TrollTech Releases Qt 3.0

Dr. Sp0ng writes: "TrollTech released Qt 3.0 today. Among the new features are platform- and database-independent data-access features, data-aware GUI widgets, a much-updated Qt Designer, and much better internationalization and font handling features. It breaks binary compatibility but keeps almost complete source compatibility with Qt 2.x. The KDE team has already begun work on KDE 3.0, which will use the new toolkit."

Comments

Binary compatibility

[Starship Trooper]

While having open-source code makes source compatibility easier to handle than binary compatibility, I've been wondering if there has been any work towards improving binary compatibility between versions of major libraries. The glibc mess has made binary compatibility between distributions more and more difficult, and important libraries like Qt and the various KDE and GNOME libs regularly break binary compatibility. I realize a lot of this has to do with the C++ ABI; have the GCC people thought of any ways to make binary compatibility easier to maintain in C++ programs without requiring vtable hacks and other ugliness?

As Linux comes of age, this is an important issue. Major companies want to bring their software to Linux, but often give up when face with the nightmare of having to support the thousands of subtly different library interfaces. Working to maintain binary compatibility for new versions of software would be a good goal for Linux's advancement.

Re:Binary compatibility

[Dr. Sp0ng]

While having open-source code makes source compatibility easier to handle than binary compatibility, I've been wondering if there has been any work towards improving binary compatibility between versions of major libraries.

This is an issue with C++... since most of KDE's widgets are subclasses of Qt widgets, they are very dependant on the signature of the Qt class. When the class signature changes (for example, when a function is added or removed, or a data member is added), the derived class needs to be recompiled or the linking will be all screwed up. This isn't an issue between minor revisions of the library as the API is stabilized, but with a major jump (2.3.1 -> 3.0), the API or implementation changes and things must be recompiled.

It's impressive that TrollTech (which is a great company, btw) managed to keep source compatibility so well. I'm a professional developer and we're using Qt for our app (which is currently ~20,000 lines), and exactly *1* line of code needed to be changed when we moved from 2.3.1 to the 3.0 betas.

Re:Binary compatibility

[taniwha]

Yeah, it's almost too bad that Linux is a dying OS.

even if this were true why would it be relevant? QT runs on Linux, various unix varients, win32, MacOS, ... plus QT/Embedded which runs on the raw hardware without an underlying GUI ... etc KDE runs on FreeBSD, Solaris, etc and portions of it (Konquerer for example) run under QT Embedded too

Personally I think you're just another pro-M$ troll working on the current FUD campaign for your corporate masters

Re:Binary compatibility

[davecb]

As another commentator pointed out, this can be hard if your C++ compiler gets in the way (;-))

The general problem was solved back before Unix (on Multics, to be precise), and an equivalent problem was solved for databases by the relational algebra folks.

You need a motivation to do it, though, and that motivation's not there. You need to be worried about stability without preventing innovation. A few years back a quite large part of it was solved for Suns by My Evil Twin, David J. Brown: a two-part version number for every interface in the libraries, checked at link time.

--dave

Re:Binary compatibility

[elflord]

While having open-source code makes source compatibility easier to handle than binary compatibility, I've been wondering if there has been any work towards improving binary compatibility between versions of major libraries.

The short answer is yes, there has been. The biggest problem has been with the C++ libraries, and g++ is finally standardising on a stable ABI.
As for Trolltech, they've always worked hard to maintain binary compatiblity (eg minor releases are binary compatible), indeed there were more
problems with binary compatiblity caused by libstdc++ issues than with Qt itself. I'm not
sure that KDE has been as stable, though this
should improve. (The move to DCOP resulted in growing pains)

To get some appreciation of how fragile binary compatibliity is, read this. Binary compatibility is fundamentally
difficult to preserve in C++, and I don't think there's any clean way around it. Fundamental
changes in interface or exposed structure
(that means anything besides opaque pointers) will break binary compatibility.

Personally, I think the fundamentals need to be
nailed down. C++ and C libraries need to preserve
binary compatiblity. On the other hand, I don't
think there's a problem with other libraries, so long as they maintain binary compatiblity across minor releases. (users could install multiple versions of the same library)

Re:Binary compatibility

[elflord]

Let's face it C++ is a pile of shite and we need something much better to move onto

There are lots of other things to move onto, and
many of them are very well thought out (Eiffel,
for example). However, C++ still stands up pretty
well against the competition IMHO.

Re:Binary compatibility

[be-fan]

have the GCC people thought of any ways to make binary compatibility easier to maintain in C++ programs without requiring vtable hacks and other ugliness?
>>>>>>>>>
Hopefully, C++ binary incompatibility should be passe. There is a standard C++ ABI for Itanium, and GCC 3.0's C++ ABI should be standard for x86. I don't know if other compiler vendors will follow suit (one hopes, but doubts), but the GCC people shouldn't change it.

Re:Binary compatibility

[Ian Bicking]

Doesn't the standard ABI only address binary compatibility across libraries compiled by different compilers? I.e., now you may lose binary compatibility between otherwise compatible libraries if they are each compiled with a different compiler.

But won't you still lose binary compatibility when you change the source sufficiently? For instance, don't most C++ compilers use offsets to refer to the various instance variables, and won't those offsets change as you add or remove variables?

I suppose for virtual methods calls you could preserve binary compatibility. Does Qt use virtual methods for everything?

And if everything was virtualized, wouldn't C++ be about as efficient as Objective C (or maybe even GCJ'd Java)? Or is there some fancy translation that C++ will do when linking, for a one-time-only cost (for each application startup, but not every call)?

I know little about the internals of C++ compiled code and linking, so I really don't know.

Re:Binary compatibility

[Anonymous Brave Guy]

I realize a lot of this has to do with the C++ ABI; have the GCC people thought of any ways to make binary compatibility easier to maintain in C++ programs without requiring vtable hacks and other ugliness?

C++ doesn't have a standard ABI, and can't sensibly have one. For a start, there's nothing in the rulebook that says you must implement virtuality using v-tables. Even if you do, there is more than one possible way to implement multiple or virtual base classes, for example. Imposing a required ABI would force compromises in the efficiency of C++ code, which is against the spirit of the language.

Basically, you're using the wrong tool for the job if you try to impose an ABI on raw C++ classes. If you want binary compatibility between C++ libraries, you should be advertising a higher-level interface using something like COM or CORBA or whatever other features your platform provides. You can always build something like this on the efficient base C++ provides, but if you compromise that base by trying to impose a defined ABI, you're taking the wrong approach, IMHO.

Re:Binary compatibility

[be-fan]

You're perfectly right about breaking binary compatibility due to source changes. I was talking about binary compatibility between GCC releases (C++ libraries in GCC break every new release). As for virtual methods, they don't totally solve the problem, but don't incur a speed hit either. The virtual method type thing you're referring to is what COM does. You can't easily subclass such an object, and most C++ libraries depend heavily on that capability. Second, virtual C++ calls are no slower than C library calls. In C, all library calls refer to a table of function offsets. The call first jumps to that table, which then jumps to the actual function. (Or it reads the address of the function from the table, it depends on the implementation.) This is done so that you can map libraries into different places in the process address space (say one day at 0x600 then the next at 0x1200) and you only have to change the values in the table rather than all the function calls in the code. With C++ virtual function calls, the process is similar (in Visual C++'s compiler anyway). When the library is dynamically linked to the program, the vtables of each class are written with the addresses of the functions that implement each method. Thus, the call is a single-indirect calls, just like a C library call.

Something to think about

[Reality Master 101]

How far would Microsoft have gotten if they "broke binary compatibility" with major releases of Windows? Basically, not far at all. That's not to say that Windows has perfect backward compatibility, but I don't think it's too strong a statement to say that one of the reasons Microsoft has dominated is that they have given people an upgrade path for their old applications.

Of course, the downside to this philosophy is the incredibly crufty interfaces to a lot of the Windows functionality. But I think it's key to point out that users don't care at all about those things -- they just care that their applications work.

If the desktop dreamers ever want to see Linux on the desktop, then they need to not destroy everyone's applications if you want to upgrade. Just telling everone to "recompile your applications" is not going to fly well with the typical user.

Re:Something to think about

[Skeezix]

I am sure that KDE 3 and KDE 2 can be installed in parallel. That's what we're doing with the GNOME 2 release. In other words, you'll still be able to run you're GNOME 1.x applications...you just have to have the GNOME 1.x platform libraries on your system in addition to the GNOME 2.x libraries. Distributors such as Red Hat will take advantage of this, so your apps won't "break".

Re:Something to think about

[Lface]

How far would Microsoft have gotten if they "broke binary compatibility" with major releases of Windows? Basically, not far at all. That's not to say that Windows has perfect backward compatibility, but I don't think it's too strong a statement to say that one of the reasons Microsoft has dominated is that they have given people an upgrade path for their old applications.

Just keep the old major version around, what's the problem with that? I have both Qt 1.x and Qt 2.x installed already and I can happily run programs linked against both.

Windows has problems with having different versions of a dll installed at once leading to what is often called dll hell, but this is not a problem with Unix.

Re:Something to think about

[Anonymous Coward]

There are binary compatibilities between certain Microsoft operating systems. When going from Windows 3.x to Windows 95 Microsoft had to keep all the old libraries in addition to the new Win32 libraries. In the case of XP, Microsoft came up with a library of "shims" - wrappers around the program that successfully routed the calls to a similar method.

Linux distributors use a method similar to the first one - they supply both libraries. However, the binary library for Qt is just 5MB, a tiny amount - libc5 is even less, and in the long run it makes for a better API, a cleaner system, and far faster software development.

Re:Something to think about

[MemRaven]

How is this any different than the current Windows scenario? While I agree with you that some times you just have to cut the cord and say "no applications which haven't been recompiled will work with this release of the FOO platform," users expect that their old applications will continue to work. And when it doesn't, they get really upset with you. It's been happening for years now, ever since there started to be a separation between software and hardware (way back in the day).

For windows users, they expect that only in rare cases will their old applications no longer work when they upgrade their computers. This has been something that Microsoft has done very well. The only thing is that they largely hide this functionality from you by making sure that you can't tell that there are full compatibility libraries for like 6 previous versions of windows installed on your machine when you install Windows Me. No, it doesn't always work perfectly, but most well-written applications will work properly in an upgraded version of windows. The difference with a Linux environment is that you can tell what library packages you have installed.

I think it's a reasonable tradeoff by having compatibility libraries. For those people who don't need all those compatibility libraries, you simply don't install them. But when you do need one or two, you have them available to you.

Re:Something to think about

[slamb]

I would have to agree with the primary poster here. I do think that it is good to keep that backward compatibility. It is also good to see that the GNOME team is working on a backward compatibility feature...

The GNOME people aren't creating a new binary compatibility feature; they are taking advantage of the versioning support already in ld.so. That's why there are major and minor versions of all your libraries. Major versions represent API changes; minor versions do not. An application gets the major number it requests, with the highest minor number available.

This is the case with KDE as well. If you install RedHat, you will notice kde-2.x packages and kde1-compat-1.x packages. The kde1-compat packages are necessary only for backward compatibility, as the name suggests. When 3.0 gets out of beta, RedHat will likely move the current kdelibs package to kde2-compat and create new packages for KDE 3.0.

How many diferent revisions are you going to need to keep on your hard drive to be able to run that really old 1.x GNOME app when there is no GNOME 8.x version available?

It's no worse than in Microsoftland. I'm told that every new version of DirectX includes every previous version of DirectX for this reason. Other Microsoft packages have the incredibly crusty APIs Reality Master mentioned because I don't believe versioning is natively supported.

What do you do when you get rid of your 1.x legacy apps? Hunt down all the 1.x GNOME Libraries?

If you have package management, this is easy. rpm -e kde1-compat kde1-compat-devel. Done. If something requires these libraries, rpm will tell you. (This is the same for GNOME stuff. There are gtk+10 and gtk+ packages, for example.)

Re:Something to think about

[cnelzie]

Only thing is that "feature" fails to work with several... I guess you don't call them applications... games. For one, I am a mechwarrior fan and wanted to play Mechwarrior2:Merceanaries on my Windows 2000 running laptop, which has that "feature" as well.

When it failed, I gave it a go on one of the XP Home machines at work. It failed there as well.

I also have an easy to use CAD application that I love to play with. Unfortunately, it will never run on any version of Windows after installing the latest release of DirectX, or Windows NT after installing DirectX 3.0 on it.

Sure, I am pissed about that. It sucks, but that is life.

The download for that Compatibility feature to be added to Windows 2000 Professional was also very tiny. I recall it was less than a few megabytes. I could be wrong on its size though.

--
.sig seperator
--

Re:Something to think about

[cnelzie]

Recompiling the app would be great. If you still had the source laying about. Typical users will more than likely only download pre-compiled binaries for their platform. Unless I am mistaken, I am not a programmer, there is next to no possibility of getting the source out of that precompiled app.

It is also no big deal to technically inclined folks. However, it is not an easy thing to ask end-users. People that KDE and GNOME are being designed to be used by.

--
.sig seperator
--

Re:Something to think about

[cnelzie]

If you have package management, this is easy. rpm -e kde1-compat kde1-compat-devel. Done.

Wonderful, now go and tell that to the barely computer literate masses that GNOME and even KDE are being designed for. They will look at you with a "What the heck did you just say? RP..What?"

Sure, you can just blow them off and say that they need to get back to running Windows. The only thing is, they have the same trouble with Windows. It is mostly that computers, in general, are still to dificult to use for the average person.

I know what I am saying, because I have family. They are also very technically illiterate and have very little wish to really learn how to do anything technical with a computer system.

As for having prior DirectX versions in the latest release. That I doubt. I have more than a few apps and games that fail to run under newer releases of DirectX. Some that fail to run even under the "Compatibility Feature" in 2000 and XP.

These apps and games are also not very old either. About 3 years for one and about 5 years for another one of the first DirectX 2.0 Games.

--
.sig seperator
--

Re:Something to think about

[ink]

However, I have to be a stinker and say this... How many diferent revisions are you going to need to keep on your hard drive to be able to run that really old 1.x GNOME app when there is no GNOME 8.x version available? Does this mean that we will have all the versions of the GNOME stuff on our hard drives at the same time?

The same thing happens with Windows all the time. Each application's installation directory is searched for dynamic libraries first, and then the system library directories are searched second. Take a look at most Win32 applciations, they include DLL files in their own directories for just this problem.

The reason why this is so painfully visibile under UNIX systems is that by convention we usually don't keep old libraries around; package managers in particular don't like this (which is why we have lame hacks like libfoo-compat or libbar3-version). We're going to have to change how we do things a little bit, but nothing drastic needs to be done. Newer libraries will always break older ones, its unavoidable; we just need to make sure that multiple libraries can co-exist without being a headache to maintain.

Re:Something to think about

[be-fan]

You can't really blame some DirectX programs for breaking. DirectX has evolved so much, that there are basically 3 different DirectXs, pre-5.x, 5.x-6.x, and 7.x-9.x. Even within catagories (such as 7.x-9.x), some things have been totally overhauled. Then, you add the fact that DirectX most DirectX games were originally designed for Windows 95, but most still run on the totally different Windows 2000. At that point, its a miracle that MS has been able to keep DirectX as backwards compatbile as it is. Certainly nothing in the Linux world compares to it.

Re:Something to think about

[be-fan]

Qt 1.x and Qt 2.x installed already
>>>>>>>>
Great, now you'll have Qt 1.x, 2.x, AND 3.x.

UNIX is about power, elegance, and simplicity. Somewhere along the line, elegance and simplicity got lost in features and bloat.

Re:Something to think about

[IGnatius T Foobar]

I call bullshit.

Here's a simple exercise: go to the nearest Windows machine, preferably one loaded with lots of apps of various vintages, and delete all but the newest VBRUN*.DLL, MFC*.DLL, etc. Then see how many of your apps work.

When Microsoft releases new widget sets, API's, etc., older applications do not automagically use them. Having, for example, MFC 2 and MFC 3 on your system isn't any different from having Qt 2 and Qt 3 on your system.

What Microsoft did get right, is the installation procedures: have multiple libraries sitting on the same machine if necessary, but don't bother the user about it -- it's not their problem.

Re:Something to think about

[SurfsUp]

How is this any different than the current Windows scenario? While I agree with you that some times you just have to cut the cord and say "no applications which haven't been recompiled will work with this release of the FOO platform," users expect that their old applications will continue to work.

You weren't paying attention. Your QT 2 apps will continue to work because of versioned libraries: they continue to use the QT 2 libraries, while QT 3 apps use the QT 3 libraries. This is a fundamental capability that Windows lacks. Windows tries to implement versioned interfaces and the result is a disaster because all previous versions of an interface have to be supported in a single DLL. Aside from bloating up the DLL, messing up the interfaces, this introduces a substantial risk that some vendor will ship a DLL that implements some earlier interface incorrectly, breaking other applications, or that two vendors will ship mutually incompatible DLL's. Ever seen that happen?

Re:Something to think about

[Snowfox]

How far would Microsoft have gotten if they "broke binary compatibility" with major releases of Windows? Basically, not far at all.

How far would MS have gotten? Probably up to about 20 megs for a basic install instead of 100. Maybe 64 megs of RAM total instead of 128 recommended for Outlook alone?

You take on bloat when you keep providing older interfaces and older subsystems.

Re:Something to think about

[sulli]

Well, Apple has done it three times: with System 7, Power Macintosh, and now OS X. In the old days this was a pretty major pain in the butt (of course Mac fans took it all, like abused lovers) but these days the sw vendors are being nice and shipping both binaries (OS X and Classic) together. So, while undesirable, isn't the end of the world.

Re:Call me old fashioned...

[hawkstone]

"Recode"? It for the most part requires only a re-link. Thus the "breaks binary compatibility" but "almost complete source compatibility". Changes to any source code which uses Qt should be minor to zero.

Professional user of QT 2.12

[anfloga]

And all I can say is, what a joy to work with this QT toolkit is.

Before I wrote software which uses QT, I wrote it using Motif. The designer that comes with QT is light-years ahead of any designer I've used for Motif. The "slot/socket" mechanism that it uses allows me to use a more abstract GUI design. And the geometry management is much nicer as well.

Just thought I'd throw those thoughts in. No, I don't work for Trolltech. Lykke til Trolltech!

Hope I said that right. It's been years.

Re:was wondering...

[ryants]

where does Trolltech get its revenues from? Support, selling some other product?

You may write commercial/proprietary/non-free software only if you have purchased the Professional or Enterprise Edition. Qt for Windows is only available as Professional or Enterprise Editions.

So, basically, you can (have to) pay to get away from the GPL/QPL/whatever their license is called these days.

They also sell training.

See http://www.trolltech.com/developer/faqs/general.ht ml?cr=1

Re:Still not open-source though

[David Roundy]

I'm sorry, but Qt (for X windows anyways) is available under the GPL. How can it get more open source than that? Admittedly, Qt is not cross-platform and open source, but KDE isn't cross-platform anyways.

Re:Still not open-source though

[Dr. Sp0ng]

I'm sorry but I have a huge problem with running KDE when there's a dependency on proprietary software.

It's GPL'ed. Is that not open enough for you?

It's dual-licensed - GPL so it can be used with free software, or if you want to use it in a closed-source commercial app, pay TrollTech some money. I think this is a great licensing scheme, as it keeps the source open for people who agree to the GPL's terms while still allowing TrollTech to pay developers to keep developing it full-time. If they weren't making money off of it, I don't think it would be the amazing toolkit that it is today.

Qt improvement BETTER than KDE improvements

[alexhmit01]

KDE is an impressive desktop, it works nicely, and has really grown. I always play with new releases on a Linux box, though my daily desktop in a Win2K laptop. It's fun to watch Linux's desktop grow, but I need too many Win32 only programs. My G4 Cube is fun as well, but I still have the Win32 problems, so the laptop stays.

However, looking at two "market" outcomes: Win32 vs. Cocoa|Carbon vs. Qt/KDE vs. Gtk, OR Win32 vs. Qt, and you clearly see which API system is more likely to allow competition on the desktop.

Java held great promise, but MS has succeeded in killing desktop Java. Without WORA, there is no real advantage to Java (the platform), but Qt has an interesting perspective.

As Qt Designer grows, it can become competitive to Visual Studio. Potentially, Qt becomes the glue that binds everything together.

If you can build a Qt application for Linux/MacOSX/Win32, or a Win32 app for Win32, there is an advantage to make the former. You still need to QA all the platforms that you support, but Qt lets you produce a product for multiple markets.

For a small company, Linux/MacOS provide a niche to target, but adding Win32 really makes this compelling. The windows market is MUCH more competitive, so being apple to primarily target niche markets but still selling to the dominate market is tempting.

Go Trolls go!

Alex

Re:Qt improvement BETTER than KDE improvements

[gururise]

This is great, but.... there is one major problem with your arguement.

In order for you to make your Qt application cross platform (linux/win32), it's gonna Cost ($$$) you an arm and a leg in license fee's for the Win32 version of Qt, which, by the way is NOT FREE.

Don't get me wrong, I love Qt, but if it costs me $2k to 3k grand to make my application cross platform, forget it! I cannot afford that. In addition, if a commercial company wants to develop software for linux, they too have to purchase a Qt license ($$$ several grand), unless they want to release their app under GPL, which means they can no longer expect to sell their app and make money.

So just because Qt is free, as in GPL, it doesn't make it more free than Gtk, which is LGPL. GTK apps face none of the problems that Qt apps incurr. A GTK app can be make open source or closed source, and can be made cross platform or uni-platform... ALL FOR FREE.

And that, folks, is the biggest difference between the two widget toolsets!

Re:Qt improvement BETTER than KDE improvements

[Dr. Sp0ng]

In order for you to make your Qt application cross platform (linux/win32), it's gonna Cost ($$$) you an arm and a leg in license fee's for the Win32 version of Qt, which, by the way is NOT FREE.

Ahh, but it is. Qt/Win32 is now licensed similarly to the X11 version - free for open source stuff, expensive for commercial stuff.

Re:Qt improvement BETTER than KDE improvements

[dimator]

but if it costs me $2k to 3k grand to make my application cross platform, forget it! I cannot afford that.

Well, I don't think trolltech is targeting developers like you, or companies that can't afford a couple thousand in development costs. And as far as I know, there's no "official" win32 GTK version out there, except for this: http://www.gimp.org/~tml/gimp/win32/, from which I quote the top line: "I do this work in my free time, so don't ask me for release timetables etc. If you want some new feature, you are free to suggest it, but don't hold your breath."

Is that a statement you want to build your corporate software around?

Re:Qt improvement BETTER than KDE improvements

[elflord]

In order for you to make your Qt application cross platform (linux/win32), it's gonna Cost ($$$) you an arm and a leg in license fee's for the Win32 version of Qt, which, by the way is NOT FREE.

WRONG, WRONG, WRONG. Completely false. See the Qt non-commercial license. I can't believe this crap is marked as "informative".

Re:Qt improvement BETTER than KDE improvements

[Keith Russell]

FAQ you. In short, any version of Qt released under the non-comm license is free as in beer, but not Free as in speech. There are two notable issues:

1. No source code. You're stuck with the binaries only.
2. Incompatible with GPL. It's a non-Free, 3rd party library, which is a no-no in GPL'd projects. From the README:

   If you wish to port one of the many GPL'd Qt-based Unix applications to another operating system using the Qt non-commercial edition, you need to get that application's copyright holders to add an exception to its license.

Favorite quote from the FAQ: "Once Microsoft Windows is completely open source, we will reconsider." So there. Nyah! They still can't tell the difference between taunting Microsoft (which they're not), and taunting Windows developers (which they are).

Re:Still not open-source though

[Jeremi]

Perhaps you should check out Trolltech's site then. All the source code to Qt is available for download there, for free.

database functionality... why?

[nilstar]

Okay, here goes.... why oh why is QT in need of database support. It is a cross platform GUI (last time I checked?). Aren't things like cross platform database access left to tools like Java?

Re:database functionality... why?

[jfunk]

A bunch of points in no particular order:

• Qt was never intended to be just a GUI. It was intended from the beginning to be a RAD environment. That means simplifying many programming tasks including, but not limited to: GUI stuff (QWidget on down), string use (QString, etc.), internationalisation (i18n, QtLinguist, etc.), 3D graphics (QGL), and the elimination of evil callbacks (signal/slots are my very favourite feature). You can also create non-GUI apps under Qt, if you want (KDE's 'dcop' command is an example. try an 'ldd' on it)
• Database functionality is actually quite important for a toolkit such as Qt. Have you tried Kylix? It's biggest selling point is it's DB functionality. It's really simple to quickly create DB apps, even if you can only use MySQL or Interbase. We have it where I work but we use PostgreSQL. I will definitely be trying Qt's new DB functionality
• Do you *really* want to make a frontend in Qt and a backend in Java? If you're going to use Java, you might as well use Swing or Awt for the GUI bits. Besides, I've seen some terrible experiences with getting different Java programs running under various JREs on Windows. If you can simply compile a binary and an installer, then the user only has to install one thing and can avoid JPain

OK, not so many points as I thought...

Re:database functionality... why?

[elflord]

Okay, here goes.... why oh why is QT in need of database support. It is a cross platform GUI (last time I checked?)

No, it was never just a GUI library. It also included a container class library, strings, streams, graphics file manipulation, and more recently, it has an OO socket implementation, and XML support (Sax and DOM) You're on to something with your Java comment though -- think of it as a C++ version of the Java standard library, if you like.

Re:Still not open-source though

[jonathan_ingram]

I'm sorry but I have a huge problem with running KDE when there's a dependency on proprietary software.

Although you are stupid and misinformed (no closed source software anywhere in KDE), with your attitute, you should prefer KDE to Gnome. QT is GPLed, which means that if you want to write commercial applications using it, you have to pay Trolltech for an alternative license. In contrast, the whole of Gnome is no better than LGPLed, which means there is nothing stopping commercial software.

KDE is therefore the better choice for those like Richard Stallman that believe that all software should be free.

Re:Qt? Who needs it...

[jonathan_ingram]

Yes, it's strange that wxWindows has been ignored by the wider Unix community... from what little I've seen of it (mainly in relation to wxPython, the Python bindings for it) I've been very impressed -- particularly compared with Tcl/TK (or tkinter, the 'standard' Python GUI system).

There is some nice software like Audacity and Roxfiler using it, but nothing like the amount that *should* be.

almost complete source compatibility

[Anonymous Coward]

keeps almost complete source compatibility with
That means, according to my practice, almost no bigger QT2 project compiles with QT3 without modifications (yes, the modifications are not very big and depending what classes you're used these may not be very much also).
What I really liked with QT3 was new designer, it's way ahead of old dialog drawing app, going near to Delphi's funcionality.

It's a cross platform toolkit!

[alexhmit01]

If I had to predict a reason, it is probably because Trolltech's paying customers want integrated database access. If you are building a corporate app to deploy across Win32 AND Linux desktops to access the corporate database, you likely want it to be able to. In fact, you probably want the app to function without calling an external Java system and therefore need a Java programmer/QA person.

Java is a cross platform toolkit/language/vm, Qt is a cross platform toolkit for C++.

This lets you build database applications (the VAST majority of application, in fact just about every application is really a database application, think about what computers do...) that will compile for Linux, Win32, Mac OS X, and Qt Embedded platforms...

Pretty slick...

Alex

Re:Still not open-source though

[jfunk]

You do have access to all the source-code. The only requirement is that you have to pay for _using_ it if you are making money on it.

That's not entirely accurate. You have to pay for using it if you are making money on it and you're developing closed-source apps.

You are free to make money off of Qt-based apps without paying TrollTech as long as you provide source to your customers as per the GPL. This is why distros are allowed to package KDE and any other GPL-licensed software such as Emacs, Gcc, and others.

Don't uhh... troll

[marm]

I'm sorry but I have a huge problem with running KDE when there's a dependency on proprietary software.

Sigh. How many times does this have to be explained before people get it?

Qt is Open Source software.

The X11 version (which is what KDE depends on) is licensed under either the GPL or the QPL, at your choosing. If you develop proprietary software (i.e. under a license that is incompatible with either the GPL or the QPL), then a paid-for commercial license is required. This is how TrollTech make their money. Either way, you get full source code.

Even Richard Stallman has given his blessing to KDE and Qt's licensing scheme.

Can I make it any clearer for you?

Re:Qt? Who needs it...

[Dominic_Mazzoni]

Amen!

The really cool thing about wxWindows is that at any time somebody could write wxQt, and immediately all wxWindows programs could integrate with KDE as well as they currently integrate with GNOME.

I haven't regretted for a second choosing wxWindows, even if nobody ever writes wxQt, but I sure do like my KDE desktop.

Finally for the Mac!

[SeanAhern]

One of the most exciting pieces of news about Qt 3 (for me at least) is that it supports Mac OS X. And I'm not talking in X11 mode running XFree86. They have a true Quartz/Aqua implementation that runs natively, including OpenGL support.

So finally, all of those apps that use Qt to port to Windows now immediately port to Mac OS X with a recompile. Good show, Trolltech!

Read more from their press release.

Re:Finally for the Mac!

[Dr. Sp0ng]

What does Qt do? It uses fake transparency and doesn't use much of the native support for displaying widgets. Only a fragment on the powerful Mac Display API is used AFAIK. This means that Qt is far slower on Mac than it could have been.

Qt doesn't use native widgets on any platform. This allows developers to subclass widgets and change the way they're displayed in a platform-independant way. This is a good thing.

I haven't tried Qt on OS X, but the performance is good on X11 and Win32, where it uses the same techniques. There's nothing inherently slow about drawing widgets yourself instead of using the operating system's native libraries.

Re:Finally for the Mac!

[spitzak]

Unfortunately this is why Qt works at all. It is absolutely impossible to make a portable library that interfaces to a high-level toolkit like interface. This was tried with things like wxWindows that tried to run atop Win32 widgets and Motif. Where are those toolkits now?

There is a serious problem with the system designers being so full of themselves that they think they can dictate things like toolkits. The should be spending their time on hard stuff, like advanced rendering models, and stop thinking they are cool because they can program a new type of drop-down menu.

Unfortunately Qt itself seems to be suffering from this too. A lot of this very useful stuff (like the antialiased rendering) is intricately linked to their toolkit such that it is impossible to use it without also using Qt. I am hoping they will start to fix this, as it is probably becoming an unimaginable maintenence mess unless they start looking at layers of libraries.

I would consider using Qt if they would stop copying some of the stupider Windoze things: allow Emacs ctrl keys in the edit widgets, fix the dragging of scrollbars so they don't go back if you drag diagonally, make the "combo box" pop up with the currently selected item under the mouse and make it the full height of the screen, don't move the focus when you click on buttons, allow buttons in the menubar so we don't need a seperate "toolbar", and put the filenames in a single column in the file chooser. KDE needs to fix the window manager to not raise windows when you click on them, and allow windows to be repositioned without raising them. There are a dozen other little problems like this. Until we stop seeing this crap there are going to be people like me who will refuse to use Qt.

Kapps for Mac OS X?

[Tachys]

Does this mean that in the future we will see Kapps like Kword and Kmail on Mac OS X?

Re:Stallman's response

[RelliK]

Funny? I just can't tolerate trolls like that.

Re:Call me old fashioned...

[elflord]

AKAIK it's C++ and there hasn't been a standard ABI until GCC 3.0.

That's also partly true. There hasn't been a stable ABI, so the dependency on the standard library (libstdc++ 2.7/8/9) has resulted in more relinking than changes in Qt. The new ABI for g++ is not standard, but it's supposed to be well a defined ABI that is reconcilable with the standard.

Re:Call me old fashioned...

[elflord]

if your widget set gets a re-write, why should you have to recode your entire GUI?

One hopes not. Trolltech have done a good job of maintaining source compatibility. Binary compatibility however is a much more fragile thing, especially in C++. It is broken by many things, some smaller than changing the interface. I recommend this link here as a good explanation of binary compatibility issues.

Damm

[harvord]

Damm I thought this was some sort of first post/goatsc.ex tool with a GUI.

Re:Stallman's response

[elflord]

I notice Qt is not on the list of GPL software on
fsf.org. Oversight perhaps ?

Re:When will TT replace moc with C++ templates?

[elflord]

The 'moc' signal/slot mechanism is hokey - when will it be ditched by TrollTech for a pure template callback solution?

I think the lack of good compilers had a lot to
do with the approach, at the time. This also
had a lot to do with them re-inventing STL.

QT Pricing

[hack0rama]

QT is not free for cross platorm freeware.

Earlier we did not had a very good choice for cross platform GUI, AWT/SWING did not have the performance of native GUI and WxWindows was not powerfull/rich enough.

Then came QT and I thought wow ! this is it, for my next cool application, eventhough I will develop it on Linux, I can make it available for Windows as well as Mac users.

Then I realised its only free on X, you got to pay around 1500$ to get it on other platforms even if you want to write/ditribute a freeware app.

On Windows you pay 50$ after rebates to get a copy of VisualC++ 6.0. And for 50$ you get a compiler, GUI class library, and IDE and debugger. And just for the QT library its 30 times more than Visual C++, how can any hobby programmer afford it ?

I hope Trolltech come out with a more sensible pricing for freeware developers on Windows/Mac which should help QT to gain more acceptance in the non Linux programming community as well.

Re:QT Pricing

[Dr. Sp0ng]

Then I realised its only free on X, you got to pay around 1500$ to get it on other platforms even if you want to write/ditribute a freeware app.

No, dude. It's free for open source software on Win32 as well:

http://www.trolltech.com/developer/download/qt-win -noncomm.html

Re:QT Pricing

[Dr. Sp0ng]

It is only Qt 2.3 [ QtWin230NonCommercial.exe ] I could not find Qt 3.0 free version for Windows, and they dont say anything about it.

Ah. You're right. I stand corrected.

Well, Qt 3's only been out for a few hours now, maybe they'll get a free 'doze version out at some point.

Re:QT Pricing

[Anonymous Coward]

Hi!

We will be releasing Qt/Windows 3.0 non-commercial and Qt/Mac 3.0 non-commercial within 1-2 weeks (current release date: 20/10/2001)

Michael
TrollTech A.S.

Re:When will TT replace moc with C++ templates?

[elflord]

Fat fucking chance. Trolltech will never admit that their solution is full of shit.

I hear moc trashed quite often, but I've yet to hear anyone succesfully enumerate the tangible disadvantages of it. Trolltech have been able to stick to the same design for a long period of time, maintain binary compatibility over minor releases, and for the most part source compatiblity over all releases, while continuing to develop, extend and refine their toolkit. This IMO is a sign of far-sightedness.

Re:Still not open-source though

[small_dick]

Just curious...how much does TrollTech pay the kernel developers to run on top of *their* objects?

"but MS has succeeded in killing desktop Java"

[jonabbey]

I have to beg to differ. If MS can destroy desktop Java by simply not bundling it with their OS, then desktop Java was dead already.

In fact, the wide range of systems on which network clients written in Java can operate was and is one of the main reasons why we did Ganymede in Java.. we can and do run our client on Win32, Mac OS (8, 9, and X), OS/2, Linux, FreeBSD, Solaris, HP/UX, AIX, etc., etc., etc.

In the real world, Java is still the best at client-side WORA if your demands for performance and features can be satisfied with the abilities of the Java VM and class libraries.

are all KDE contributors paid licensees?

[small_dick]

...or do they work for free (uncompensated)?

My reading of the Qt license says it can't be both ways; you can't be compensated for the code you develop, unless you buy a license, regardless of your end product license.

Re:are all KDE contributors paid licensees?

[Bob Uhl]

Read the GPL--which Qt is now offered under. As long as you abide by th (well-known and acceptable to many) terms of the GPL, it doesn't matter what you do.

If you wish to offer non-GPLed code to the world, then yes, you'll need to purchase a license from TrollTech (a great company, from everything I hear). Personally, I really do hope that things go well for them. They're good guys. Does the KDE project have any plans to donate money in their direction?

Personally, I'm a gtk+ man, simply because I prefer C development, and like gtk's handling of classes, types and all that. I also prefer GNOME as a desktop environment. But KDE is sweet, to be sure. It just doesn't do quite what I like. Choice is a Good Thing(tm). I look forward to many years of desktop competition. It should be interesting.

Re:are all KDE contributors paid licensees?

[small_dick]

Ahhh...so as long as they use Linux, not Windows, they can do this. Actually, on X11, you can use a number of "free" licenses for the end product, and be compensated for creating it as well.

The Linux Qt goes out as a "Free Edition" while the Windows Qt goes out as the "Non Commercial" edition, with different restrictions on each.

The GPL is not all-knowing is this case. Reading the GPL tells you nothing about the following, which applies to Qt-win:

"Terms of use"

"Developing and distributing applications"

"Private users may use the Qt non-commercial edition in a non-commercial setting to produce non-commercial applications."

"A non-commercial setting means that you must not use the package in the course of your employment or whilst engaged in activities that will be compensated. A non-commercial application is an application that cannot be sold, leased, rented or otherwise distributed for recompense."

Snipped from:

http://www.trolltech.com/developer/download/qt-w in -noncomm.html

Seems odd to use different licences for different platforms, but I'm sure there is logic in it.

Re:are all KDE contributors paid licensees?

[HiThere]

It'd really the idea of mixing in with your crowd to be accepted, which is very valid, imho.

Yes-No. If it were GPL then I could use it. I could even pay a bit for it (though not anywhere near $1500). And when I released software (which all of 30 people might ever use), having it be GPL & free would be no problem.

But if I need to use the commercial license, then I can't use it. No option. No choice. I can't. $1500 isn't a feasible price, and there's no budget available. And per copy prices aren't acceptable. not even at $.01 per copy (or less). We don't have an accountant for this matter, and aren't about to hire one.

It's their product. It's their choice. But if the Non-Commercial license for 3.0 is the same as for 2.x, then it's write it off.

Fortunately there are other tools. I'm currently looking at Fox. Which seems to be useable. Not as full-featured as Qt, but feasible.

Re:speed of Qt

[be-fan]

Qt isn't the problem. On Windows, even widget-heavy Qt apps redrawing smoothly. I have absolutely now idea why redraw performance on Linux is so bad. Its probably not XFree86's rendering core, since I hear XAA is quite speedy. It probably comes down the communication required by X's design. The seperate window manager process (IMHO, a dumb idea, a dynamically loaded window manager module would have sufficed) needs to communicate heavily with X whenever the user manipulates windows.

Re:Qt? Who needs it...

[Mochatsubo]

Of course if you are in the market for a Python GUI, you should also check out PyQT in addition to wxPython. A nice tutorial for PyQT by Boudewijn Rempt can also be found here. -willryu

Who killed Java? Who will kill Qt?

[fm6]

Java held great promise, but MS has succeeded in killing desktop Java.

Even if you subscribe to the worst MS conspiracy theories, you can't give MS sole credit for killing desktop Java.

Sun deserves a lot of credit. If you're going to introduce a Revolutionary New Approach to Programming, you shouldn't do it with inefficient, buggy VMs, or quickie compilers that don't properly exploit garbage collection. Thos mistakes gave Java a reputation for flakiness and inefficiency it still hasn't fully dispelled.

And if you want everybody to start using Java to develop desktop apps, you don't suddenly shut down your own application development efforts before they've had a chance to bring their product to market. But of course IBM, Oracle, and all the other biggies were doing that too. Coinciding with the downfall of the Network Computer.

And that's what really went wrong with desktop Java. Platform independence was never enough by itself to make Java widely adopted on the desktop. You had to give people a reason to abandon their investment in Windows-based solutions. That reason, was the Java-based NC, which was supposed to lower the Cost of Ownership for big corporate computer buyers. (And, not incidentally, give these same buyers a reason to buy proprietary Sun and IBM hardware instead of commodity PCs.) Unfortunately, nobody bought the NC idea, and the main market for Java desktop apps disappeared.

Some, but not all, of this history is repeating itself with Qt and KDE. Being technically superior to Windows wasn't enough for Java, and it won't be enough for the Linux desktop.

Re:Who killed Java? Who will kill Qt?

[iapetus]

Even if you subscribe to the worst MS conspiracy theories, you can't give MS sole credit for killing desktop Java.

Desktop Java is dead? That's news to me, since I'm currently working with plenty of big companies who are still developing desktop Java solutions.

What died was the idea that Java would be the development language of choice for all desktop apps in the future, from diarying systems to desktop publishing. And that's a good thing, IMO.

Re:Who killed Java? Who will kill Qt?

[be-fan]

Being technically superior to Windows wasn't enough for Java, and it won't be enough for the Linux desktop.
>>>>>
The Linux desktop hasn't even gotten to the "technically superior" phase yet. I use it everyday, but Windows has a really big edge in the technical superiority department.

Re:Which databases do they support?

[elflord]

Drivers for Oracle, PostgreSQL, MySQL and ODBC are available and writing new drivers is straightforward

Cheers,

yacc ...

[_generica]

from src/moc/README
----
Notice that moc does not compile with GNU bison, use standard AT&T yacc or Berkeley yacc instead.
----

why do these people refuse to use commonly available tools. I've spent a lot of time searching for these, neither of which are under developemnt or even easily availble. Bison is under development. Why don't they use it, or at least let us use it ??? Because of this, I can't compile qt-3.0.0, and I think this is unacceptable.

No, it's not

[GCP]

I just came from their site. I just read the FAQ. They reiterated the point in several of the answers: "no, you have to buy the pro or enterprise version if you want to sell on Win32", "no the free version is not even available on Win32, only the pro or enterprise version," "no, you *can't* even develop for free on Win32 and then pay for a license when you decide to start selling, the Win32 license requires you to pay us, even for development...."

They couldn't be much clearer. Or, are you saying that their Website is wrong?

Re:speed of Qt

[jonabbey]

Well, XFree86 can do mmap for client/server communications on a single system, I believe, so you're really getting pretty good speeds. The biggest issue there is the context switch time, I imagine.

Re:for Mac OS X as well !

[pointwood]

AFAIK, theKompany has started using Qt3 a while ago which should mean that their apps should be available on *nix, Win and Mac.

Re:Cross-platform configuration

[Warwick Allison]

You missed QSettings.

It's the registry on Windows, and ~/.foobar files on Unix.

http://doc.trolltech.com/3.0/qsettings.html

Cool, eh?

--
Warwick

Question about Steven's comments in Dr Dobbs...

[MeerCat]

Not wanting to troll, but in October's Dr Dobbs (pages 105-107), Al Stevens points out what he doesn't like about Qt - primarily the way that the framework breaks the "new/delete" idiom. In particular, widgets must be allocated on the heap and then given to the framework to manage and delete. (When I last looked at Qt I though the same sort of thing but thought maybe I was being a little too snobby and showing my age).

As I said, I don't want to troll, but for those who're using Qt/KDE is this a big concern ? Do you write a handler wrapper class around widgets that hides this mis-match, or do you just live with it ? Does it only happen in one or two spots ? Is short - how do you change your practices to match the toolkit ?

He also dislikes the metaobject compiler and a few other items, but I'm less concerned about those...

T

Re:Question about Steven's comments in Dr Dobbs...

[anno1602]

Having looked at MSFC (yuck!), GTK and Qt, I find that Qt is the toolkit that makes UI programming the easiest. And frankly, I don't quit get what you mean with your new/delete idiom breakage. It all works the very same way as in standard C++, except for two things:
1. Include the QOBJECT macro in every class you want to use Qt in
2. You don't have to bother deleting Qt Objects. It's done by Qt.

I think it's great. How is this bad?

Anno.

Re:Question about Steven's comments in Dr Dobbs...

[Junta]

His complaint is with Point 2, it seems strange to have to explicitly call a new, but then not have to worry about deleting either. From a functionality standpoint it's nice, but it does cause problems to those who expect to have to delete for everything they use new to make.

Re:Question about Steven's comments in Dr Dobbs...

[MeerCat]

Having looked at MSFC (yuck!), GTK and Qt, I find that Qt is the toolkit that makes UI programming the easiest

I agree MFC is nasty (I almost had to use Glockenspiel CommonView 10+ years ago, and MS just stole the entire team to write MFC version 1 - I'd already written my own C++ wrapper by then).

except for two things [...] You don't have to bother deleting Qt Objects. It's done by Qt [...] How is this bad?

When you have a large body of code evolving over a period of time, you often want to check such things as resource leakage. This normally means checking that all allocations match up with deallocations (with a GC-ed resource you do this by checking all your GC code works and by checking people use the GC properly). You check this by matching up alloc and de-allocs of whatever resource it is.

If you have a single block of code that runs

alloc resource
use resource
free resource

then you can easily see that this resource is handled properly (ignore true exceptions for now).

On the other hand

alloc resource
if resource allocated
use resource
free resource
end-if

is also correct, but

alloc resource
use resource
if some-condition
free resource
blah-blah-blah
if some-other-condition
free resource

is usually wrong - it breaks the idiom - reviewing this code should set off alarm bells as allocs and frees don't directly match. If the code is genuinely correct (say the 2 conditions are mutually exclusive) then you have to mark it in some way to say "this misuse of the idiom is correct" - often you "mark it" by refactoring the code to use the idiom

alloc resource
use resource
do-the-commonstuff-here
free resource

In C++ the standard idiom is "object construction is resource allocation", and this makes exception handling and some of the refactoring easier - you allocate the resource in the constructor and free it in the destructor. Again, for the reader/reviewer it is easy to see where allocs and frees match up and prove the use is correct

class blah
{
blah() { alloc resource }
~ blah { free resource }
reset { free resource; alloc resource }
}

Again, this is not language specific, but idioms that make it easy to see when your code is correct. That's why adding a function to the above class

set(r) { free resource; resource = r; }

is nasty - you have an unbalanced freeing of a resource so to prove its correct you have to show that everyone who calls set knows how to use it properly. This seems to be the Qt idiom.

How is this bad ? Add 5 years of development with a rotating team of 10 developers (say turnover of 2 a year) and management, and a medium sized code base of 250,000 lines of code across 25 libraries and a dozen executables.... it's 10pm on the night before a release - do you know where all your allocs and frees are ?? On a small project or a small codebase you can hold it in your head "don't worry about these special cases" but in the larger case it makes for problems, and I put enough bugs in my own code without idioms that encourage me to introduce more. I can think of ways to code around it (a wrapper that allocates the class and gives it to the Qt framework, a bit like auto_ptr) but why doesn't Qt do this for me ?

Long answer to a short question - sorry....

T

Re:Question about Steven's comments in Dr Dobbs...

[spitzak]

My toolkit fltk does things similar to Qt: when you destroy a "containier" widget it destroys all the inner widgets for you, even though you had to use "new" to create all those child widgets.

I have to admit this has caused problems, though for most programs the code savings is enormous (because fltk has to keep track of all the child widgets anyways, this avoids the need for the program to do so just to be able to delete them).

I solved a lot of this with a hack: I made the destructor change part of the object (the "parent widget pointer") to null, and container destructors don't destroy child widgets unless the parent pointer is equal to them, thus avoiding double destructors. This is theoretically bad programming practice but as far as I can tell has never failed. It allows widgets to be local variables, and imbedded (non pointer) members of larger structures, which Qt does not allow, this has proved to be very useful! However it still fails if the programmer calls the destructor after destroying the container.

Re:Question about Steven's comments in Dr Dobbs...

[spitzak]

Actually I *want* the users to be able to create the objects on the stack. Something like this:

function() {

Fl_Window window(...);

Fl_Input textfield(...); // this is in the window

Fl_Button okbutton(...); // also in window

window.show(); // put it on the screen

(wait for user to hit ok button)

return result;

} // this destroys the window & widgets

I have tried to stop the copy & assignment by making them private and undefined. Unfortunately the stupid MicroSoft VC++ does not like this, and you have to give dummy implementations, which means that code that has rights to call private functions are still not prevented from compiling with assignments and copy constructors. Stupid MicroSoft strikes again!

Re:Question about Steven's comments in Dr Dobbs...

[spitzak]

MSVC++ refuses to build a shared library where the header file declares some function exists but it is never declared.

You can get around it by ifdef'ing out the declaration when making the library, but this assummes that the library itself has been debugged.

Re:Question about Steven's comments in Dr Dobbs...

[spitzak]

If I make Uncoypyable be "class _declspec(DLLIMPORT) Uncopyable..." I can compile the library (if I leave out the commented-out lines, as you said). However I cannot link with it unless I also comment out the assignment operators from the header. It appears that something in the linking process with a .dll requires that all symbols declared with APIENTRY must exist.

Re:Question about Steven's comments in Dr Dobbs...

[spitzak]

Imbedding the non-DLLEXPORT class may work but I think it produces nasty warning messages from the compiler about doing it. What also works is to put DLLEXPORT on each individual public+protected method rather than on the entire class. This of course looks incredibly ugly in the header file, I think this crap will still pollute header files for decades after Windows has disappeared, just like K&R vs Ansi prototype macros still pollute most of the Unix header files.

It would be nice if the class DLLEXPORT just exported the public (and maybe the protected) methods. I think they export all of them so that inline public methods that call them can be compiled. The compiler could reliable check for this, though.

Of course it would be even better if the missing symbol was just missing from the DLL, like it is in Linux .so files. I don't understand why they can't do this, I thought there was a problem with reserving "slots" in the DLL, but it is obvious that DLL's work if you add or delete unused exported symbols from them, so I don't know what is going on. Probably stupidity.

Re:for Mac OS X as well !

[maggard]

There are numerous features included in Qt/Mac, and among these is an extensive C++ framework for OS X, support for the Aqua look &feel, OpenGL support, database support and rich text support. Qt/Mac runs native on Mac OS X, of course, and is fully carbonised.

Fully native isn't Carbonised. Fully Native is Cocoa or Java. Thus this will likely miss out on many of the fully native features such as support for Aqua, not just "support for the Aqua look &feel".

Re:TrollTech should make a portable Virtual Machin

[be-fan]

Who cares? Linux programs are open source, and so the only thing you'd gain from a VM is negative speed.

Re:Server Architecture Crucial

[be-fan]

Yahoo. You don't need a client-server architecture achieve remote usage. There's a program on Windows called Citrix ICA. It allows you to run programs remotely. On a T1, Excel runs only a little slower than running KSpread does locally! The real reason X runs as a seperate process isn't network transparency, but protection. The GUI needs to protected place where it can maintain data about the windowing system. On Windows, this windowing code is put in the kernel. Here, user apps can't crash it, but it can crash the kernel. The only other safe place is a seperate process. In theory, one could put the windowing system into a library, so all UI calls would be simple function calls, but on most chips, there is no way to protect library data structures from the user process. The old x86 segmentation mechanism used to be able to check a memory access based on the privelege level of the segment holding the calling code. If something like this could be done for pages (only the GUI's code pages would have the right to access GUI data), then we could get rid of this whole windowing process crap altogether. But, I digress. That wasn't my point in the first place. I was saying that you could put the window manage in a library and dynamically load it into the X server. The X sever doesn't need to be protected from the window manager, and putting it in a library would offer most of the flexibility of putting it in a seperate process. This would speed up a lot of the window/manipulation operations that are so slow in X today.

Re:speed of Qt

[be-fan]

First, XFree86 isn't designed with fast communications channels in mind, and thus doesn't benifet much from shared memory channels. Second, I wasn't talking about putting X11 in the kernel or anything like that. I was saying that the window manager, instead of being a seperate process, could by a dynamic library. The real reason the WM (like Blackbox or whatever) is seperate is for flexibility. Back when X was designed, dynamically loaded libraries didn't exist, so the WM was put into another program. Now that we have dynamic libraries, you could load the WM as a X server module and get the benifets of flexibilty AND speed. This would speed up stuff like moving windows which are slow in X because of the communication required between the WM and the X server.

Superiority: a definition

[fm6]

Depends on what you mean by "superior". If you just count features, Windows will always beat Linux. MS's huge employee base can dream up new features faster than any competing team, Open Source or otherwise.

But that's part of the problem. On Windows, everything gets totally re-invented ever few months. As a result, nobody can keep up with all the changes, and the system as a whole is painfully complex and unpredictable.

If you care about the stability and useability of a system, then the "superior" system is usually not the more "advanced" one.

Re:Superiority: a definition

[be-fan]

I care about speed, Windows wins. I have yet to see a widget set on X that matches the performance of Win32 in terms of redraw speed. Hell, even Qt on Windows is faster than Qt on Linux.

I care about unification, Windows wins.
>>>>>>>
I like GIMP, and I like KDevelop. I don't have infinite RAM and I like my apps to look the same. What do I do?

I care about predictability, Windows wins.
>>>>>>>
The other day, I installed AbiWord, and it didnt' like the fact that I'd removed its crappy Type1 fonts from my path. Why? Why is the app so damn bound to its fonts? I tried to install the mandrake kernel source RPM the other day, to find that it needed GCC 2.96. GCC 3.0.1 (which I have installed, in RPM form no less) works fine for the kernel, why is it so attached to its obsolete RPM? There are just too many factors in Linux that can fuck up. In theory, Linux is quite elegant and powerful, but in practice, its really not. Not as a GUI machine anyway.

I care about stability, Windows wins:
Its true. KDE-2 has crashed more often on me than Windows 2000. Of course, you'll tell me to go use Window Maker, then I'll ask where my unified GUI is, and you'll then tell me to use KDE-2.

I care about audio, Windows wins:
The Linux audio system is probably the most f*cked up thing ever. aRts on top of OSS/ALSA? WTF? Aren't software mixers archaic relics of the early 1990's? And why is aRts nifty media framework tied to a dumb software mixer? I wnat to use my SBLive! fully! ALSA is quite powerful, and quite speedy. Build a media framework on that instead.

Of course, Linux has tons of strong points. The kernel whips Windows to all hell. The VM system is (finally, thanks AA) much better, the filesystems are faster, and everything is just smoother. With the preempt and lowlat patches, BeOS finally loses the audio-latency performance crown for a general purpose OS (as long as you don't use aRtsd or esound!) urpmi is nifty (when it works). Konqourer is really a step forward. Auroura boot is just plain cool. I use Linux on a daily basis these days, but I don't enjoy it as much as I should. XFce and GNOME are decently fast, but lacking in features I enjoyed in Windows. I can use XMMS/ALSA and get good sound, but I have to live without the media framework I had in BeOS. It certainly gets the job done, but it has so much more potential its disgusting. Everything is already there. If only someone non-braindead came along to organize it all...

Dead Java

[fm6]

Well, "dead" is relative, at least in software. One does see a fair number of Java desktop apps. But it's pretty marginal. Of course, Java never was going to take over completely, But at one time, it was reasonable to hope that Java would replace native code for some basic desktop apps, such as word processing and spreadsheeting. Early attempts at this, like the Java version of WordPerfect, were underwealming. But some decent desktop apps did eventually appear. Alas these were much too late to arouse any serious interest.

And I think that's too bad. It would have been really nice to have a universal component architecture. It would have allowed us to get away from big, bloated, brittle apps that irritate techies and frighten non-techies. Maybe Java couldn't have replaced every native app in the world, but if it had replaced just two -- Word and Excel -- the world would be a better place.

I am not blaming DirectX

[cnelzie]

I just find it terribly frustrating that I am forced to buy the latest and greatest version of Caligari's TrueSpace, simply to be able to create some, nifty to me, 3D rendered objects.

I am not made of money. So, I have taken one of my old extra HDs and tossed an older version of Windows. Simply to be able to run that application and create some art. It is not a pretty fix, but it is one that does function for me.

To get back to the point. Backward compatibility is an incredibly important aspect of an Operating System and even a hardware architecture. To simply put it, for every person that has the money to buy all the latest and "greatest" whiz-bang programs, operating systems and hardware. There are at least a thousand that are unable to afford all of those whiz-bang new toys.

--
.sig seperator
--

Re:I am not blaming DirectX

[be-fan]

I just find it terribly frustrating that I am forced to buy the latest and greatest version of Caligari's TrueSpace, simply to be able to create some, nifty to me, 3D rendered objects.
>>>>>>>
Blame Caligari. It had no business basing a 3D moderling in DX. The state of D3D at the time the early versions of TrueSpace came out was not at the level necessary for a 3D modeler. D3D has changed entirely, and its hard to expect D3D to maintain compatibility with an app that is pushing the API to its limits anway. (I wouldn't be suprised if the early versions for TrueSpace are full of D3D workarounds.)

Re:speed of Qt

[spitzak]

I would also agree with this.

The window manager is a problem when you create windows and when you move and resize them. However it does not interfere with the actual drawing of the window contents at all, they are the same speed as if there was no window manager.

Most of Xlib's problems are the enormous numbers of calls that return a value, thus requiring synchronization between the server and client. For instance to draw in an arbitrary color the program needs to ask for the color cell (a round trip) and then set the color cell in as the foreground color and draw (not a round trip). Yes of course any real program will remember the color cell after the first call, but many other things in X require round trips all the time. If no Xlib calls returned a value I think the stream buffering would result in far less context switches than even Windows where the system is put into the kernel.

You are correct that window managers were made before there were shared libraries (or at least before there were shared libraries that the user could easily change). If we could fix this now, I would actually put the entire window into the toolkit. If people wanted the window behavior or borders to change this would be a themable part of the toolkit. Actually I would expect we would be able to get rid of the window borders entirely, which would go a long way toward making a user-friendly and attractive interface.

Blatant Kylix Database Plug

[fm6]

Have you tried Kylix? It's biggest selling point is it's DB functionality. It's really simple to quickly create DB apps, even if you can only use MySQL or Interbase.

Actually, you don't even need MySQL. There's a driver for XML-based flat file databases.

Re:Server Architecture Crucial

[prizog]

You don't need a client-server architecture achieve remote usage. There's a program on Windows
called Citrix ICA. It allows you to run programs remotely.

And you think that's not a client-server architecture? Um, then what is it?

Re:Server Architecture Crucial

[be-fan]

Sorry about that. I meant that it doesn't have to be native to the windowing system. Windows 2000's GUI runs in the kernel, but it supports remote GUI just fine. Network transparency isn't why X is a seperate process, saftey is. X runs in a different address space so it can't crash the kernel.

Re:TrollTech should make a portable Virtual Machin

[be-fan]

And the benefits of a platform-independent binary format would be *huge*.
>>>>>>
Uh, no. Last time I checked, almost all Linux software distros release binaries for each supported arch. Besides, everyone (statistically) uses x86, so who cares?