Dear Peter et al, to end this discussion, let say that I would love to have a TGQt deriving from TVirtualX to provide cross platform canvas graphics. Especially now that Troll Tech has made the Win32 port of Qt available for free for non-commercial apps (only since a few months) this becomes a very attractive proposition (not to talk about Qt v3 which has also native MacOS X support). In addition to TGQt we would need to re-implement, using Qt, the few higher level ROOT GUI components, like: TRootApplication, TRootContextMenu, TRootEmbeddedCanvas, TRootBrowser, TRootControlBar, TRootGuiFactory, TRootCanvas, TRootDialog, TRootHelpDialog, but this is very well doable and would not take more than a few weeks. Making Qt scriptable would also be nice but is not essential for day one. Of course a Qt port will live next to the ROOT GUI classes so the many apps using these widgets will continue to work. Rene and I are taken 100% by other parts of the system so we can not start this work, but we are of course willing to advice and later maintain the code. Anybody interested in starting TGQt? Cheers, Fons. On Saturday 27 October 2001 06:35, 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). > > -- 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