Hi Peter, I am a bit puzzled by all these statements. I've followed reasonable closely Betrand's progress and the results using the gdk-win32 emulation lib looks quite good. This gdk lib is also used to run the GIMP under Windows and that works fine. Betrand even wrote a ROOT GUI based tool using his current port that runs in production at his employer's factory (Alcan formerly AluSuisse). As far as I know there are no thread issues in this port since there are no threads used anymore (Betrand correct me if this is wrong). The major remaining issue is that of the terminal (DOS box) access where the issues you descibe pop up. We hope this can be circumvented by implementing a small terminal emulator directly in the GUI (which also can be embedded in the GUI like in Visual Studio) to avoid the thread issues between the app and the DOS box. We had hoped Thane could have helped here. We noticed indeed some performance issues in the TCanvas based graphics. Betrand is profiling the code to see where the bottleneck is. The canvas uses a relatively small subset of the TVirtualX interface so we hope that going direct to win32 calls there will improve the situation. The performance for the GUI itself is more than adequate and orders of magnitude better than Java/Swing. We've looked at other toolkits too in the beginning. First of all wxWindows is a lowest common denomintator x-platform lib and when we looked at it 3-4 years ago it was not acceptable at all. Qt at that time was not free for X11 let alone Win32. Qt has in common with our approach that it build a GUI from first principles, just using basic X11 or Win32 calls (not by using higher level widget as provided in Xt, Motif or Win32 controls). Therefore I do not see why we should not be able to achieve what Qt has achieved on Win32. They also did not rewrite the complete X11 layer to accommodate Win32. And concerning gtk/gdk, well that is exactly what we are doing on Windows, using the gdk-win32 lib, so I can not imagine what we would have gained here by using gtk also for X11 (plus it did not exist in a mature form 3-4 years ago). The whole Win32 GUI issue is taking so much time since no Win32 hackers ever stepped forward to help Betrand. Open Source development in the Win32 world is just very rare and not an accepted way of working, it seems. Further Betrand is doing all this next to his daily Alcan job where as process informatics engineer he is on 24x7 call to keep a large Aluminium foundry running. Rene and I have no time to spent on the Win32 port, so we need this help from the community. All help is appreciated and welcome, but I don't buy the argument that we should rewrite the complete GUI system just to be able to accomodate the Win32 port. This does not mean that we would not allow WIN32 ifdefs in certain higher level parts of the code, but a rewrite, no. Cheers, Fons. Peter Lipa wrote: > > 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. -- 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