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

[Emilio Pozuelo Monfort <pochu27 gmail com>]

Hi,

On 30/10/13 01:10, Michael Webster wrote:
> Apologies if this has been brought up already...
>
> This patch:
>
> https://git.gnome.org/browse/gtk+/commit/gtk/gtkmenu.c?id=01dc23cdec377c9d9897cc32bf28ec1d241b29fa

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.

Regards,
Emilio

> 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.
>
> Thanks
>
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list