Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
On Wed, 2005-06-15 at 17:48 -0400, Paul Davis wrote: On Wed, 2005-06-15 at 12:39 -0500, Bob Caryl wrote: Hey everyone, I am using the GtkHTML widget to create a help viewer for my application. It works well, but I cannot use gtkmm to create my application window because The Compiler Bob drops to the floor and genuflects just freaks out when I try to use a derived window class-member function as an argument for the GTK G_CALLBACK macro (using a call to sigc::mem_fun() ) when doing a signal connection to the GtkHTML object. Hence, I have been forced to write the entire thing as a standalone application using only GTK :-( sigc::mem_fun() produces a slot. a slot is in almost no way related to a ptr-to-function as required for GTK C callbacks. if you want to use C++ and sigc++, plan on using gtkmm, not GTK directly. And if you must provided a C function pointer, you'll need to provide a pointer to a static method (or global function) and the state information as user_data. See the various SignalProxy classes, for instance, in TreeSelection. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
Paul Davis wrote: if you want to use C++ and sigc++, plan on using gtkmm, not GTK directly. Well, when somebody writes a wrapper for GtkHTML I can do that.. right? But for now, I seem to be in a pickle. Bob ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
Murray Cumming wrote: And if you must provided a C function pointer, you'll need to provide a pointer to a static method (or global function) and the state information as user_data. See the various SignalProxy classes, for instance, in TreeSelection. In other words, the way I've done it (separate executable invoked via fork, execv) is the only thread safe way to do this until GtkHTML has a C++ wrapper. Thanks guys, Bob Caryl ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
On Thu, 2005-06-16 at 06:08 -0500, Bob Caryl wrote: Murray Cumming wrote: And if you must provided a C function pointer, you'll need to provide a pointer to a static method (or global function) and the state information as user_data. See the various SignalProxy classes, for instance, in TreeSelection. In other words, the way I've done it (separate executable invoked via fork, execv) is the only thread safe way to do this until GtkHTML has a C++ wrapper. I don't see how threads have anything to do with this. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
On Thu, 2005-06-16 at 06:08 -0500, Bob Caryl wrote:
Murray Cumming wrote:
And if you must provided a C function pointer, you'll need to provide a
pointer to a static method (or global function) and the state
information as user_data. See the various SignalProxy classes, for
instance, in TreeSelection.
In other words, the way I've done it (separate executable invoked via
fork, execv) is the only thread safe way to do this until GtkHTML has a
C++ wrapper.
what are you thinking? this has nothing to do with threads. it doesn't
even have a *lot* to do with language, except for the fact that you
can't use a non-static C++ member function as a C callback. if you
really want to use C++ objects with GTK widgets, then do this:
class Foo {
public:
static gint my_c_proxy_for_bar (arglist...);
gint my_handler_for_bar (otherarglist...);
};
gint
Foo::my_c_proxy_for_bar (..., gptr user_data, ...)
{
return reinterpret_castFoo*(user_data)-my_handler_for_bar
(relevant_args...);
}
gint
Foo::my_handler_for_bar (otherarglist...)
{
}
and then somewhere, connect
gtk_signal_connect (widget, signal, , SomePtrToFoo);
I have done this a lot with the GtkCanvas widget which has never been
wrapped for C++ (and never will be; we're migrating to GNOME::Canvas
ASAP)
--p
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
Paul Davis wrote: what are you thinking? this has nothing to do with threads. it doesn't even have a *lot* to do with language, except for the fact that you can't use a non-static C++ member function as a C callback. Evidently I have failed to make clear the circumstances surrounding this situation. The callback function involved is one that opens a resource file (like an image source) to load its content into a GtkHTML widget when that widget issues a url-requested signal. This widget would have been embedded into a scrolled_window container within a Gtk::Window. The callback function for the url-requested would need to have access to information within the derived Gtk::Window class itself to be able to do its job. I had originally intended to write my help display routine as part of a dynamic library intended for use by my applications. If I use a global function in this setting it would be entirely possible that multiple applications and/or threads in the same application could try to call such a global function simultaneously (or nearly simultaneously), thereby giving indeterminate results. *That* is what I was thinking, Paul. If my concerns in this regard are misplaced I would hope you guys would point out *why*. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
Paul,
thks for the code outline. I have also been struggling with using a gtk
widget in my gtkmm code. Unless there is another demo somewhere that I have
not seen, maybe this code could be cleaned up a bit with comments, etc to
have a nice clear demo of a gtk widget being wrapped and instantiated and
having it's signal picked up by a gtkmm slot function. This would be really
useful and also make a great addition to the gtkmm tutorial.
John
On Thursday 16 June 2005 05:50 am, Paul Davis wrote:
On Thu, 2005-06-16 at 06:08 -0500, Bob Caryl wrote:
Murray Cumming wrote:
And if you must provided a C function pointer, you'll need to provide a
pointer to a static method (or global function) and the state
information as user_data. See the various SignalProxy classes, for
instance, in TreeSelection.
In other words, the way I've done it (separate executable invoked via
fork, execv) is the only thread safe way to do this until GtkHTML has a
C++ wrapper.
what are you thinking? this has nothing to do with threads. it doesn't
even have a *lot* to do with language, except for the fact that you
can't use a non-static C++ member function as a C callback. if you
really want to use C++ objects with GTK widgets, then do this:
class Foo {
public:
static gint my_c_proxy_for_bar (arglist...);
gint my_handler_for_bar (otherarglist...);
};
gint
Foo::my_c_proxy_for_bar (..., gptr user_data, ...)
{
return reinterpret_castFoo*(user_data)-my_handler_for_bar
(relevant_args...);
}
gint
Foo::my_handler_for_bar (otherarglist...)
{
}
and then somewhere, connect
gtk_signal_connect (widget, signal, , SomePtrToFoo);
I have done this a lot with the GtkCanvas widget which has never been
wrapped for C++ (and never will be; we're migrating to GNOME::Canvas
ASAP)
--p
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
Lars Luthman wrote: On Thu, 2005-06-16 at 07:22 -0500, Bob Caryl wrote: I had originally intended to write my help display routine as part of a dynamic library intended for use by my applications. If I use a global function in this setting it would be entirely possible that multiple applications and/or threads in the same application could try to call such a global function simultaneously (or nearly simultaneously), thereby giving indeterminate results. Why would a global function be less thread safe than a member function? As long as you're not using any global or static function variables (which you also could do in a member function) I don't see how there is a difference. I'm an old windows programmer (and therefore relatively new to linux GUI programming), and so I'm assuming that dynamically loaded libraries work the same way under linux as they do under windows: If an application (or thread within an application) instantiates an object, it gets its own exclusive copy of that object (complete with all the data used by such an object). If, on the other hand, an application (or thread), uses a global function and/or global data from within a dynamically loaded library that is subject to such use by other applications and/or threads, it is possible that simultaneous accesses could happen. In the case of my callback, two applications could be trying to load data into the SAME GtkHTML widget at the same time and thereby would be sharing ONE GtkHTMLStream handle. If my understanding of how dynamically loaded libraries work under linux, please disabuse me of my notions. ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
On Thu, 2005-06-16 at 08:01 -0500, Bob Caryl wrote: Lars Luthman wrote: On Thu, 2005-06-16 at 07:22 -0500, Bob Caryl wrote: I had originally intended to write my help display routine as part of a dynamic library intended for use by my applications. If I use a global function in this setting it would be entirely possible that multiple applications and/or threads in the same application could try to call such a global function simultaneously (or nearly simultaneously), thereby giving indeterminate results. Why would a global function be less thread safe than a member function? As long as you're not using any global or static function variables (which you also could do in a member function) I don't see how there is a difference. I'm an old windows programmer (and therefore relatively new to linux GUI programming), and so I'm assuming that dynamically loaded libraries work the same way under linux as they do under windows: If an application (or thread within an application) instantiates an object, it gets its own exclusive copy of that object (complete with all the data used by such an object). If, on the other hand, an application (or thread), uses a global function and/or global data from within a dynamically loaded library that is subject to such use by other applications and/or threads, it is possible that simultaneous accesses could happen. In the case of my callback, two applications could be trying to load data into the SAME GtkHTML widget at the same time and thereby would be sharing ONE GtkHTMLStream handle. This would only be true if it was shared (static) memory. Obviously 2 applications don't share the same widget, or every label would contain the same text in every window in application. If my understanding of how dynamically loaded libraries work under -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
On Thu, 2005-06-16 at 15:09 +0200, Murray Cumming wrote: This would only be true if it was shared (static) memory. Obviously 2 applications don't share the same widget, or every label would contain the same text in every window in application. If my understanding of how dynamically loaded libraries work under And also, you didn't have this problem/confusion when using the MFC DLL, so why have it with gtkmm or gtkhtml? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
I'm an old windows programmer (and therefore relatively new to linux GUI programming), and so I'm assuming that dynamically loaded libraries work the same way under linux as they do under windows: If an application (or thread within an application) instantiates an object, it gets its own exclusive copy of that object (complete with all the data used by such an object). If, on the other hand, an application (or thread), uses a global function and/or global data from within a dynamically loaded library that is subject to such use by other applications and/or threads, it is possible that simultaneous accesses could happen. In the case of my callback, two applications could be trying to load data into the SAME GtkHTML widget at the same time and thereby would be sharing ONE GtkHTMLStream handle. If my understanding of how dynamically loaded libraries work under linux, please disabuse me of my notions. it all depends on the design of the library. good libraries (i.e. more than 90% of them) have no global or function-scope static variables. if they require state, they provide some kind of init function that the caller has to invoke before doing anything (consider gtk_init()). if they require this state for thread-safety, they generally require you to pass some kind of object returned by the init to each call. if there is a library function that gives you, say, a new GtkHTML widget: GtkWidget* browser = gtk_html_new (...); then there is 99.5% certainty that the object you have created is unique. nothing else will access it unless you give them the address stored in browser (or they do a pointer walk, but thats another story). now of course, if the library has a function like this: GtkWidget* browser = gtk_html_get_the_one_instance(); then you have a different issue. If the docs don't state that you can use the instance from multiple threads simultaneously, then you should get a new library. as murray said, you apparently were not confused by this with MFC and win32 DLL's - why the confusion with Linux. non-thread-safeness in a library is not because its a library or dynamically linked - its because the library is badly written and/or designed. true on win32, true on *nix. its unfortunate if your experiences on windows have led you to think otherwise. oh, and finally. X Window-based GUI toolkits are generally *not* thread safe, unlike the stuff on win32. there is always a trade off with this question: if you make things thread safe, there is real cost for the single-GUI-thread case; if you make things non-thread safe, there is ral cost for the multi-GUI-thread case. win32 took one path, X Window has taken the other. this means that even though the library problems you are imagining are not actually real, the issue of doing GUI work from multiple threads with *any* X Window toolkit (GTK, Qt, FLTK etc) need to be carefully thought through. The solutions are not hard, but they require a comprehensive understanding of the issues, and a consistent approach to program design Google for GTK threads multiple and you'll find a smattering of posts, some of them even from me :) --p ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
On Thu, 2005-06-16 at 07:22 -0500, Bob Caryl wrote: I had originally intended to write my help display routine as part of a dynamic library intended for use by my applications. If I use a global function in this setting it would be entirely possible that multiple applications and/or threads in the same application could try to call such a global function simultaneously (or nearly simultaneously), thereby giving indeterminate results. Why would a global function be less thread safe than a member function? As long as you're not using any global or static function variables (which you also could do in a member function) I don't see how there is a difference. (sorry if this mail is sent twice to the list, I think I used the wrong sender address last time) -- Lars Luthman PGP key: http://www.d.kth.se/~d00-llu/pgp_key.php Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E signature.asc Description: This is a digitally signed message part ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
On Thursday 16 June 2005 12:50, Paul Davis wrote:
On Thu, 2005-06-16 at 06:08 -0500, Bob Caryl wrote:
Murray Cumming wrote:
And if you must provided a C function pointer, you'll need to provide a
pointer to a static method (or global function) and the state
information as user_data. See the various SignalProxy classes, for
instance, in TreeSelection.
In other words, the way I've done it (separate executable invoked via
fork, execv) is the only thread safe way to do this until GtkHTML has a
C++ wrapper.
what are you thinking? this has nothing to do with threads. it doesn't
even have a *lot* to do with language, except for the fact that you
can't use a non-static C++ member function as a C callback. if you
really want to use C++ objects with GTK widgets, then do this:
class Foo {
public:
static gint my_c_proxy_for_bar (arglist...);
gint my_handler_for_bar (otherarglist...);
};
gint
Foo::my_c_proxy_for_bar (..., gptr user_data, ...)
{
return reinterpret_castFoo*(user_data)-my_handler_for_bar
(relevant_args...);
}
gint
Foo::my_handler_for_bar (otherarglist...)
{
}
and then somewhere, connect
gtk_signal_connect (widget, signal, , SomePtrToFoo);
I have done this a lot with the GtkCanvas widget which has never been
wrapped for C++ (and never will be; we're migrating to GNOME::Canvas
ASAP)
You are not even guaranteed that static C++ member functions can be used as a
C callback.
You should really use a function with C linkage as the proxy (probably in
anonymous namespace so it is not exported). Static member functions are not
guaranteed to have the C linkage. On g++ they do, but I believe on the Intel
compiler as an example they do not, and your example will not compile. (In
your example the C++ handler is public, but if it were private the proxy
function would also need to be a friend.)
Chris
___
gtkmm-list mailing list
gtkmm-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
You should really use a function with C linkage as the proxy (probably in anonymous namespace so it is not exported). Static member functions are not guaranteed to have the C linkage. On g++ they do, but I believe on the Intel compiler as an example they do not, It does work on g++, SUN CC, AIX, Irix, and HP-UX compilers, however. I think it works on the ARM compiler. I don't know about the Intel compiler. Let's not confuse him with irrelevant details. However, there's a bug about this, and patches are welcome. Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Using (or not using) sigc::mem_fun with the G_CALLBACK macro
On Wed, 2005-06-15 at 12:39 -0500, Bob Caryl wrote: Hey everyone, I am using the GtkHTML widget to create a help viewer for my application. It works well, but I cannot use gtkmm to create my application window because The Compiler Bob drops to the floor and genuflects just freaks out when I try to use a derived window class-member function as an argument for the GTK G_CALLBACK macro (using a call to sigc::mem_fun() ) when doing a signal connection to the GtkHTML object. Hence, I have been forced to write the entire thing as a standalone application using only GTK :-( sigc::mem_fun() produces a slot. a slot is in almost no way related to a ptr-to-function as required for GTK C callbacks. if you want to use C++ and sigc++, plan on using gtkmm, not GTK directly. --p ___ gtkmm-list mailing list gtkmm-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtkmm-list
