bulia byak wrote:

Jon,

in today's CVS:

• There's a noticeable delay after the program window appears and

before it shows icons in toolbars. It never happened before.

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.

• You removed the possibility for toolbars to be cut. Why? Now the

window starts up wider than before, and if we add more controls to the selector toolbar it will have to be wider still. Moreover switching tools (e.g. switch to star) may resize the window, which is very annoying. Please fix this.

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.

Besides, you removed the only place where the "detach" flag was checked but did not remove its setting. This flag was added to make sure a detached toolbar is not cut while the attached one may be cut by the window. I think this must be restored.

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.