Re: callback_data in Gtk2::SimpleMenu [and Gtk2::ItemFactory (well, Gtk2.pm)]
- From: Don Armstrong <don donarmstrong com>
- To: Gtk-Perl-List <gtk-perl-list gnome org>
- Subject: Re: callback_data in Gtk2::SimpleMenu [and Gtk2::ItemFactory (well, Gtk2.pm)]
- Date: Mon, 2 Feb 2004 10:50:50 -0800
On Mon, 02 Feb 2004, Ross McFarland wrote:
On Mon, 2004-02-02 at 00:41, Don Armstrong wrote:
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.
That's probably because of the confusion that calling it user_data
causes, as ever GtkObject has it's own user-data property which is
totally separate from the callback_data...
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,
struct GtkItemFactoryEntry {
gchar *path;
gchar *accelerator;
GtkItemFactoryCallback callback;
....
}
void gtk_item_factory_create_items (GtkItemFactory *ifactory,
guint n_entries,
GtkItemFactoryEntry *entries,
gpointer callback_data);
entries : an array of GtkItemFactoryEntrys whose callback members must by of type
GtkItemFactoryCallback1
As you can see, create_items takes an array of GtkItemFactoryEntrys
whose callback members are GtkItemFactoryCallback1.
GtkItemFactoryCallback1 has it's own callback_data.
void (*GtkItemFactoryCallback1) (gpointer callback_data,
guint callback_action,
GtkWidget *widget);
Now, it's possible that the callback_data to create_items is totally
separate from the callback_data in GtkItemFactoryCallback1. [If so,
someone really needs to clean up the documentation in this area of the
code, because it's not clear at all.]
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 hashref is created and goes away once it's out of scope and no
longer referenced, so the memory useage and the time involved really
isn't that big of a deal.
There are places to make up time and memory useage, but if it causes
the program to get locked into a particular design implementation, you
have to weigh it carefully.
Regardless, as you're the person responsible for maintaining this
slice of code, do it any way that works for you... it's merely a
suggestion comming from someone who has seen the time it takes to keep
a purely array based paramater system in sync with changing function
calls.
Don Armstrong
--
I'd sign up in a hot second for any cellular company whose motto was:
"We're less horrible than a root canal with a cold chisel."
-- Cory Doctorow
http://www.donarmstrong.com
http://www.anylevel.com
http://rzlab.ucr.edu
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]