Global Key Command Button Icon do not show

Uh… are you including the main window toolbar in this idea? You’d better take a look at the Federation & Empire module.

I think I’ve seen programs that do this, and it can work if it’s a fairly small toolbar, with just a little bit that doesn’t fit. Generally only a good idea if screen real estate is at an absolute premium.

I am seeing it more and more in newer programs

Here is an example toolbar. I wouldn’t call it a scrolling bar though - more of an extended hidden pane that is accessible by pressing the “>>” arrows. The scrolling part of the bar is in effect on the ribbon portion though via mouse wheel on the tabs

[attachment=0]toolbar.png[/attachment]

If you resize the window both work correctly with the toolbar wrapping. You see the difference in that my fix doesn’t show the bug which started this discussion. When you open the centauri map the buttons are displayed correctly.

This is because I use a different test to decide whether to redo the tree layout and I use the correct way to achieve this.

Firefox does the same with its bookmark toolbar. If there’s too many to display it puts a “>>” button at the end of the toolbar clicking on which gives the remaining entries as a drop down menu. This might not work for us but could work by scrolling the toolbar left to reveal more choices.

Thus spake george973:

What I’m asking is: How do I bring this situation about, so that I can
see the difference between old WrapLayout and your modification?

If you resize the window both work correctly with the toolbar wrapping.
You see the difference in that my fix doesn’t show the bug which started
this discussion. When you open the centauri map the buttons are
displayed correctly.

Sorry, I didn’t ask about what I meant to. What I intended to ask about
was the difference in behavior between your code and simply not
overriding layoutContainer at all.


J.

WrapLayout calculates the preferred size on the basis of the current width and how that causes the toolbar to wrap. This size is used to allocate space for the toolbar. Since the width may change this calculation may be incorrect.

My extra code overriding layoutContainer just checks that the component as laid out fit within the size of the toolbar and force another round of layout if they don’t.

The effect of not having it there means that it is possible for buttons not to appear because they’re outside of the toolbar and therefore not drawn. How often it would happen is not clear since dragging a winow smaller causes lots of resizes. You’d need to put a breakpoint on the relayout code or a message and try lots of resizing to see how often it triggers.

Basically it’s an insurance policy which won’t always be needed but will stop the problem of toolbars not appearing.

Thus spake george973:

My extra code overriding layoutContainer just checks that the component
as laid out fit within the size of the toolbar and force another round
of layout if they don’t.

Ok. Merged to trunk@8083, 3.1@8085.


J.