Re: [ROOT] Windows Graphics/GUI - RE: More on Graphics abstraction (was Re: [ROOT] Qt ROOT)

From: Brandon Kohn (blkohn@hotmail.com)
Date: Fri Oct 26 2001 - 13:23:28 MEST


Why hasn't java/swing been considered for a GUI layer?  JNI is quite good,
and programming java GUIs is a joy.  Seems to me that this is the most
obvious platform neutral answer to the gui problem (provided all algorithms
are implemented in native c and called via JNI). Are there reasons that Java
has not been considered?

Brandon

----- Original Message -----
From: "Peter Lipa" <lipa@nsma.arizona.edu>
To: "'Fons Rademakers'" <Fons.Rademakers@cern.ch>
Cc: <roottalk@pcroot.cern.ch>
Sent: Thursday, October 25, 2001 10:00 PM
Subject: [ROOT] Windows Graphics/GUI - RE: More on Graphics abstraction (was
Re: [ROOT] Qt ROOT)


> 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