Hi Brett,
On Wed, 24 Oct 2001 15:00:44 -0400
Brett Viren <bv@bnl.gov> wrote
concerning "Re: More on Graphics abstraction (was Re: [ROOT] Qt ROOT)":
> 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.
Oh, that was never ever my intention (if that's the impression you
got - sorry for not being clear enough). To slaughter "Highlander":
"there can be only one" GUI factory in any application, hence no need
to send signal from Qt to libsigc++ or vice versa.
> This is because libsigc++ is compile-time type-safe while
> Rt is neither ...
^^^^^^^
|||||||
Did you mean to say libsigc++ is run- and compile- time
typesafe? I guess you did.
> ... and because libsigc++ is more flexible than Rt in the
> number and types of arguments you can use for your signals and
> slots.
Yeps, libsigc++ is very cool indeed!
> And, how do you even give an Rt slot three arguments?
It's tricky, but doable.
> > 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.
I was thinking along the lines of, how do you tell the parent and/or
child that is has a new child and/or parent. Memory management is
another (BIG and important) issue.
> 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.
Which is why Gtk-- is so neat.
> 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.
Well, now you have, if you want to be sure that you users can run your
stuff, zero options - use ROOT's rather inflexible style.
I guess it really boils down to the question:
Should ROOT provide a full graphics abstraction, so that user ROOT
GUI code can run on any platfrom, or should ROOT simply implement
the GUIs that ROOT need for all supported platforms, leaving the
user to use the GUI library she prefers.
Personally, I prefer the former, but I think the later is probably the
most reasonable choice (graphics libraries are rather good at what
they do - and ROOT sure could use a SQL query mechanism).
> Anyways, this is all probably more than you wanted to read...
No, not at all. I really wanted to some more spicy arguments, and you
delivered - thanks.
Yours,
Christian Holm Christensen -------------------------------------------
Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91
DK-2200 Copenhagen N Cell: (+45) 28 82 16 23
Denmark Office: (+45) 353 25 305
Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:04 MET