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