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

I wonder if a patch to introduce an offset into the GtkMenu initial popup position would be accepted.

There is already a style property "horizontal-offset" and "vertical-offset" that applies to submenus.  Perhaps an "initial-offset" property that would kick the initial menu over by that value in both X and Y?  That way we're propertly constructing and positioning padding, and providing the ability (that heretofore has been an 'unintended' feature) to move the popup menu out from under the mouse initially.

I'll prepare the patch, but I'd like to be sure there would at least be consideration for this.


On Wed, Oct 30, 2013 at 7:36 AM, Michael Webster <miketwebster gmail com> wrote:
For what it's worth, I'm guessing the current behavior is what was intended all along, and we've all been using what was previously an accidental 'feature' to accomplish something (using padding as a menu offset) to improve the usability of the context menus.

On Tue, Oct 29, 2013 at 9:26 PM, Emilio Pozuelo Monfort <pochu27 gmail com> wrote:

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.
> Thanks
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org

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

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