Re: GSeal bugs in GtkAccelLabel hampering flexibility

[Mathias Hasselmann <mathias hasselmann gmx de>]

Am Montag, den 26.01.2009, 04:03 +0000 schrieb Peter Clifton:
> Hi,
> 
> I'm trying to write a subclass of GtkAccelLabel in order to override its
> source for the accelerator string.
> 
> gEDA (GPL Electronic CAD) uses multi-key-press keyboard shortcuts which
> are unfortunately incompatible with the GtkAccelGroup way of achieving
> keyboard shortcuts.
> 
> 
> By subclassing GtkAction, I've been able to add extra data, stashing our
> desired accelerator string, and have been able to override the
> connect_proxy method in order to replace the GtkAccelLabel in the menu
> item with a custom "GschemAccelLabel", upon which I set a string
> property with our desired accelerator text.
> 
> All is well here, and menus work - display as expected. (Even if I
> suspect the fact you can swap the GtkMenuItem's label before hooking the
> GtkAction connect_proxy method may be exploiting implementation details
> of the system.
> 
> 
> Unfortunately, GtkMenuItem will only check the accelerator width for
> GtkAccelLabel and its subclasses. (I'm currently subclassing GtkLabel).
> 
> However.. even if I subclass GtkAccelLabel, I have no means to override
> its idea of what the accelerator string is, nor the width it returns
> when queried.
> 
> 
> The header file GSEALs the required members:
> 
> struct _GtkAccelLabel
> {
>   GtkLabel label;
> 
>   guint          GSEAL (gtk_reserved);
>   guint          GSEAL (accel_padding);      /* should be style property? */
>   GtkWidget     *GSEAL (accel_widget);       /* done*/
>   GClosure      *GSEAL (accel_closure);      /* has set function */
>   GtkAccelGroup *GSEAL (accel_group);        /* set by set_accel_closure() */
>   gchar         *GSEAL (accel_string);       /* has set function */
>   guint16        GSEAL (accel_string_width); /* seems to be private */
> };
> 
> "seems to be private" -> Has broken my ability to override it
> accel_string _does not_ have a direct setter -> I can't override it.
> 
> 
> I felt like I was so close to making this work without having to
> re-write the whole damned GtkMenu* GtkAction* GtkAccel* class hierarchy
> in our app, but I'm beginning to realise this isn't going to work
> without major surgery.
> 
> Please please ensure that when GSEAL'ing members / hiding implementation
> details away in prep for GTK3.0, that the toolkit is actually actually
> usable / flexible enough for developers who need to subclass and extend
> or change its default behaviour.
> 
> Either make the widgets flexible enough in the first place, or expose
> the appropriate hooks / class member virtual functions in order for us
> to extend things! GtkAccel* could so nearly have been directly usable
> for what we want, but due to lack of virtual functions in the class, we
> can't just subclass it to give the behaviours we need.
> 
> 
> I'm running out of decent arguments against other developers on the team
> who want to switch away from GTK, and my own patience is becoming
> stretched. I want to love GTK, but sometimes (like tonight) it
> frustrates me so very much!
> 
> Sorry for the rant..
> 
> Any suggestions as to how to fix this will be warmly received.

What about creating a patch providing the hooks you need?
In the end that's how FOSS works.

Ciao,
Mathias
-- 
Mathias Hasselmann <mathias hasselmann gmx de>
Personal Blog: http://taschenorakel.de/mathias/
Openismus GmbH: http://www.openismus.com/