GSeal bugs in GtkAccelLabel hampering flexibility

[Peter Clifton <pcjc2 cam ac uk>]

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.

-- 
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!)