Hello some comments,
> Qt has in common with our approach that it build
> a GUI from first principles, just using basic X11 or Win32 calls (not by
I have not evaluate Qt too deep. However I found it is extremely attractive nowadays.
> using higher level widget as provided in Xt, Motif or Win32 controls).
It seems to me it is not true they do use the highest possible level the "operating system +
video hardware" provided it doesn't affect the Qt general design.
They claim:
http://www.trolltech.com/products/qt/index.html
QT: Native Look & Feel: Qt-based applications have the native look and feel
of whatever platform they run on.
ROOT: Provide ROOT custom Windows-95 look and feel.
QT: Performance: There is no performance hit incurred by using Qt.
Qt is not based on operating system emulation or run-time interpretation.
Qt-based applications are native, compiled C++ applications on each platform.
Qt-based applications run at least as fast as applications written with those toolkits.
The memory footprint is also the same.
For example the generic implementation of QFiledialog class is 164 K source file, however
the WIN32 implementation of that class is 13 K only.
QFontdatase is 41 K for the generic case vs 8k for WIN32
They do distinguish Windows Xp and Windows 2000: Like the piece of the code below shows:
case PointingHandCursor:
if ( qt_winver == Qt::WV_2000 || qt_winver == Qt::WV_XP ) {
sh = (unsigned short*)IDC_HAND;
break;
}
This means they do provide several different Qt implementations with the common API
These implementaitons track and try to accomodate and re-use ALL new features all local
OS API + video driver + video hardware
It is very tough task and this just provides an extra proof that Qt team is a great one,
they have very ambitious goals, they do provide very effective solutions for each platform
they support (UNIX, Windows, MAC). Its commercial success, taking in account plenty of
"free implemntation around", provides an extra proof the quality of Qt is extremely high.
> Therefore I do not see why we should not be able to achieve what Qt has
> achieved on Win32.
I do see.
Fons just compare the size of the Qt share library and libGUI + TVirtualX + TVirtualPad + TSystem
share libraries then compare the functionality they provide.
http://www.trolltech.com/products/qt/whitepaper/whitepaper.html
(I know ROOT share library are large due CINT dictionary inside, That dictionary should be taken
in account during the comparisons)
For example no way ROOT can support what Qt Linguist does.
(see: http://doc.trolltech.com/3.0/linguist-manual.html
http://www.trolltech.com/products/qt/whitepaper/whitepaper-8.html
)
> They also did not rewrite the complete X11 layer to
> accommodate Win32.
Sure they did this but not for the sake of WIN32 rather to provide "Embedded Qt".
They claim:
" . . . Qt/Embedded installs and runs with a very small memory
footprint on any device running embedded Linux - without using X11. . . "
(see: http://www.trolltech.com/products/embedded/index.html )
> 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.
I did not see anybody suggestes you to RE-WRITE any code.
(And by the way not for the sake of Win32 rather for the sake of MAC)
Probably I missed things.
The point of the thread (as I understood this discussion) is whether one needs
to ADD one extra implementation of TVirtualX class that allows to use Qt feature and
use ROOT on MAC platform too. They may require some #ifdef Qt" though
for " . . . certain higher level parts of the code . . . "
Cheers, Valeri
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:04 MET