Guys, thanks for the animated GUI discussion. Some remarks:
- The ROOT GUI provides a convenient scriptable default GUI environment
supporting modern event handling techniques (signal/slots).
In a not too distant future it will be truely cross-platform when
the win32 version will be released. Currently it mainly lacks:
- extensive documentation
- better type checking in the signal/slots mechanism
- gui builder
- skins
And we plan on fixing these omissions (in order listed).
- QtROOT will allow embedding of ROOT canvas based graphics in Qt.
This should make all Qt hackers happy.
- GtkROOT (Brett?) will allow embedding of ROOT canvas based graphics
in Gtk. Should make all Gtk hackers happy.
- Main difference between ROOT's signal/slots vs. libsigc++:
- libsigc++ is type safe but requires tight compling of the
signals to the slot methods (compile time binding)
- lacks typesafety, but allows total decoupling of signals from
the slot methods (run-time method lookup, which allows
Java bean like component programming)
Both have their pro and cons.
Cheers, Fons.
Brett Viren wrote:
>
> Christian Holm Christensen writes:
> >
> > 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.
>
> Not Qt to libsigc++, but Rt to Qt or Rt to libsigc++. I understood
> you to be suggesting interface Rt to Qt's (or alternatively, Gtk--'s)
> signal/slot mechanism. I am saying it would be difficult to connect
> Rt on the ROOT side to libsigc++ on the Gtk-- side in any general way
> with out severely limiting what kind of sig/slots can be used on the
> Gtk-- side.
>
> However, one could entertain the notion of ripping out Rt everywhere
> in ROOT and replacing it with libsigc++....
>
> >
> > > 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.
>
> No, sorry, I was a little unclear. I was just issuing my standard
> complaint about Rt: It doesn't allow for type safe connections and any
> little errors (such as typos in the strings you must pass, forgetting
> to add the slotted class to LinkDef.h, etc) must show up only at run
> time, if they show up at all.
>
> Since libsigc++ is template based the compiler fails/warns if there
> are type mismatches. And since the signal connection is not based on
> passing strings, but real live objects, a typo is caught immediately.
>
> ...
>
> > 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).
>
> Yes, this is the question (although I don't understand the reference
> to SQL queries, maybe something in Qt?).
>
> But, I think the answer to this "A or B" question is "yes", that is,
> "both". And, thankfully, this is looking like what we will get (via
> QtROOT's trail-blazing).
>
> > > 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.
>
> Heh, my pleasure. Although, I didn't mean to be inflammatory.
>
> -Brett.
--
Org: CERN, European Laboratory for Particle Physics.
Mail: 1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248
WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7679480
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:04 MET