On 20 Dec 2019, at 18:15, Wolfgang Lux <wolfgang....@gmail.com> wrote: > > >> Am 20.12.2019 um 16:11 schrieb Fred Kiefer <fredkie...@gmx.de>: >> >> ... >> >> There you just describe that now the popup looks the same whether in pull >> down or in popup state. But what is the reason for this change? As I wrote I >> am happy with getting rid of all this special code, but last time I tried to >> do this it was rejected. > > I don't recall whether I was involved in that rejection or not, but if I > wasn't I'd think that it was the correct move. > > Regarding the different behavior with regard to the title cell, it apparently > dates back to the heyday of OpenStep (and presumably the original NeXTstep as > well). The idea seems to be that the title that is visible in the pop up > button cell when the menu is not visible should be backed up by an element of > the associated menu. In pop up mode this would be the selected item, while in > pull down mode it is invariably the first element of the menu (since the > title of the pull down is not supposed to change depending on the user's last > selection). I think that's nothing that GNUstep can or should change.
This is how it works before and after change. > That only leaves you with the option whether to display the title item when > the pull down is visible or to not display it. If you wanted to display the > title, the only reasonable choice for that would be such that the title item > appears above the button itself (because otherwise you would redundantly > display the same information twice). Correct. This is how it works after change. > But then that doesn't work that well if you display an icon in the button > cell rather than text (useful, for instance, when you want to make NSToolbar > buttons with an attached pull down menu) and the popup button's width and/or > height do not match the width or height of the menu (items). Also beware that > the menu does not necessarily need to appear at the bottom of the pop up > button. You can set the preferredEdge property of the button cell to make it > appear on one of the sides of the button (or even appear attached to the top > edge, although I don't see a reason for doing that). But of course these are > all aesthetic judgements so feel free to disagree. Good points. I guess these are the cases for further testing, changing and separate PR. > > Wolfgang > Sergii