Re: GtkMenu padding - need an alternative for providing an offset


On 30/10/13 01:10, Michael Webster wrote:
Apologies if this has been brought up already...

This patch:

Is it just me or all these changes we've recently made are not 'deprecations'
but ABI breaks?

If foo_frobnicate() changes from doing something useful to being a nop, we're
breaking our interface, whether we keep the symbol in the DSO or not. GObject
properties are no different.

Don't get me wrong, I'm not against this kind of changes. But I'd rather see us
keep compatibility until GTK+ 4 is out than (rightfully) piss off our users
because of changes like this.


deprecated GtkMenu-horizontal-padding and GtkMenu-vertical-padding,
suggesting that CSS padding is used instead.  The problem is that these two
values were commonly used to provide a slight 'nudge' to context menus to
prevent the first item in the menu from being automatically highlighted
(and possibly inadvertantly selected) when the context menu appeared under
the pointer.

With this deprecation, we can no longer do this - and adding more padding
is simply compensated for in the positioning code, so that first menu item
is always selected.

It would be nice to have some sort of either gtk setting or even hard-code
in 1 or 2 pixels of extra position in X and Y to avoid this situation,
which could be very frustrating to deal with.


gtk-devel-list mailing list
gtk-devel-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]