Re: callback_data in Gtk2::SimpleMenu [and Gtk2::ItemFactory (well,]

On Mon, 2004-02-02 at 00:41, Don Armstrong wrote:
[Sorry, I ment for my reply to go to the list. I'm sending this
message there as well.]

On Sun, 01 Feb 2004, Ross McFarland wrote:
On Sun, 2004-02-01 at 16:41, Don Armstrong wrote:
It looks like you actually get n+1 callback_data per call to
create_items where n is the number of GtkItemFactoryEntry you

nope. gtk_item_factory_create_items is not var arg's so you get 1
user_data per call, it takes a single user_data that is used for all
the entries' callbacks.

It has a single callback_data [which is quite different from
user_data] for the function, and each GtkItemFactoryEntry has a
GtkItemFactoryCallback1 which has it's own callback_data as well as a

void        (*GtkItemFactoryCallback1)      (gpointer callback_data,
                                             guint callback_action,
                                             GtkWidget *widget);

[I don't quite understand why you're talking about user_data in the
section that I've snipped... that's a totally different issue than the

callback_data is the user_data passed to create_item(s), for whatever
reason they didn't follow the standard everything else used and call it
that, and it's the first parameter too, which is weird. the only way it
is set is by passing user_data to calls of create_item and create_items.
which gets me back to the point i've been making for 3 emails now, if
you use create_items there's no way to specify user_data/callback_data
for each entry, they all share the single user_data passed to the call
of create_items. have a look at the entry struct, the 
user_data/callback_data isn't in there, the only place it exists is in the calls to create_item(s) and it's 
passed to the signal_connects. there is not n+1 callback_data's anyway you look at it there might be n unique 
callback_data's if you called create_item n times, but if you used one single call to create_items then there 
will only be 1 callback_data that is passed to all of the callbacks. 
SimpleMenu probably should be passing a hashref instead of an
arrayref per entry like it is currently doing... that will
alleviate some of the dependency on exact function order.

not at all, it's a lot of extra over-head for no reason, it's hidden
from the user and so long as it's kept in sync with the
implementation of itemfactory (which it can and will have to be
since they're released together and tested well) the lowest overhead
is the best.

The current stable version of create_item already supports being
called with a hashref, so the overhead argument, while plausible,
isn't important since you've already added in the
overhead. Furthermore, that second of code is only being called once
per menu creation. Worrying about optimization there is kind of silly,

it isn't the overhead of having the code to do it around, it's using a
hash ref instead of an array, which would both use up more memory and
time (tiny amounts, but still.) the array is created by simplemenu and
passed to itemfactory, the world never sees it so we might as well do it
with arrays. mainly though i used arrays when i wrote it and there's no
reason to change that now.


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