Re: GSeal bugs in GtkAccelLabel hampering flexibility

[Peter Clifton <pcjc2 cam ac uk>]

On Mon, 2009-01-26 at 10:15 +0100, Mathias Hasselmann wrote:
> 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.

Don't lecture me on FOSS. It works fine in gEDA, and other projects I'm
contributing to with occasional bug-fixes / reports, like X / Intel
video etc... and it does NOT always require the bug reporter sends a
patch. (It wasn't me who sealed members without providing setters).

Some times recognising / diagnosing the problem is more important than
learning an alien code-base and attempting a fix the problem. That
probably isn't going to lead to great code either. At the very least,
I'd need some input from a GTK developer suggesting how the fix should
be architected, what the original design decisions were which made the
code as it is now.

The way GTK seems to have worked (from my past experience), is I /
others write patches, then they sit in Bugzilla and get ignored. I won't
pollute this reply with the list of examples, but I can think of
several. (Ok - only one patch was mine).

Having the first reply to my post basically saying get lost and write
some patches is not conducive to good collaboration on the problem.


In any case.. to rely on upstream code changes we'd be waiting several
years or so before we can actually write applications based on that
code, and assume it to be present. The gEDA userbase is very
conservative, and tends not to run a bleeding-edge distro - which is a
pain. I've only just been "allowed" to depend on GTK 2.8 for our latest
release, that's how bad things are!.

I brought the issue up at all (rather than just sulking about the
problem privately) was in the hope that it would result in the problem
_eventually_ being fixed.


-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)