Qt/root, Qt-GSI and Qt-BNL

ROOT
#1

Hi all,

I have a few questions on Qt/root.

  1. What are the differences between Qt-GSI and Qt-BNL?

  2. Is it possible to enable only one of the two Qt options?
    And, how?

    I’ve tried with the following, but both qt and qtgsi are enabled (root v5.22.00 on Fedora 10 x86_64).

./configure linuxx8664gcc --enable-ruby --enable-explicitlink --enable-minuit2 --enable-gdml --enable-qtgsi --disable-qt --with-qt-incdir=/usr/include --with-qt-libdir=/usr/lib

  1. Are version 3.x of Qt supported?

    It seems that the root configure script looks for Qt/qglobal.h, but I’ve never succeeded in configuring recent root software with Qt 3.x on my linux/FreeBSD boxes (Fedora 10, SLC 5.2, FreeBSD-{6,7}.x-RELEASE) on which packages of Qt-3.x development kits/ports are installed.

On these sysmtes qglobal.h reside in: /usr/lib{,64}/qt-3.3/include and /usr/local/include/; i.e. paths w/o “Qt”.

Yours,
Kazuyoshi

#2

[quote=“furutaka”]1. What are the differences between Qt-GSI and Qt-BNL?[/quote]I do not know much :blush: about the current status of QtGSI. The page root.bnl.gov/QtRoot/QtRoot.html#publications.
Please, pay your attention that ROOT Manual ( ftp://root.cern.ch/root/doc/26ROOTandQt.pdf ) tells about two use case scenarios

[quote]“ROOT-based Qt-application"
and
"Qt-based ROOT application”. [/quote]
From Qt application stand point QtRoot (BNL) provides the native Qt widget (C++ class, one can subclass it to customize, for example) as a backend of the TCanvas objects.

From the ROOT application stand point it provides the set of the native ROOT plug-ins those can be turned on / off as needed.

That allows to integrate ROOT (embedded TCanvas ) into Qt application and use any Qt widgets and Qt classes within ROOT applications as well. For example, you can use Coin3D-based ROOT plug-in to visualize ROOT 3D classes. For Qt classes one can build the RootCint dictionary and use it from the ROOT command prompt etc. etc. (see for example rhic.bnl.gov/RCF/UserInfo/Me … chMeet.ppt )
With a few lines of the code you can do something like this
root.bnl.gov/QtRoot/pictures/HelloGlViewer.gif from your ROOT command prompt. QtROOt should be compatible with QtGSI applications because it provides the C++ class with QtGSI interface.

QtGSI doesn’t change the TCanvas X11-based backend. It embeds the X11 widget into the QtGSI applications

[quote=“furutaka”]2. Is it possible to enable only one of the two Qt options?[/quote]In theory, yes. There is no depedency between these two versions. [quote=“furutaka”]And, how?[/quote]Someone needs to adjust the “configure” script. To do that one needs a clear idea what is wrong with the current implementation.
As soon as QtRoot(BNL) is concern, the BNL Qt-layer is provided as the native ROOT plug-in . As such, it can be built separately against of any ROOT release to complement it.

[quote=“furutaka”]3. Are version 3.x of Qt supported?[/quote]No. However, you can check out the Qt3 compliant version of QtROOT plug-in from BNL CVS. You can build that plug-in against of your regular ROOT version. It should work. But it is provided “as is”. It is not supported.

#3

This message was removed because it did duplicate the previous one

#4

Hi all,

Thanks Vareli for your followup.

[quote=“fine”]
From Qt application stand point QtRoot (BNL) provides the native Qt widget (C++ class, one can subclass it to customize, for example) as a backend of the TCanvas objects.

From the ROOT application stand point it provides the set of the native ROOT plug-ins those can be turned on / off as needed.

That allows to integrate ROOT (embedded TCanvas ) into Qt application and use any Qt widgets and Qt classes within ROOT applications as well. For example, you can use Coin3D-based ROOT plug-in to visualize ROOT 3D classes. For Qt classes one can build the RootCint dictionary and use it from the ROOT command prompt etc. etc. (see for example rhic.bnl.gov/RCF/UserInfo/Me … chMeet.ppt ) [/quote]

I’d be really very happy if I can build applications with both Qt and ROOT, because it makes it even easier I think. But…

[quote=“fine”]

[quote=“furutaka”]2. Is it possible to enable only one of the two Qt options? And, how?[/quote]In theory, yes. There is no depedency between these two versions. However, someone needs to adjust the “configure” script. To do that one needs a clear idea what is wrong with the current implementation.
As soon as QtRoot(BNL) is concern, the BNL Qt-layer is provided as the native ROOT plug-in . As such, it can be built separately against of any ROOT release to complement it.

[quote=“furutaka”]3. Are version 3.x of Qt supported?[/quote]No. However you can
check out the Qt3 compliant version of QtROOT plug-in from BNL CVS. You can build that plug-in against of your regular ROOT version. It should work. But it is povided “as is”. It is not supported.[/quote]

I asked the questions above because my root executable, built successfully for example with the following configuration (without the “Qt extension”), after displaying miserable-looking (just like root-native one but distorted) TBrowser, crashes my X server (and terminates my X session), and I want to try to figure it out why by breaking down possible causes.

An example of my root configuration (on a machine running Fedora 10 x86_64, Athlon64x2):

linuxx8664gcc --enable-ruby --enable-explicitlink --enable-minuit2 --enable-gdml --enable-qt --with-qt-incdir=/usr/include --with-qt-libdir=/usr/lib64

The crashing occurs also on another machine (Athlon64x2, running i386 version of Fedora 10). On my notebook PC (Panasonic Let’s Note CF-W2) running Fedora 10, id doesn’t crash (with long error messages though).

I don’t think it’s due to Qt/Root, because on the machines on which X servers are terminated by qt-enabled-root, even KDE 4 crashes just after a single click on the root window (desktop) without invoking the qt-enabled-root executable. :imp: Therefore I suspect that the origin of the crash is brought by Qt4 itself or Qt4 of Fedora 10.

At this moment I couldn’t test it on other linux distros/OS (FreeBSD [67]-stable) because it doesn’t compile: even on Scientific Linux 5.2 (x86_64), because it requires Qt version older than 4.3. (For the test I use virtual machies on VMware Workstation. The crash occurs on REAL machines.) In another thread of this forum I read your post on the difficulties of maintaining the code to adopt to many versions of Qt, and I do agree, but…

I just want to find some linux distributions on which we can run Qt(4) enabled root successfully. Are there any REFERENCE distros for BNL-Qt/root? On what OS are you developing it?

By the way, I have another trouble on Qt-enabled-root (one on my Let’s Note running Fedora 10 i386 (built by myself), and even with a binary for Windoze distributed from BNL, root5.18.00.exe, on Windose Xp SP3): it doesn’t cause crashes but I couldn’t open root files from the root object browser.

Yours,
Kazuyoshi

#5

I have to correct:

The version of the latest(?) ports on FreeBSD is 4.4.3, and it doesn’t compile due to errors related to QBrush and QPalette:

In file included from graf2d/qt/src/GQtGUI.cxx:17: include/TQtWidget.h: In member function 'int TQtWidgetBuffer::Height() const': include/TQtWidget.h:89: error: 'class QPaintDevice' has no member named 'height' include/TQtWidget.h: In member function 'int TQtWidgetBuffer::Width() const': include/TQtWidget.h:90: error: 'class QPaintDevice' has no member named 'width' graf2d/qt/src/GQtGUI.cxx: In member function 'virtual void TGQt::NextEvent(Event_t&)': graf2d/qt/src/GQtGUI.cxx:904: error: 'QCoreApplication' has not been declared graf2d/qt/src/GQtGUI.cxx: In member function 'virtual Window_t TGQt::CreateWindow(Window_t, Int_t, Int_t, UInt_t, UInt_t, UInt_t, Int_t, UInt_t, void*, SetWindowAttributes_t*, UInt_t)': graf2d/qt/src/GQtGUI.cxx:1322: error: 'Window' is not a member of 'QPalette' graf2d/qt/src/GQtGUI.cxx:1322: error: no matching function for call to 'QBrush::QBrush(QPixmap&)' /usr/local/include/qbrush.h:55: note: candidates are: QBrush::QBrush(const QBrush&) /usr/local/include/qbrush.h:54: note: QBrush::QBrush(const QColor&, const QPixmap&) /usr/local/include/qbrush.h:53: note: QBrush::QBrush(const QColor&, Qt::BrushStyle) /usr/local/include/qbrush.h:52: note: QBrush::QBrush(Qt::BrushStyle) /usr/local/include/qbrush.h:51: note: QBrush::QBrush() graf2d/qt/src/GQtGUI.cxx:1325: error: 'class TQtClientWidget' has no member named 'setBackgroundRole' graf2d/qt/src/GQtGUI.cxx:1325: error: 'Window' is not a member of 'QPalette' graf2d/qt/src/GQtGUI.cxx:1329: error: 'Window' is not a member of 'QPalette' graf2d/qt/src/GQtGUI.cxx:1332: error: 'class TQtClientWidget' has no member named 'setBackgroundRole' graf2d/qt/src/GQtGUI.cxx:1332: error: 'Window' is not a member of 'QPalette' graf2d/qt/src/GQtGUI.cxx: In member function 'virtual void TGQt::ClearArea(Window_t, Int_t, Int_t, UInt_t, UInt_t)': graf2d/qt/src/GQtGUI.cxx:1923: error: no matching function for call to 'QBrush::QBrush(const QPixmap&)' /usr/local/include/qbrush.h:55: note: candidates are: QBrush::QBrush(const QBrush&) /usr/local/include/qbrush.h:54: note: QBrush::QBrush(const QColor&, const QPixmap&) /usr/local/include/qbrush.h:53: note: QBrush::QBrush(const QColor&, Qt::BrushStyle) /usr/local/include/qbrush.h:52: note: QBrush::QBrush(Qt::BrushStyle) /usr/local/include/qbrush.h:51: note: QBrush::QBrush() graf2d/qt/src/GQtGUI.cxx:1927: error: 'Window' is not a member of 'QPalette' graf2d/qt/src/GQtGUI.cxx: In member function 'virtual void TGQt::ClearWindow(Window_t)': graf2d/qt/src/GQtGUI.cxx:2305: error: no matching function for call to 'QBrush::QBrush(const QPixmap&)' /usr/local/include/qbrush.h:55: note: candidates are: QBrush::QBrush(const QBrush&) /usr/local/include/qbrush.h:54: note: QBrush::QBrush(const QColor&, const QPixmap&) /usr/local/include/qbrush.h:53: note: QBrush::QBrush(const QColor&, Qt::BrushStyle) /usr/local/include/qbrush.h:52: note: QBrush::QBrush(Qt::BrushStyle) /usr/local/include/qbrush.h:51: note: QBrush::QBrush() graf2d/qt/src/GQtGUI.cxx:2309: error: 'Window' is not a member of 'QPalette' gmake: *** [graf2d/qt/src/GQtGUI.o] Error 1 rm core/utils/src/RStl_tmp.cxx core/utils/src/rootcint_tmp.cxx

The version Fedora 10 provides is also 4.4.3 (on my machine I use a binary package, qt-devel-4.4.3-10.fc10.x86_64): it compiles, it crashes…

Yours,
Kazuyoshi

#6

Hi all,

A relaxed time in a bath tub reminded me of another difference between machines on which KDE and Qt-enabled-root crashes X and a machine on which they don’t: the former (both i386 and x86_64) were updated from the previous version of Fedora (9) while on the latter Fedora 10 was freshly installed (because attempts of the upgrade failed and the machine was left as an indefinite mixture of Fedora 9 and 10).

I’ll see whether KDE4 and Qt(4)-enabled-root crashes or not on another freshly installed F10 (on a virtual machine using VMware Workstation), and if it doesn’t I’ll then try on a REAL machine.

Yours,
Kazuyoshi

#7

Hi all again,

I have to clarify further… (sorry to bother again)

On the notebook (Fedora 10 i386), I did two tests.

The first is to build root_v5.22.00 with the following configuration and w/o Qt extension:

[quote]linux --enable-ruby --enable-explicitlink --enable-minuit2 --enable-gdml --enabl
e-qt --with-qt-incdir=/usr/include --with-qt-libdir=/usr/lib[/quote]

The executable built with the above configuration, with Gui.Backend: qt and Gui.Factory: qt in ~/.rootrc, shows terrible looking object browser as the attachment, and sometimes the root process is crashed (I’m still not sure when it crashes). .root files can be open by clicking icons in the browser (though it’s difficult to select the correct icon because of the terrible look). Canvases are not distorted.

I’ve also tested version 5.22.00 of root built with both Qt layer and Qt extension by using the INSTALL_QTROOT.sh: it shows beautiful browsers with Qt widgets, although I can’t open .root files by clicking their icons in the browser.

distorted-browser.png606×526 167 KB

#8

Hi again,

[quote=“furutaka”]On the notebook (Fedora 10 i386), I did two tests.

The first is to build root_v5.22.00 with the following configuration and w/o Qt extension:

[quote]linux --enable-ruby --enable-explicitlink --enable-minuit2 --enable-gdml --enabl
e-qt --with-qt-incdir=/usr/include --with-qt-libdir=/usr/lib[/quote]

The executable built with the above configuration, with Gui.Backend: qt and Gui.Factory: qt in ~/.rootrc, shows terrible looking object browser as the attachment, and sometimes the root process is crashed (I’m still not sure when it crashes). .root files can be open by clicking icons in the browser (though it’s difficult to select the correct icon because of the terrible look). Canvases are not distorted.

I’ve also tested version 5.22.00 of root built with both Qt layer and Qt extension by using the INSTALL_QTROOT.sh: it shows beautiful browsers with Qt widgets, although I can’t open .root files by clicking their icons in the browser.[/quote]

I noticed that Gui.Factory: value in $ROOTSYS/etc/system.rootrc of the latter is “qtgui” instead of “qt”, and have changed the corresponding setting for the former (via $HOME/.rootrc"): this time I couldn’t instantiate any browser object, i.e. nothing appeared after the following “Symbol font family found:” message.

[code][furutaka@alex ~]$ root

  •                                     *

  •    W E L C O M E  to  R O O T       *

  •                                     *
  • Version 5.22/00 17 December 2008 *
  •                                     *
  • You are welcome to visit our Web site *
  •      http://root.cern.ch            *

  •                                     *

ROOT 5.22/00 (trunk@26997, Jan 14 2009, 21:51:00 on linux)

CINT/ROOT C/C++ Interpreter version 5.16.29, Jan 08, 2008
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0] TBrowser b;
** $Id: TGQt.cxx 26689 2008-12-06 07:03:04Z brun $ this=0x99169b8
Symbol font family found: Standard Symbols L
root [1] [/code]

Kazuyoshi

#9

On a freshly installed Fedora 10 i386 (on a VMware-Workstation virtual machine), neither KDE4 nor Qt(4)-layer-enabled-root crashes X server, as guessed.

I’m going to see whether they crashes the one installed on a real machine next week.

Kazuyoshi

#10

Sorry, forgot to mention…

It doesn’t bring me a browser with Gui.Backend: qt and Gui.Factory: qtgui, either…

Kazuyoshi

#11

Hi,

This will be my last post this evening.

The attached is the result of opening the $ROOTSYS/tutorials/hsimple.root file by clicking its icon in a object browser brought by a copy of Qt(BNL)root binary (root5.18.00.exe, installed under C:\BNL\ROOT directory.

The system is:
Microsoft Windows XP, Home Edition, Version 2002, Service Pack 3,
AMD Athlon™ Xp 2600+, 2.09 GHz, 1.00 GB RAM

Kazuyoshi

qt3root.png1280×1024 184 KB

#12

Hi,

Another note: on one of the crashing environments, with “Gui.Factory: qtqui” instead of “qt”, no crash occurs after instantiating a TBrowser object, but no browser appears either (as the freshly installed machines).
When I try to get a canvas, the following message appered and the root process was terminated:

root [1] TCanvas c Error in <TGQt::TGQt::CopyPixmap>: Wrong TGuiFactory implementation was provided. Please, check your plugin settings root.exe: graf2d/qt/src/TGQt.cxx:1282: virtual void TGQt::CopyPixmap(int, int, int): Assertion `dst != (QPaintDevice *)-1' failed.

What are wrong with my settings?

Kazuyoshi

#13

[quote=“furutaka”]I don’t think it’s due to Qt/Root, because on the machines on which X servers are terminated by qt-enabled-root, even KDE 4 crashes just after a single click on the root window (desktop) without invoking the qt-enabled-root executable. :imp: Therefore I suspect that the origin of the crash is brought by Qt4 itself or Qt4 of Fedora 10.[/quote] :open_mouth: At this point I would suspect you got several :bulb: Qt versions on your machine and all of them are on your LD_LIBRARY_PATH/PATH or something as simple as that.

I did see your others messages. However I had not had a chance yet to go through.

Anyway, may I suggest to continue this thread via the dedicated lists.bnl.gov/mailman/listinfo/qt-root-l list?

To minimize the “guess job” may I ask you to install all components you are going to use with INSTALL_QTROOT.sh script root.bnl.gov/QtRoot/How2Install4Unix.html?

PS. I have read some of your other messages and paid my attention you had applied the script I recommend and you did get the smoothly working version. May I suggest we just stick with that and will not discuss your other troubles within this thread? Let’s separate things and discuss how to use Qt with ROOT. You may wish to initiate another thread “How to get the proper Qt version on Linux”. However, I think the ROOT forum is not the best place to seek the assistance with Qt4 installation :roll: .

#14

[quote=“furutaka”]The version of the latest(?) ports on FreeBSD is 4.4.3, and it doesn’t compile due to errors related to QBrush and QPalette:

In file included from graf2d/qt/src/GQtGUI.cxx:17: include/TQtWidget.h: In member function 'int TQtWidgetBuffer::Height() const': include/TQtWidget.h:89: error: 'class QPaintDevice' has no member named 'height' . . . [/quote]This, again, suggests several different Qt versions. The method in question is defined by Qt 4.4 doc.trolltech.com/3.3/qpaintdevice.html

#15

Hi Vareli,

Thanks for your time to follow-up this thread in the Super-Bowl evening! :smiley:

[quote=“fine”][quote=“furutaka”]I don’t think it’s due to Qt/Root, because on the machines on which X servers are terminated by qt-enabled-root, even KDE 4 crashes just after a single click on the root window (desktop) without invoking the qt-enabled-root executable. :imp: Therefore I suspect that the origin of the crash is brought by Qt4 itself or Qt4 of Fedora 10.[/quote] :open_mouth: At this point I would suspect you got several :bulb: Qt versions on your machine and all of them are on your LD_LIBRARY_PATH/PATH or something as simple as that.

I did see your others messages. However I had not had a chance yet to go through.

Anyway, may I suggest to continue this thread via the dedicated lists.bnl.gov/mailman/listinfo/qt-root-l list?[/quote]

Well, but I don’t think it a bad idea to discuss Qt-layer here, because its source code is included in that of root proper. To discuss Qt-extension, which is not yet included in the root source tree, it’s better to move to the qt-root-l… (I’m already a silent/read-only member of the list.) Shall we discuss my crashing of Qt-layer-only executables here and let’s talk about the executables created using the INSTALL_QTROOT.sh script?

Anyway, the first thing I should do may be to remove all the Qt-3.x related libraries from my environment (or set the library search path properly), right? (I’ll do this on my home machine.)

By the way, which one is the correct value for the Gui.Factory: key, “qt” as in the Users Guide?, or “qtgui”?

Ah, one more question… Is the Windoze executable distributed in root5.18.00.exe working properly for example in your environment?

Yours,
Kazuyoshi

#16

Hi Valeri and all other rooters,

Well, I think I didn’t understand and still don’t…

My understanding was that all of the Qt-layer is already included in the root proper and the Qt-extension is only available from BNL, but “Install Qt ROOT layer and Qt Extensions” of http://root.bnl.gov/QtRoot/How2Install4Unix.html reads:

[quote]To add the Qt-layer to your existent X11-version of ROOT you need 3 components:

* The source code of the original ROOT from the ROOT Web site
* The source of the Qt-layer from the BNL Web site
* Qt libraries version 3.3 or higher built with no XFT support. [/quote]

From the above, it seems that the Qt-layer is divided into two parts, one in the root proper and the other in BNL archive… What’s the truth? Can someone make clear what are Qt-layer and Qt-extension and how are they distributed?

Yours,
Kazuyoshi@home

#17

[quote=“furutaka”]Well, but I don’t think it a bad idea to discuss Qt-layer here, because its source code is included in that of root proper. To discuss Qt-extension, which is not yet included in the root source tree, it’s better to move to the qt-root-l… (I’m already a silent/read-only member of the list.) [/quote]Well, QtRoot was born as one single package (check publications) . There were no two separate Qt-layer and Qt-extension at the time. BNL CVS repository does contain both pieces together as one single product. It was not me to split the single QtRoot and create two pieces.[quote=“furutaka”]Shall we discuss my crashing of Qt-layer-only executables here and let’s talk about the executables created using the INSTALL_QTROOT.sh script?[/quote]As soon as you keep posting to this forum I am to keep answering via the RootForum too.
However, I still think it is better to discus QtRoot as one single package and in one single and friendly place.[quote=“furutaka”]Anyway, the first thing I should do may be to remove all the Qt-3.x related libraries from my environment (or set the library search path properly), right? (I’ll do this on my home machine.)[/quote] It is hard to say from far far away how you ended up with some sort of the Qt3/Qt4 mixed installation. Yes, you certainly should check your environment. I would appreciate if you could post your story :wink: and final solution on QtRoot list.[quote=“furutaka”]By the way, which one is the correct value for the Gui.Factory: key, “qt” as in the Users Guide?, or “qtgui”?[/quote]
“qtgui” is to turn the Qt-extensions on.

To be clear:
Gui.Backend “qt” is to turn on the Qt-base TCanvas plug-in.

Gui.Factory “qt” does NOT add any new plugin. Rather activate the ROOT GUI based plugins. It is quite fragile because of ROOT GUI dependency. What you get is really ROOT Gui backed by the low level layer to mimic the low level X11 functionality using the high level package like Qt.

Gui.Factory “qtgui” is turn on the Qt-based ROOT plugins ( see root.bnl.gov/QtRoot/QtRoot.html#what for the list). In addition it provides the bunch of the Qt-based control widgets (C++ classes. It can be subclassed and it can be used with the Qt designer) to be used within Qt-application to set the ROOT graphical attributes. (see: qtRoot/qtExamples/Qt4/CustomWidgets ).

[quote=“furutaka”]Ah, one more question… [/quote]You are :smiley: welcome [quote=“furutaka”]Is the Windoze executable distributed in root5.18.00.exe working properly for example in your environment?[/quote]I am not sure whether I understand your “in your environment” properly. “root5.18.00.exe” self-installed InstallShield binary distribution was built and linked against of Qt 3.3.4. It does include Qt3 DLL. It doesn’t include the Qt-3 development kit (Qt3 was not GPL-ed under Windows. see qtwin.sourceforge.net/qt3-win32/index.php ) ). I’ll upload the new executable (ROOT 5.22) built against of Qt4 this week. Mean time you can use the script to build it yourself. Anyway one needs to build his/her own Qt4 version to build his / her own Qt4 applications. I can create and upload the Qt4.4-based Win32 version. However, I doubt the distribution will contain Qt4 SDK. Either way you should build it alone from Nokia/ TrollTech source.

#18

[quote=“furutaka”]My understanding was that all of the Qt-layer is already included in the root [/quote] Correct. [quote=“furutaka”]the Qt-extension is only available from BNL[/quote]It is not correct :unamused: . From BNL you get BOTH things together. [quote=“furutaka”]“Install Qt ROOT layer and Qt Extensions” of http://root.bnl.gov/QtRoot/How2Install4Unix.html reads:

[quote]To add the Qt-layer to your existent X11-version of ROOT you need 3 components:
…
. What’s the truth?[/quote][/quote]The truth is :exclamation: there was a bug :blush: in the HTML source of the page in question. It exposed the obsolete text. Thank you for your report. The bug has been fixed. Check that page again. I hope you’ll find it less confusing.

[quote=“furutaka”] Can someone make clear what are Qt-layer and Qt-extension and how are they distributed?
[/quote]There is no the separate Qt-extension only distribution.
There are

  • Qt-layer from ROOT CERN as part of the ROOT distribution
  • QtRoot ::= Qt-layer + Qt-extension from BNL CVS.
#19

Hi,

Just a short followup…

Well, but I just faithfully followed the “Qt-layer Configuration” instruction of the “Users Guide 5.21” (December, 2008), p424. :frowning:

I just wanted to know whether it is properly working on someone’s PC…

At home, I’m trying to make KDE4 properly at first, and partly succeeded, but I’m not sure why it is working now (I just removed some leaf Qt-3 libraries and re-configured X.org X). I’ll report when I understand…

Yours,
Kazuyoshi

#20

[quote=“furutaka”][quote=“fine”]Gui.Factory “qt” does NOT add any new plugin. Rather activate the ROOT GUI based plugins. [/quote]Well, but I just faithfully followed the “Qt-layer Configuration” instruction of the “Users Guide 5.21” (December, 2008), p424. :frowning: [/quote] The Manual is correct as soon as Qt-layer is concern.[quote=“furutaka”]…
I just wanted to know whether it is properly working on someone’s PC…
[/quote]You said:[quote=“furutaka”]…
a binary for Windoze distributed from BNL, root5.18.00.exe, on Windose Xp SP3):it doesn’t cause crashes[/quote]What about[quote=“furutaka”] I couldn’t open root files from the root object browser.[/quote] I still need to understand / reproduce that. Again, the best place to ask such question is QtRoot list. There are the QtRoot windows users there to help. CERN doesn’t support QtRoot for Windows.[quote=“furutaka”]At home, I’m trying to make KDE4 properly at first, and partly succeeded, but I’m not sure why it is working now (I just removed some leaf Qt-3 libraries and re-configured X.org X). I’ll report when I understand…[/quote] :confused: What are we speaking about :open_mouth: ? Are we speaking about Windows Win32? Then what is the connection with X.org. Win32 version does not need any X env around to be built and used