Dear Fons (and Valery), Fons, I didn't know that Valery and you had this discussion before. It surprises me, that the insights of the only person on the planet who knows both root AND Win32 inside out - Valery's - aren't taken seriously. This way we wasted 2 months of intense trial and error to find out what Valery knew all along.... What Valery, Thane and I are trying to tell you is that the gdklib's in the current state are not suitable for root graphics/GUI. The lib is not threadsafe and crashes at random times. About the Windows open source community not helping: Thane spent 2 months FULL TIME (and that means often 16 hrs workdays) to absorb root and help to get Bertrands port working in the interpreter (for standalone compiled code you don't have the complexity of the separate console thread stealing stdin and stdout and Bertrands port worked kinda OK - with crashes here and there). As I said - Thane GOT it to work WITH the interpreter by circumventing the native windows cmd.exe console and making a new terminal window that grabs stdin and stdout from various places of TRint. That requred some modifications in TRint. That extra terminal window runs in an extra thread (he tried hard to do it in the main thread but it never worked - you've to ask Thane about the details). Thane gave his solution and code back to Bertrand. However, even with these tricks the graphics often got hung or crashed or updated at the wrong times (you had to hit return several times in the interpreter to get a graphics window update, etc) and we traced those crashes down to gdklib not being thread safe. Fons, you argure that we can get rid of the extra thread(s) and do everything in one thread only, but then you'll never have multithreaded support on windows platforms and the TThread classes will never work on windows. And we are back 10-15 years in software technology. This is why we finally made the decsision to not pour any more time and money into this gdklib route when we are pretty sure that it will not work properly (with the current gdklib version). In short - there WAS help, even from a private company (Thane works for Neuralynx.com who collaborates closely with my lab! However, after 2 months of hacking code written by programmers who think and design primarily for unix platforms, the project was declared as undoable (in a proper way) with a reasonable amount of time, effort and cost. The root deverlopers (besides Valery) can not design a very complex (almost a new OS!) application for unixes and expect the daunting task of a windows port to be "contributed" by the "windows open souce community" or even by a single person in his free time besides a demanding full time job. (I understand that the actual port was supposed to be done by someone else and Bertrand just offered to help some, but that 3rd person bailed out and Bertrand was left alone ....). The fact is that root graphics/GUI is DESIGNED for unix and NOT windows and a "port" is EXTREMELY HARD without rethinking some of the basic root-graphics and root-console architectures. IMHO it is THIS fact that kept the windows open source community from tackling that task and NOT that this community doesn't exist or want to contribute. (As a note, seeing in the code what kind of tricks needed to be done to get the 'old' root graphics working under windows - I now have great admiration for Valery and his achievements ....) About your statement "This gdk lib is also used to run the GIMP under Windows and that works fine.": As an answer I'd like to quote from the GIMP website as of today, and you get a taste of what the root Win32 port (gdklib version) will look like: ------ quote Warnings The Windows version is GIMP 1.2. The base GIMP code should be relatively bug-free. The Windows code without doubt has bugs, though. The GIMP for Windows is not really targetted at end-users yet. The program(s) might crash unexpectedly or behave otherwise strangely. (But of course, so do many commercial programs on Windows.) The stability seems to depend a lot on the machine, display drivers, other software installed, and whatnot. Presumably the more memory you have, the better GIMP works. (For any real image work, I would say 128 megabytes is minimum.) Many people do find GIMP very useful. But it is not a Photoshop killer (for real Photoshop users, that is), Photoshop has lots of features that the GIMP lacks. 256-colour mode doesn't work, and GIMP will not start if you try. Use at least HiColor (thousands of colours, 16-bit colours). (Stick to Paintbrush if you feel like complaining about that.) TrueColor (millions of colours, 24- or 32-bit colours) is a must for serious work, of course. Many people with ATI Rage Pro cards have complained about display errors. It seems that this is a known problem with the drivers for these cards, and can be worked around by setting DEVBMP=0 in the [display] section of the Windows system.ini file, like this: [display] DEVBMP=0 If you have NT 4, and a Microsoft Wheel Mouse, some people tell me GIMP hangs unless you remove the mouse icon from the taskbar, or update the mouse software to the latest version. Go figure. ------ endquote And this is probably just the tip of the iceberg .... Last not least: with the gdklib approach you'll never have root behave like a windows application with e.g. drag/drop support and copy/paste/print of canvases directly from a canvas into e.g. a word document or powerpoint presentation. You'll always have to go through (often huge) eps files (with all the various eps cross-application compatiblity problems). This way root will always be a unix application that sort of also happens to run somehow on windows (like GIMP) and if you have some background in unix you might be able to eventually understand how root works. A root GUI application written by more savvy programmers for 'naive' windows users (e.g. biologists, physiologists, data analysts) will never have properties the windows users expect (e.g print a canvas directly to my nonpostscript deskjet printer). IMHO, this is BAD design (better: bad MULTPLATFORM design). Especially in days and times when other people/groups put in already a lot of effort to make true multiplatform applications possible. ( I understand very well that these tools were not available in 1996!!). Qt appears to be the prime candidate, but wxWindows was redesigned since 1997 and gets quite some good commentaries too. (I know neither well enough to judge or recommend a solution here!). Java probably creates more problems than it solves (in my personal experience with Java and JNI). Fons, I never said "rewrite the whole damn thing!". I am asking KINDLY to rethink the gdklib port of the root GUI/graphics classes to Win32. As Valery and others said, why try to emulate in a ROOT-only-GUI what Qt, wxWindows or other cross-platform libs do already masterfully, when one could just USE these tools, developed by many savy people full time over many years? Do I miss something here? What it probably comes down is either: A) Root developers get so annoyed with Win32 that they stop supporting it. B) Or they'll just say: if you want a fully functional root on windows, use the cygwin X version. I hope I am wrong here.... All the best Peter PS: All the Qt <--> root talk in this tread is about the linux/unix Qt-root future only. None of the Qt-root developers plans to make their code cross platform in the near future. Bertini's QtRoot classes don't and probably won't work under windows without deep changes in root-graphics and root-console layers. My pledge here is that IF there is already effort to make another TVirtualX implementation in Qt, then PLEASE go the short extra mile to include a final solution for root on Win32 (even if it includes commercial code such as Qt). -----Original Message----- From: Fons Rademakers [mailto:Fons.Rademakers@cern.ch] Sent: Friday, October 26, 2001 2:03 AM To: Peter Lipa Cc: 'roottalk@pcroot.cern.ch' Subject: Re: [ROOT] Windows Graphics/GUI - RE: More on Graphics abstraction (was Re: [ROOT] Qt ROOT) 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