bulia byak wrote: Yes. Prior to this, all the icons were rendered and cached when the SPIcons were created during program initialization. Now they're not rendered untill they are actually realized (how GtkImage does it). The delay is them being rendered for the first time. I was thinking that we'd need some sort of pre-render to go back in. The main problem, though, is that it's not that simple. At program launch (when the prior versions would pre-render) the theme is not yet in place. So a theme change occurrs *after* initial creation, and thus invalidates much of the cached contents. Among other things, that was why the stock icons like file|open would always pull the fallback GTK+ versions even though the current default theme had different icons for that. Also complicating it is that the only way to detect a 'theme change' at the moment is when the individual SPIcon widgets themselves get notified of a style change. They respond to that change by invalidating their internal bitmap and thus marking itself to be re-rendered at next 'expose'. For the short term, we could pre-cache some at initialization since our SVG icons now are only getting the size from the current theme, thus good chances that some sizes will be the same. But moving forwards we'll probably want to get something a little more robust, and also allow our SVG icons to get colored by the current theme, etc. The hardcoding shortcut was what happened to allow cutting previously. Getting rid of the 'naughty' code happened to get rid of that benefitial side-effect. So I just need to track down a proper way to allow that to happen. Just like with the toolbox heights, I'll replace the physical with some logical. The old height way was "set all toolbars to a minimum of XX pixels". The new height way is "set all these toolbox widgets to get the height desired by the largest". That's what I mean by physical versus logical. Yes. It might be needed. But then again it might not. Once I track down a better way of handling that, then we'll see what's needed. Often things just start working better. It's just the transition from physical to logical that gets a little tough. BTW, that does bring up a related 'cut' issue. The vertical toobox has major problems. You've never seen it need to be cut before, but when I switch to 'Large Print' it ends up too large vertically for my screen, and the entire status bar gets pushed off. And that's without even switching to the large font the theme recommends. Would we want to get some kind of "scroll if too many things" going on there? Any other standard UI approach that would work out better? I do think that this could be similar to the problem with horizontal cutting.

bulia byak wrote: No... they weren't "logical". They were physical. 'request 0' logically says "I don't need any size at all, so don't give me any". However, when docked, the layout takes over and says "too bad, I'm giving you this much. Deal with it". :-) The logic was in the programmer, not the code. In this case, the code itself didn't say "only use what size is there". That properly belongs to the layout. Instead the widget itself was hardcoded with a value. The net effect appeared similar, but the logic was very different. And guess what? I found the "proper" solution! gtk_toolbar_set_show_arrow () " Sets whether to show an overflow menu when /toolbar/ doesn't have room for all items on it. If TRUE, items that there are not room are available through an overflow menu" So there's a nice, HIG-ified automatic way to just get what we want. The only problem is, that routine is for use on a GtkToolbar. We're not using the standard toolbar, but our own thing. :-( Oh, yes. I realize that. I was just pointing out that the variable in question may not be needed. I did leave the setting in just in case it would be needed. But it might go away also.

bulia byak wrote: Well... I'll check around a bit. Chances are there are still issues with the stock toolbar. I know I tried floating the one from gedit here on FC3 and couldn't move it after floating. I'll see if we can wrap a 'real' one in ours. If not I'll look at duplicating the key functionality. But at least now we have a definition of where to go and how to fix it.