Re: [gtk-list] Re: C++ and Gtk

[Kenneth Albanowski <kjahds kjahds com>]

On Wed, 27 May 1998, Brian Stempel wrote:

> In fact, I think that using "this" is probably the most flexible choice as a
> candidate for the slot, because it basically allows the static function to
> simulate a regular object method, with the same access, scope, etc. that the
> other non-static methods of the object have.  Can you give an example of
> where you'd need to use set_data/get_data, rather than having the data in
> question be a member of the class?

Consider two buttons, routed to the same handler, with only the "data" 
value to distinguish them. ("Zoom in" vs. "Zoom out", if you like.) More
importantly, and to prevent separate handlers from being used, consider an
indeterminate, or at least large, set of objects constructed at run time,
connected up to the same static handlers. Since you've got two variables
here (object in which method should be invoked, and value indicating which
object triggered the request), they need to either be distinguished with
the "data" value, via the widget value itself, or (most readily) with
set_data/get_data in the widget.

At worst, consider (for some unclear reason) if you needed to hook the
same handler up to more then one signal on the same object, and needed to
distinguish the calls (actually, all of the interpreter bindings have to
do exactly this). In this case, the "data" value is the only way to
distinguish between calls, so you need to put together a small struct
containing both the 'this' pointer, and any additional data needed to
distinguish the calls.

> AFA MenuFactory, I cannot comment, as I have only done menus using the manual
> approach, but I still do not see why a MenuFactory, ensconced in some type of
> menu managing class, could not achieve the same effect?  Can you elaborate
> please on why it is so difficult to use MenuFactory with this technique?

Because we are back to using the "data" pointer for 'this', but we might
want to store another arbitrary value, to trigger the handler in some
fashion, or (in a patch that hasn't made it in to the dist) to easily
handle radio items. 

> I ask because, as I said before, I'm planning on doing some stuff shortly
> here, and I'd like to know if there's some things I need to address.

I also have a patch which mucks with MenuFactory such that it stores a
fixed value in all of the "data" slots, and puts the usual "data" value in
user_data instead -- if that makes any sense :-) I'm afraid the patch in
general isn't very comprhensible, which about describes the entire issue. 

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)