Re: GSeal bugs in GtkAccelLabel hampering flexibility
Am Montag, den 26.01.2009, 04:03 + 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 */
guint16GSEAL (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.hasselm...@gmx.de
Personal Blog: http://taschenorakel.de/mathias/
Openismus GmbH: http://www.openismus.com/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
On Mon, 2009-01-26 at 10:15 +0100, Mathias Hasselmann wrote:
Am Montag, den 26.01.2009, 04:03 + 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 */
guint16GSEAL (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
Re: GSeal bugs in GtkAccelLabel hampering flexibility
Peter Clifton wrote: 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). Peter, I understand your frustration, but I don't see how attacking GTK+ maintainers helps. SO yeah, GTK+ has two part-time maintainers. What do you expect them to do? Qt has a team of 100 behind it. Does that make Qt more responsive to bug reports? Go try... If you want a workaround for now, just access the member as GSEAL(member_name). I told them the GSEAL macro should use __line__, they didn't listen :P. behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
On Mon, 2009-01-26 at 00:59 -0500, Yu Feng wrote: Hi Peter, I agree with you to seal accel_string without any getter/setter sucks. But some of my code may interest you. Look for class MenuLabel in the following file to see its public interface: Thanks for the suggestion. I did in fact do similar. From within the GtkAction subclass, you get a chance to set the GtkMenuItem*'s label _before_ calling the parent class connect_proxy fuction. gnome2-globalmenu.googlecode.com/svn/trunk/libgnomenu/Gnomenu-1.0.gir The dirty trick is to throw GtkAccelLabel away, then put two GtkLabels in one MenuItem. one of them aligns to the left, the other aligns to the right. It is not exactly the the same as Gtk's accel labels, but so close that none of my users have noticed the diff. The computation of the proper alignments is off for me, unfortunately. There are more exposed methods for setting the toggle size of a menu item, but I couldn't find anything suitable to override the size of the accelerator. I don't know if you can still assign GtkActions to them though. Should be able to.. just won't have it display the accelerator. GtkAction is quite a nice class. You can subclass it and provide custom factories for making menu items / toolbar buttons of the desired type.. or set the GType to be created by the built-in functions. It falls down slightly because the built-in connect_proxy member function needs to be called (it hooks up some private stuff, and refcounts etc..), but also manipulates the way a proxy object is connected. You have to be careful how you override that, and doing so is probably exploiting implementation details of just how the built-in connect_proxy function operates. Best regards, -- 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!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
On Mon, 2009-01-26 at 09:59 -0500, Behdad Esfahbod wrote: Peter Clifton wrote: 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). Peter, I understand your frustration, but I don't see how attacking GTK+ maintainers helps. SO yeah, GTK+ has two part-time maintainers. What do you expect them to do? Qt has a team of 100 behind it. Does that make Qt more responsive to bug reports? Go try... Sorry, I didn't mean to attack the GTK maintainers in general, I was just cross that the first reply I got was basically patches welcome. I should learn to move away from my computer when I'm in a bad mood about something ;) If you want a workaround for now, just access the member as GSEAL(member_name). I told them the GSEAL macro should use __line__, they didn't listen :P. Ok - didn't know I could do that. I had presumed the sealed members we not available for prodding outside GTK's codebase. (BTW.. what would __line__ do exactly?) If this lets me work around the problem, perhaps I can help prepare a more complete fix for GTK 3.0, whilst not being stuck in limbo waiting for users to move onto some as-yet unreleased GTK version. I'm not event sure whether all the fixes can even be made without breaking ABI. (GTK 3.0 will break ABI right?) I presume accessing members with GSEAL(member_name) carries a big Caveat Emptor, that you're now relying on implementation details. Thanks Behdad, I know I didn't deserve a helpful reply when I was being a grumpy git, but you provided one anyway. Best wishes, -- 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!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
Peter Clifton wrote: If you want a workaround for now, just access the member as GSEAL(member_name). I told them the GSEAL macro should use __line__, they didn't listen :P. Ok - didn't know I could do that. I had presumed the sealed members we not available for prodding outside GTK's codebase. It's a bad hack. I'm sure the GTK3 guys will find me and hunt me for letting this out. (BTW.. what would __line__ do exactly?) It expands to the line number. If the GSEAL macro used that to include the line number in the mangled name you couldn't use this trick. If this lets me work around the problem, perhaps I can help prepare a more complete fix for GTK 3.0, whilst not being stuck in limbo waiting for users to move onto some as-yet unreleased GTK version. I'm not event sure whether all the fixes can even be made without breaking ABI. (GTK 3.0 will break ABI right?) Correct. But the idea is to make transition as straightforward as possible. I presume accessing members with GSEAL(member_name) carries a big Caveat Emptor, that you're now relying on implementation details. Well, one is not supposed to use the GSEAL'ed members. But given your situation, well, why not... Cheers, behdad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
On Mon, 2009-01-26 at 16:34 -0500, Behdad Esfahbod wrote: Peter Clifton wrote: If you want a workaround for now, just access the member as GSEAL(member_name). I told them the GSEAL macro should use __line__, they didn't listen :P. Ok - didn't know I could do that. I had presumed the sealed members we not available for prodding outside GTK's codebase. It's a bad hack. I'm sure the GTK3 guys will find me and hunt me for letting this out. (BTW.. what would __line__ do exactly?) It expands to the line number. If the GSEAL macro used that to include the line number in the mangled name you couldn't use this trick. If this lets me work around the problem, perhaps I can help prepare a more complete fix for GTK 3.0, whilst not being stuck in limbo waiting for users to move onto some as-yet unreleased GTK version. I'm not event sure whether all the fixes can even be made without breaking ABI. (GTK 3.0 will break ABI right?) Correct. But the idea is to make transition as straightforward as possible. I presume accessing members with GSEAL(member_name) carries a big Caveat Emptor, that you're now relying on implementation details. Well, one is not supposed to use the GSEAL'ed members. But given your situation, well, why not... Turns out about 20% of our source files don't compile with -DGSEAL_ENABLE anyway, so looks like we've got some work to do before GTK3.0 comes out ;). Oh.. and a fair number of these bugs were in my stolen and modified from GTK sources GtkAction and GtkAccelLabel subclasses. Please do help enlighten me though.. I'm going mad trying to figure this one out... how does actually GSEAL work? (I've not found anything using Google). I can't grep a single reference defining the GSEAL macro in /usr/include, nor _g_seal__. Yet magically -DGSEAL_ENABLE makes the code compilation break by hiding those members. Am I being dumb...? What black magic is going on here? -- 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!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSeal bugs in GtkAccelLabel hampering flexibility
On Mon, 2009-01-26 at 22:09 +, Peter Clifton wrote: I can't grep a single reference defining the GSEAL macro in /usr/include, nor _g_seal__. Yet magically -DGSEAL_ENABLE makes the code compilation break by hiding those members. Am I being dumb...? What black magic is going on here? Found it... /usr/lib/gtk-2.0/include/gdkconfig.h Sorry for the noise. -- 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!) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GSeal bugs in GtkAccelLabel hampering flexibility
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 */
guint16GSEAL (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!)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
