Dear Peter Your strange claim that “this is BAD design (better: bad MULTPLATFORM design)” forces an answer from someone who is himself not involved with HEP, but is glad to be able to use the platform-independent ROOT-framework for his own purposes. First, you should remember that ROOT is designed for the HEP community, especially for the LHC (i.e. Large Hadron Collider, to make sure that you know what I mean). ROOT has so many astonishing features that I do not know, where to start. The most astonishing feature is probably the use of CINT as a C++ interpreter. It is hardly believable that it works so well, I could even create my complete GUI from within CINT and afterwards compile it as a standalone application. Forget about Visual-Basic (which was inspired by Apple´s HyperCard), forget about Java (which tries to sell a 20 year old technology, namely the compilation to p-code invented at UCSD to make UCSD-Pascal machine-independent), and which to my knowledge is less crossplatform able than ROOT!!! No less astonishing is ROOT´s possibility to store huge amounts of data as TTree in platform independent root files, which can be accessed locally, over the network, or the Web (TNetFile, TWebFile) in such an easy way. It is great that the ROOT developers have decided to put ROOT in the public domain so that people like you and me can use it for their own purposes. I consider myself a guest of the ROOT community, and I am glad that my questions to roottalk are answered equally comprehensive as the questions the HEP people have. To come back to your claim that ROOT is a “bad MULTPLATFORM design”: It is astonishing how many platforms ARE supported by ROOT with a simple re-compilation of the source code. It seems that ROOT supports more platforms than Java, where you have severe problems writing complex applications, that can run on multiple platforms. The problem of supporting Windows has more to do with MicroSoft not being interested in supporting crossplatform applications, in contrast it seems they do everything to prevent this, as you can easily see by reading the articles on LinuxToday(http://www.linuxtoday.com). As you may know, even many applications written for Windows 95 don´t run on WinNT, and applications written for WinNT often cannot be used with Win98. To give you an example from another great multiplatform public domain project, namely the statistics package “R”: (http://www.ci.tuwien.ac.at/R-project/welcome.html) This project, too, has huge problems supporting Windows, as you can see from the following mail of one of the main R developers taken from the R-help list (r-help@stat.math.ethz.ch): ----------- Subject: Re: [R] Building R with Microsoft Visual C++ From: Peter Dalgaard BSA (p.dalgaard@biostat.ku.dk) Date: Sat Jul 28 2001 - 13:16:56 CEST > I decided to do it by myself, as the impression I got was that everybody was > to busy to help. However, after having wasted the last three and a half > months, I'm forced to come back, cup in hand. I would be very grateful to > hear from anyone who has managed to build R under VC++ 6.0, and even more > grateful, if they could e-mail me a VC project tthat builds R. It would not > be neccessary to include R the source files, since I can download these > myself. What would be useful though, would be the CORRECT tools (I spent > almost a month following links in the very useful Readme files) etc. > > I happened to stumble on R shortly after my Masters degree in Applied > Statistics. I think it's an AMAZING product, and the fact that it is open > source is even more amazing. I take off my hat to all those that helped to > make it a reality. My only gripe is that of "user-friendliness" when it > comes to building R. The impression I get is that this is a closely guarded > secret by old grey haired be-spectapled men in white coats with 50 or more > years of hacking UNIX, who don't have time to explain anything to any one, > and our stuck up in their own little world of academia - Sorry ;-). Well, sixteen years to be precise in my case. However, you need to know that the grey-haired men (some more than others, none of us wear white coats though, and some of us can still manage without reading glasses) *also* gave up on Visual C++ many moons ago. The project file structure of VC++ is simply not strong enough to build the auxiliary files needed for R, and we only achieved the cross-platform portability by using the gnuwin tools. This is simply the traditional clash between two kinds of user-friendliness: making simple things easy vs. making difficult things possible (and automatable). (You can read the book or wait for the movie, but in academia the latter option may require a very long wait!) > This is just the impression I get, and many students I've spoken to have the > same impression and so don't post to this group if they have any queries. I > expect anytime, to have some Professor e-mailing to "tell me off" for being > a naughty boy ! (and to kindly inform me that it's all in the FM!). Well, it is... *provided* you use the suggested tools. Once the tools are installed, you start a shell, go to the relevant directory, type "make" and sit down and watch the magic. This might have taken you three and a half days to get to work and three and a half weeks to begin to understand how it works... If you want to use a different set of tools, in particular a proprietary one, you really can't expect anyone else to jump up and help you out. It might be doable - versions of R for Windows around the 0.50 revision (c.1997) were actually made with VC++ (by Robert), but it usually took him over a month from the Unix releases were made. However, the functionality of R has been expanded considerably since then and I have no clue as to where VC++ stands when it comes to dynamic linking and suchlike. I also think some non-binary items were actually built on Unix and copied across (but my memory is fading). --------------------- As you see, other professional public domain software packages have similar problems as ROOT faces. Since it seems that you are forced to use Windows, please send a mail to MicroSoft and ask them to be more supportive to crossplatform developers. (We all know what their response will be.) One more point. You mention that someone from a private company spent some time to help in the GUI port to Windows, which is great. However, your mail gives the impression that the ROOT developers have to solve the problem since this guy failed. Probably, the company is interested in using ROOT for their own purposes, and the use of ROOT saves them a lot of money. However, you should keep in mind that it is not the task of the root developers or of developers of any public domain project, respectively, to solve problems in the interest of companies. By the way, ultimatively, I would also need to port my GUI application to Windows, if I ever want my currently private project to be used by my colleagues in the company I work for. So you see, I am also interested in a solution to this problem, but I understand that the developers of ROOT have other preferences, since the LHC is around the corner. I apologize if you feel offended by this mail, but someone had to reply to your mail. Best regards Christian ---------------------------------- C.h.r.i.s.t.i.a.n S.t.r.a.t.o.w.a V.i.e.n.n.a, A.u.s.t.r.i.a Peter Lipa wrote: > 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