Dear Fons,
Taking the risk to start one another flaming war between linux and Win32
platform users, I would like to verbalize my humble opinion/experiences on
the root graphics issue:
1) one fanatastic thing about the basic root design was its platform
independence and the support of both unixes and windoze (and even palm
pilots as I understand).
2) Up to now there are few root apps outside HEP even though many different
fields have also huge amounts of data to process/histogram/analyse. I just
name Quantitative Finance and Neuroscience among many other potential
candiates.The latter fields unfortunately have a large user base in the
Windoze world - its a fact we have to live with (flamers - please don't
educate me about the "evil empire" and such - we all have our reasons and
they are not always in each users control).
In our neurophysiology lab I've been trying to make the case for root as
foundation of data storage and analysis (in competition to matlab) but the
inability to produce portable stand alone root GUI applications that can run
on solaris, linux and Win32 made my efforts futile (so far). I can imagine
that other labs/organizations looked at root and abandoned it for just the
same reason.
In fact, I've been hoping against hope that the Win32 GUI/Graphics will be
merged soon since several years (I think it was 97 when you announced the
GUI classes and that the Win32 version will follow in 6 months when Valery
finds the time to implement the TGWin32 class ). Fact is, that it is now
fall of 2001 and the circumstances are such that the linux and root versions
keep diverging.
Trying to accelerate things, my colleague Thane and I contacted Bertrand
Bellenot, inquired about the status of his work and offered some help. We
(in fact it was mostly Thane) looked
at Bertrands code, got it to kinda work with the interpreter, and came to
the conclusion that A) it will probably never work properly and B) even if
it kinda works (with random crashes that windows users are anyway accustomed
to) it will be VERY inefficient.
To quickly summarize the problems we saw:
1) Betrand replaced each X-call in TGX11 with a call to the gdk X-emulator
lib.
That is pretty straight forward, but those libs are quite inefficent. We
could live with that, but unfortunatley these libs are NOT thread safe. We
got Bertrand's code running,
both in compiled and cint interpreter (with very dirty tricks), but it keeps
crashing at random times due of internal conflicts steming from root running
in multiple treads. The authors of gdklib explicitly state that the lib is
not threadsafe and
are not intended to be used in multithreaded environments.
2) The interpreter environment and Windows consoles have very peculiar
properties in particular what they do with stdin and stdout. The main
problem in Windows is that
a Console (cmd.exe) is NOT a normal window in windows. Events related to the
console are NOT
dispached through the normal windows API so you can't prosses console events
(commands etc)
in the same event loops as any other Windows(e.g graphics output or Win32
GUI) window.
I don't want (and can) elaborate here on all the fundamental problems we saw
with Bertrands approch. (Thane wrote a detailed email to Bertrand,
explaining why we give up on that approach and stating more precisely why we
think it can't ever work properly (without random crashes) with the current
state of gdklib.)
The point HERE is that we now are pretty sure that there won't be a TGWin32
class working with TGVirtualX (and that means no Windows-linux GUI/Graphics
merger) in the near future. Not without rethinking the whole multi-platform
approach from scratch.
IMHO the root developers are left with following choices:
1) implement TGWin32 with native Win32 API calls, and reimplement the TRint
class so that
it works better with windows consoles' stdin and stdout peculiarities (or
even better, get rid of the windows console (cmd.exe), and create a Windows
application that acts as a console (but
is actually a normal windows window and follows the normal event dispatching
API).
Problem with that is that there is no volunter for a estimated 1 manyear
project of this kind.
2) Make another graphics abstraction layer (as was discussed in this thread)
based on a truly portable graphics/gui environment such as Qt or wxWindows
(the latter one is free and open source - but I can't state any preference
since I haven't any experience in either ).
If you base root graphics on a portable graphics layer, the windows port
should be straight forward.
In any case, the point I would like to raise here is:
If you debate a Graphics abstraction layer, PLEASE take into account the
Win32 Graphics layer
is on a dead end (in all probability) and in desperate need of a solution.
And Fons, if you haven't spoken to Bertrand lately, please do so and get the
first hand info
on the status and prospect of a linux-win32 merger. Your message below
sounds as if
you believe this merger is around the corner and the Qt, gdk--, wxWindows
etc debate
is overkill.
I think that debate is very necessary and should contain the desparate
Windows situation.
Just my 2 cents.
Humbly,
Peter Lipa
(forced windows user)
****************************************************************************
Peter Lipa, PhD e-mail: lipa@nsma.arizona.edu
Arizona Research Labs - Neural Systems, Memory and Aging
University of Arizona
Life Sciences North Bldg, Room 384; Phone: (520) 626-3101
Tucson, AZ 85724-515 Fax: (520) 626-2618
****************************************************************************
-----Original Message-----
From: Fons Rademakers [mailto:Fons.Rademakers@cern.ch]
Sent: Thursday, October 25, 2001 2:03 AM
To: Brett Viren
Cc: Christian Holm Christensen; roottalk@pcroot.cern.ch
Subject: Re: More on Graphics abstraction (was Re: [ROOT] Qt ROOT)
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.
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:04 MET