Christian Holm Christensen writes:
> However, since most modern Graphics libraries uses
> signals and slots, and ROOT has that too, I guess what one could do is
> to connect the Qt/Gtk--/... signals into slots in the wrapper, which
> would then transform that into a ROOT signal.
To butcher Orwell, "not all signal/slots are created equal, some are
more equal than others".
It's true that Qt's sig/slots are close to ROOT's Rt which isn't
surprisingly, since Rt is dirrectly based on the ideas in Qt's
sig/slots.
However, Gtk--'s signal/slots, implemented in the libsigc++ library,
are different enough as to make mixing with Rt a little tricky. One
could connect an Rt signal to a libsigc++ slot but not, in general,
vice versa. This is because libsigc++ is compile-time type-safe while
Rt is neither and because libsigc++ is more flexible than Rt in the
number and types of arguments you can use for your signals and slots.
For example, with libsigc++ I can have something like:
using SigC::slot;
using SigC::bind;
// Function used as a slot
template<class T>
int myfunc(T* a, SomeClass& b, Specialization c);
// Signal returning int, taking 2 args: int* and SomeClass&
Signal2<int,int*,SomeClass&> mysig;
// Connect, binding extra_arg to be given at callback time
mysig.connect(bind(slot(myfunc<int>),extra_arg));
// later....
int array[100];
SomeClass some_object;
// trigger myfunc callback with array, some_object and extra_arg.
mysig(array,some_object);
It would be very difficult to allow things like this (which are
somewhat common) on the Gtk-- side and connect them to the Rt side.
If myfunc were to call an Rt signal, how does the Rt slot which
catches it know the type of the three arguments? And, how do you even
give an Rt slot three arguments?
Other big differences: Rt Signals (like their inspiration in Qt) exist
in the nether region of (CINT) generated code, while libsigc++'s
signals are real live objects. Also, to be a Signal emitter in Rt,
one must subclass TQObject (or use the CPP macro), while with
libsigc++, one just HasA signal data member. Likewise, to be a slot
in Rt you must run your class through CINT, while with libsigc++ you
can use SigC::slot() to turn a function or a class method into a slot.
> Then ofcourse, there's
> the issue of parents and children, and how different libraries deals
> with that. Most, I believe, do it like ROOT does it, so that
> should not be too complicated.
Gtk-- handles parent/child things differently than ROOT.
Widget memory management: All children are passed by reference to the
parent. You can either create children on the stack or on the heap.
If the latter you can create them with the manage() function:
Gtk::SomeWidget* sw = manage (new Gtk::SomeWidget);
some_parent.add(*sw);
This "manage()" function just sets a bit telling the parent Widget to
memory manage the child Widget. In ROOT, as you know, memory
management must be handled outside the parent, typically with a
"fCleanup" TList.
Widget packing: There are no LayoutHints needed. Instead, simple
arguments are passed, if needed, at the time of adding a child to a
parent. Also, you don't need to tell a parent to explicitly Layout
the children.
Menus: You ask a menu for an STL list like object. When you
push_back() the menu item you also give a slot to handle the callback
when the menu item is clicked. This means there is no giant switch
statement used, as in ROOT.
These differences help to illustrate another reason why I think it
best having the GUI separate from the rest of ROOT instead of being a
low level implementation accessed through TG classes. Because there
are such differences between the different GUI libraries, one must
necessarily end up with a high level interface which only handles a
common subset of functionality. If that subset isn't to your liking
you are without options.
Anyways, this is all probably more than you wanted to read...
-Brett.
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:04 MET