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

We have waited long...

[James Skarzinskas]

Resumming this article:
We have waited long for this day! QT3 should make from some interesting new software in this field. The database intergration looks intriguing, but it will no doubt have numerous bugs.
</redundancy>

Re:We have waited long...

[James Skarzinskas]

Oh, you call me a troll eh? Your an OGRE! Beat that, /. scum!

Call me old fashioned...

[morbid]

...if you like...
..but..
if your widget set gets a re-write, why should you have to recode your entire GUI? Have they not settled on a standard interface yet?

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.

Re:Call me old fashioned...

[morbid]

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

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.

Re:Call me old fashioned...

[Matthew Austern]

The new ABI for g++ is not standard...

Depends on what you mean by "standard". It's true that the C++ standard doesn't specify a C++ ABI. (It can't, since an ABI necessarily depends on the platform.) However, the new ABI for g++ does conform to an informal standard defined in http://www.codesourcery.com/cxx-abi. This ABI was defined cooperatively by a number of companies with an interest in C++ interoperability; it was originally defined for the Intel Itanium, and was later generalized to other platforms.

was wondering...

[Anonymous Coward]

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

Re:was wondering...

[ptarmigan]

trolltech has other variants of Qt availiable for use with different commerical license schemes

Re:was wondering...

[optikSmoke]

Trolltech sells non-GPL versions of QT to commercial companies, as well, the "free" QT/Windows liscence also has a for-sale commercial counterpart.

Re:was wondering...

[ThatComputerGuy]

Trolltech charges for commercial development using QT (free development is still free). I think this is where most, if not all, of their revenue comes from.

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:was wondering...

[Anonymous Coward]

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

next time, *please* just do your homework....

amazing progress

[ptarmigan]

it's absolutely amazing how quickly Qt and KDE progress; if they keep evolving at the rate they are now (and have been for a while) there's no telling how advanced our desktops will be in a few years!

long live free software!

Re:amazing progress

[Anonymous Coward]

Surely you jest!

Re:amazing progress

[Anonymous Coward]

I do not jest. And don't call me Shirley.

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

[hawkstone]

I think Trolltech has actually done a very good job keeping binary compatibility between versions, at least in the 2.x series. They happen to do so by a method where they create much of their private class data as classes defined in the SOURCE file, not the header file.

This is actually somewhat unfortunate for developers, because it makes it nearly impossible to subclass some of their builtin widgets without copying large sections of their source code. To me that defeats some of the purpose of writing it in C++.

However, there are many obselete functions left over from *old* versions of Qt that had to go away. No one wants to support those kinds of things. And without breaking at least binary compatibility, you can't rip them out of the class definitions and the virtual function tables.

Re:Binary compatibility

[Anonymous Coward]

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

Re:Binary compatibility

[Anonymous Coward]

"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. "

Thats not the major problem for most. The real problem is all the fanatical socialist assholes that wants to socialize the industry, that the real reason Linux is abbandon.

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

[Anonymous Coward]

> This is an issue with C++...

It's kind of funny that C++ is so messed up (IMHO)partly because it tried to extend C and remain largely compatible....

Let's face it C++ is a pile of shite and we need something much better to move onto (I would say Java, but those VM's just kill machines...)

Lets hope for better in .Net?

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

[Anonymous Coward]

Unfortunately, C++ does not provide an easy way to provide binary compatibility. That's why Microsoft developed COM for Windows. COM relies on servers to instantiate the classes, avoiding problems with name mangling. I'm not saying that COM is perfect, but it does solve most problems related to binary compatibility.

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

[Anonymous Coward]

Look, I like swiming in the moana as much as the next guy, but anti-Linux != pro-M$

Re:Binary compatibility

[Arandir]

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?

It's more than just the C++ issue. You change the C++ interface to a class and you lose backward compatibility. But the very same thing happens if you change the interface to a C library. Just because it's easier to mangle [sic] the interfaces with C++, doesn't mean that C is immune to it.

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

[Anonymous Coward]

.net still uses a virtual machine. It might not get the virtual machine == slow that java does since 1) processors are faster now; and 2) initial java compilers didn't optimize, .net will.

Objective C doesn't have the C++ abi problems, but except for NeXT and cocoa OS X, it's unheard of.

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 Coward]

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.

That doesn't actually solve the ABI issue though does it, it just avoids it completly.

I honestly cannot understand why it has taken C++ Compiler manufacturers all this time to even begin to agree on a standard ABI. It's madness.

Re:Binary compatibility

[Anonymous Coward]

Actually, using virtuals methods for everything still doesn't solve the problem - in effect, C++ virtual methods become a hidden struct of function pointers, called a vtable, still vulnerable to offset changes if you insert/remove a function in the wrong place. C++ is just mis-designed. The problem is called the "fragile base class problem". It could only be solved by modifing C++ to not allow low-level trickery involving pointers - but that would (a) break microsoft's COM, which is, in effect, vtables exposed to other languages, and (b) just be recreating native-compiled Java :-).

Re:Binary compatibility

[Anonymous Coward]

Short answer: then don't subclass, use delegation. What did Bjarne Stroustroup think was his biggest mistake in C++ ? Implementation Inheritance!

Re:Binary compatibility

[Rentar]

Objective C doesn't have the C++ abi problems, but except for NeXT and cocoa OS X, it's unheard of.

Where cocoa is basically a Next-Generation NeXT-API AFAIK.

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.

Re:retards

[CtrlPhreak]

I've been disapointed about my story not being posted before, but at least when I post a comment to that effect, I use my name. Get some balls kid.

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

[2ms]

MS isn't allowed to break compatibility b/c their customers pay for software which is guaranteed to continue to work. They'd get sued or something if people were buying/selling software which could be rendered incompatible at any time. KDE and the software that needs to be compatible with it is free, so they don't have the worry of, for example, someone being pissed b/c they just spent $700 for Office and then it didn't work anymore. I assume whatever people will need to stay compatible with KDE will always be free.

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

[cnelzie]

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...

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? Of course that would be if GNOME stays GNOME up to a version 8.0.

Of course, with hard drives getting as big as they are... it really shouldn't matter... Of course since all the apps will be looking for these things in similiar or close to similiar areas that can get to be one helluva large directory.

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

--
.sig seperator
--

Re:Something to think about

[Anonymous Coward]

Hi,

I think the 1.x vs. 8.x case is exactly the kind of situation where you would recompile the app. It's not something the typical user will likely encounter, and the atypical user will likely be able to modify/recompile the app (which usually is not that big of a deal, especially with all the available help channels/forums).

Re:Something to think about

[uchian]

Ummm... this may sound suprising to you, but I have yet to recompile a piece of software so that it works on my Linux box.

You see, this is one of those things that the developers do, and then I just download it from a Debian Mirror. I'm not a CVS-kinda person, I download what is given to me in nice, easy to swallow capsules.

Exactly the same happens with Windows software - how many downloads have you tried in the past which at some point or other said "we do not support Windows ME yet", when it was only a month or so old. Actually, I remember even further when some software didn't officially support Windows 98.Same thing.

Fact is, most Windows people don't compile there own software, but when it comes to Linux... well when it becomes a widespread desktop environment, most people won't compile their own software then either.

At least in Linux you have the choice though.

Re:Something to think about

[Anonymous Coward]

Except compatibility has been broken in the windows world. Have you ever had to have the correct version of an mfcxxx.dll file? Dll's are simply executable code. The wrong dll can cause a program to quit working. I've had to replace dll's because mfc42.dll from 2/1/1999 was not the same as mfc42.dll from 11/20/1999. Dates obviously made up, but the story is true.

Some win3.x apps didn't run on win95. Many drivers needed to be redone for winME. w2k is actually better about this, but there are some programs that can't run under it.

Dll hell is no different that *.so hell or glibc hell. All are examples of software breaking after an upgrade.

Re:Something to think about

[Varitek]

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.

Stuff that makes things better for the programmer will often lead to programs that are more stable. The user wins in the end.

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

[yesthatguy]

They don't even hide it in XP :) There's apparently an option in the application properties where you can choose which compatibility environment you want to run the app in.

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

[QuMa]

Have you looked in your /usr/lib recently? Chances are, it's already one helluva large dir...

As to hunting down 1.x libraries, that's what package managers are for.

Re:Something to think about

[slamb]

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?"

If they don't know how to use the package management system, they shouldn't delete these packages. Having kde1-compat around isn't going to slow your system to a crawl. It takes up about two megs of disk space in RPM format; at most twice that uncompressed. If nothing uses it, it won't ever be loaded into RAM. I only said how to do it because you seemed concerned about hunting down all those 1.x libraries, as you would have to do on a Windows system. Package management does the "hunting" for you here.

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.

*shrug* Don't know what to say. As I said, there I was relaying what I had heard from someone else. It could be wrong, or those applications could be not conveying properly what version of the API they expect. (I believe you have to make a specific functional call for it.)

Re:Something to think about

[Anonymous Coward]

Just telling everone to "recompile your applications" is not going to fly well with the typical user.

If only there were people who could somehow package applications for typical users. They could distribute precompiled binaries!

Ahh, a man can dream...

Re:Something to think about

[colmore]

Yes but forcing upgrades on Linux is different from forcing upgrades on Win. On Windows a complete system upgrade, purchasing new versions of all major applications, could cost thousands of dollars per box, on Linux, it just costs the hassle.

I actually think a lot of problems with computer technology - the 640k limit, a lot of bloat, etc. etc. could be solved by breaking backwards compatibility every once in a while.

true when KDE is a major consumer product ;-) they would probably go about this differently, but for now breaking backwards compatibility isn't THAT much of an issue.

Re:Something to think about

[Anonymous Coward]

.5megs. Really nothing if it works. Somehow I question that it works though. On the compatibility runtime environment. 2000 has that too. As does Mac OS X, but you dont have to set it in X. Isn't it nice how Apple just knows.

Re:Something to think about

[TheMMaster]

On the other hand retaining binary compatibility like microsoft has will eventually end in buggy things like "WIN16 VM" "DOS VM" and other nasty things that make microsoft software the crap it is.
I hate (and when I say hate I mean HATE) microsoft software for the software as well as for the way they are "dealing" with competitors but if they would just throw out ALL DOS support and WIN16 support out of their next release of windows then they MIGHT be able to make a remotly stable system...

We (at linux here) don't have that problem because every distributer has the source to all apps and can recomile if needed, plus that home-users (ok maybe the power users) can do this themselves when they have this really cool space invaders clone written in 1992 that they want to run on glibc10.90

argh... too much coffee, time to do something useful, going to switch the backup tapes now ;-)

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:Something to think about

[Dan D.]

Its a business plan waiting to happen. Make it a service agreement and its the best of both worlds. You charge people to upgrade it for them, sorta an assurance of the latest greatest working model for a modest sum. Then use the rest of your time to contribute to the project your upgrading. Then the users don't have to think about it.

Re:Something to think about

[hoefkens]

> I am sure that KDE 3 and KDE 2 can be installed in parallel

Unfortunately that is not quite true. The format of the config files has changed between KDE2 and KDE3. Other than that, yes you can install them in parallel (but I doubt the usefullness).

Trust me, I know what I am talking about, since I develop for KDE.

Re:retards

[Anonymous Coward]

ooooh i can just feel my hot, sweaty balls resting on that big chin of yours! nice pic!!!

Re:retards

[Anonymous Coward]

Or maybe /. are censoring our submissions. How come there's no mention on the frontpage about TrollTech releasing Qt 3.0?

Re:Killing Gnome softly

[Anonymous Coward]

GNOME has had database abstraction and data-aware widgets for ages, fuckwit.

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.

Oh, joy!

[Anonymous Coward]

Trolltech has done it again. It's nice to see a commercial company with a _working_ businessmodel make it even when they support Linux.

Cross-platform configuration

[Anonymous Coward]

Hmm, I must say that quite frankly QT is the single most impressive piece of code I read in a long time. It's one of the very few software products about which people who don't like it say it's well designed. What I'm missing though, is a cross platform configuration support. I want to use registry on windows, gconf or kconfig on systems that support it or a simple database backend on systems that don't have any of the above. Since now we have database support it shouldn't be hard to code something like this, but I would like to see a native support for that right in QT!

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

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

[Moridineas]

And which part of QT3.0 or KDE wasn't open-source?

Scott

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

[Anonymous Coward]

Never ceases to amaze me how bitchy self proclaimed open-source activists get when they find something that is free as in speech but not as in beer.

If you want Qt for Windows, there's nothing stopping you from coding your own port and releasing it under the GPL.

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

[Anonymous Coward]

"Go Trolls go!"

It's not every day you see THAT moderated up to +4 on Slashdot, is it?

Re:Qt improvement BETTER than KDE improvements

[Anonymous Coward]

And you know, just what the hell is wrong with a company that says "If you want to give your code away, fine, we'll give our code away. But if you want to charge for your code, then we'll charge you." It's called game theory boys. The idea is that you do to the other person what they do to you. If the are nice to you, you are nice to them. If they are bad to you, you are bad to them.

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

[fperez]

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.

No it won't. Qt Non Commercial Edition for Microsoft Windows.

Not that you'd ever bother checking your facts before posting. That would be a grave violation of the Slashdot code of conduct, wouldn't it?

Qt's licencing is pretty simple: GPL code? get Qt for free. Wanna charge $$$? Then pay Trolltech some. Sounds pretty fair to me.

Re:Qt improvement BETTER than KDE improvements

[fault0]

The difference is that GTK+ in Windows at it's present state sucks. It's slow and uses non-native widgets. With Qt, on the other hand, you can't tell what app is Qt-based and non Qt-based.

If you are looking at an alternative, I would suggest WxWindows.

Re:Qt improvement BETTER than KDE improvements

[Anonymous Coward]

except that gtk sucks gonads on windoze

look at gimp/windows

besides, you can use qt/noncommercial on windows it is FREE

i suggest you do your research before posting.

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).

I assume the database API is not threadsafe?

[Anonymous Coward]

Yes? No?

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.

Re:Still not open-source though

[anfloga]

Not sure what you are talking about... IIFC one can recomplile QT from scratch. This, of course, would require absolutely all of the code.

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?

[Anonymous Coward]

The idea of a cross platform GUI is you use the one piece of source for all implementations. Trouble is, different implementations have different ways of dealing with text, sockets (networking) and databases. Therefore Qt supplies these features. If you look, you'll see Qt supplies it's own Char and String classes so people don't have to worry about wchar_t vs. char and so forth.

Re:database functionality... why?

[Anonymous Coward]

Why do you assume that Java "won" the language war? C++ is still very much alive as evidenced by the KDE GUI environment. A cross-platform C++ DB library is very useful.

Re:database functionality... why?

[anal-johnson]

you should know that java sucks, shitfuck

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:database functionality... why?

[Anonymous Coward]

* Do you *really* want to make a frontend in Qt and a backend in Java?

Quite often Java's the easiest way to get the database drivers.

Re:Still not open-source though

[Anonymous Coward]

What do you mean?

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.

Thats hardly any unreasonable request, I think it's great!

We need more people like Trolltech on the Linux-scene and less hippie/fanatics like GNU.

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.

Does Borland still own 10% of TrollTech?

[Anonymous Coward]

Does Borland still own 10% of TrollTech? They bought part of this company when they developed Kylix (Delphi for Linux).

Re:GNOME?

[Anonymous Coward]

You aren't talking about reasonable people here, you are talking about GNU (who stands behind gnome). They are to the computer-scene what the Talibans are to Afghanistan, totally fanatic people who just will not act reasonable in nay way.

They just hate that people can freely sell their own work (trolltechs sells QT licenses) out of their own will.

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.

Re:almost complete source compatibility

[Warwick Allison]

Indeed, another poster here with a 20000 project had to change just 1 line. Generally the compiler will lead you to these lines - when we broke anything we tried to make it break in an obvious way, and there is a porting guide to help you.

But QT *still* has licencing issues

[Anonymous Coward]

Why have these now been swept under the carpet?

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

When will TT replace moc with C++ templates?

[Anonymous Coward]

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

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

[Anonymous Coward]

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

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

[Anonymous Coward]

Hear, here, brother. That MOC shit has got to go. It's an abomination like PRO*C/C++.

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.

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:When will TT replace moc with C++ templates?

[Anonymous Coward]

Prolly never. They have even documented why they think the moc-way is better than templates for s&s.

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

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

[Anonymous Coward]

You may have a point, paleface.
But I hate the fact that it ain't C++, you need to include "foo.moc" at the bottom of your source.

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

[elflord]

But I hate the fact that it ain't C++, you need to include "foo.moc" at the bottom of your source.

You don't have to, and probably shouldn't include
it in your source. Better to put the preprocessed
moc files in different translation units, and
compile those seperately.

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

[fault0]

No you don't.

All the AC posts in this thread are by one person. And they don't know anything about moc in reality.

Re:And thats great!

[Anonymous Coward]

"But QT *still* has licencing issues"

Yes, they do have license issues and that is that they DONT play RMS/GNU/(Insert fanatic of choice here) silly anti-profit/pro-socialist games.

All I say about that is: GO TROLLTECH!

Re:Still not open-source though

[jallen02]

Just so you know.. qt for linux is COMPLETELY GPL'd. Does it get any freer? What do you want public domain? You have access to ALL the source.

Opensource for open software. I compiled Qt from source, what don't you have access to? People love to flame Trolltech for not being open but damn! They made the x11 version of Qt GPL'd.

Nuff said.

Relevant quote...

The Qt/X11 Free Edition is provided with no support and no warranty.

The Qt Free Edition is provided under both the Q Public License ("QPL") and the GPL. This specifies that you may freely use the Qt Free Edition for:

Running software developed by others (e.g. KDE)
Development of open source/non-proprietary software
The Qt Professional / Enterprise Editions are available for development of commercial/proprietary software. If you wish to evaluate Qt/X11 for commercial use, please see the Evaluation information.
and

The current version of Qt/X11 Free Edition is 3.0.0

:)

Jeremy

TrollTech should make a portable Virtual Machine

[Anonymous Coward]

TrollTech should make a portable Virtual Machine and have g++ target code toward it. This way they would be moving into Java platform territory and true portable binary distributions. That would be insanely great. Perhaps with Mono or .NET this will become a reality.

Re:GNOME?

[Anonymous Coward]

Now THAT was a troll for TrollTech! Good to see someone can get it right!

Re:Still not open-source though

[TedCheshireAcad]

Yeah, this is KDE. We don't tolerate that kind of krap.

Re:Qt? Who needs it...

[Anonymous Coward]

I had a look at wxWindows. The API isn't very nice - it makes it very difficult to create good OOP code, indeed to code at all. Basically a person can learn Qt faster than wxWindows and someone who knows Qt could code the same app faster than someone who knows wxWindows

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:Burger King Black Cherry causes Green Feces

[Anonymous Coward]

Oh, that one was my fault. Sorry about that.

With Qt 3.0 is RogueWave now toast?

[Anonymous Coward]

They have threads and database support now. RogueWace also changed their licensing model to be subscription-based (a.k.a. expensive!). I think TrollTech finally has done them in for good.

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.

Kylix

[Anonymous Coward]

They've gotta do DB stuff for Kylix, which is a
moneymaking deal with Borland for TT. Might as
well go whole hog with it.

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!

[Lothar]

Qt for Mac OS X is nice. Problem is the way it's implemented.

As we all know Mac OS X has a powerful API for displaying widgets with the whole PDF rendering technique and it has true transparency.

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.

Of course I realize that a cross plattform GUI can't always take advantage of all different native methods. But in many cases it can.

It's a shame that Qt doesn't use more native interfaces. Hopefully this will change.

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:Kapps for Mac OS X?

[LMCBoy]

Not without quite a bit of work. Either the kdelibs would have to be ported to OSX, or the kapps would have to be made "pure" Qt.

Database code only in Qt Enterprise edition

[Anonymous Coward]

which costs $$$ even for free use.

Re:Database code only in Qt Enterprise edition

[Anonymous Coward]

it's been in all of the qt3-betas, and it's in the free final

stop spreading anti-QT fud, when you've never even looked inside qt and seen if there was db access in the free version or not.

ok thanks bye!

Re:Stallman's response

[RelliK]

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

Bring back QCOM!

[Anonymous Coward]

Ten bucks says that Warwick Alison wrote QCOM. All his APIs suck and are deprecated eventually. He just simply needs to take a course in OO programming for dummies.

Re:Bring back QCOM!

[Mandelbrute]

Ten bucks says that Warwick Alison wrote QCOM. All his APIs suck and are deprecated eventually. He just simply needs to take a course in OO programming for dummies.

Bullshit. He was doing object oriented programming with C++ on an Atari ST well over a decade ago.

Check out Qt nethack for something he did years ago before he went to Troll - it's now been ported to the iPac.

Re:Bring back QCOM!

[Anonymous Coward]

Who cares about nethack? Take a look at any code that he has authored in Qt. Look at the API - it bites! More of his code is obsoleted than any other TT coder. He wrote the deprecated TableView widget, for example. His code is counter-intuitive and awkward. I'm sure glad HE can understand it, because he has to maintain that crap. Who did write QCom anyway?

Re:Bring back QCOM!

[Anonymous Coward]

How brave of you to critizise Warwick anonymously.

I've known Warwick for a number of years and I'm proud to work with him. He's one of the most brilliant programmers I've ever met. He has made enormous contributions bringing Qt to where it is today.

Warwick didn't write QCom or QTableView.

I probably top the list of Qt programmers whose code has been either rewritten or obsoleted.

Haavard Nord
CEO, Trolltech

Re:Bring back QCOM!

[platypus]

How brave of you to critizise Warwick anonymously.

I've known Warwick for a number of years and I'm proud to work with him. He's one of the most brilliant programmers I've ever met. He has made enormous contributions bringing Qt to where it is today.

Warwick didn't write QCom or QTableView.

I probably top the list of Qt programmers whose code has been either rewritten or obsoleted.

Haavard Nord
CEO, Trolltech


wow,

i wish more people had a CEO like you,
this is a very nice gesture.
And I guess you're not an impersonator ;-)

(yeah, moderator) score -1, offtopic

Re:Bring back QCOM!

[navindra]

AFAIK, Matthias Ettrich wrote QCom, but then again he did say he tends to get things right the second time around (with the rewrite).

And as we all known, Matthias *is* a brilliant programmer with results behind him...

Re:Still not open-source though

[corebreech]

When I first saw QT it was not GPL'd, therefore I never paid much attention to it. Now it is. My mistake.

Re:Stallman's response

[ahde]

you deserve more than score 2

Re:Still not open-source though

[peripatetic_bum]

What license it is using to be dual?

But what a great way to go?

I am utterly surprised that the rest opensource is liscensed like this?

Of course, if someone pays to keep it closed i geuss that is ok and you make a sensible choice in choosing the "closed" software versus having a piece that is completely open ala RMS.

Anyway, what o people think that people if given the choice can be sensible in choosing between liscenses?

(-5, Trool, Offtopic)

[Anonymous Coward]

Isn't TrollTech the company which manufactures /. posters? :)

Re:I'm a troll

[geomcbay]

Well, you responded didn't you?

Clearly this was an example of their advanced new meta-troll...Those TrollTech folk are at least 2 years ahead of us civilians when it comes to trolling technology.

for Mac OS X as well !

[wdavies]

I got this press release from Mac Dev -- I am quite surprised -- is this very new ? Does it
mean we'll be able to get lots of Linux Apps on
Mac OS X soon ? How many products are our there that use Qt exclusively ?

Winton

--For Release Monday, Oct. 15, 9am PST--

Trolltech Releases Qt/Mac for Mac OS X

2000/10/15 - Oslo, Norway - With its release of Qt/Mac, Trolltech has added
Apple Macintosh to the list of platforms supported by Qt, an emerging
industry standard in cross-platform software development. Application
developers using Qt can now target Mac OS X with the same ease, as they are
currently targeting Windows, Linux, Unix, and embedded Linux systems. Qt
allows developers to create a single source tree that will run on all these
major platforms.

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.

"With the introduction of Qt/Mac, we can offer benefits to both our
existing customers and to Mac users," says Haavard Nord, CEO of Trolltech.
"Qt developers now have millions of new users they can target with existing
Qt applications. And Mac users now has a completely new set of more than
ten thousand applications that can run on the Macintosh platform."

Eirik Eng, Trolltech's president, said Trolltech had taken pains to ensure
that Mac users would feel comfortable with Qt applications. "Qt/Mac has the
Aqua look and feel, so all Mac users will feel right at home with programs
developed with Qt," he said. "It is exciting to see Qt applications running
on Mac OS X. The Qt functionality integrated with the cool look and feel
the Aqua-style provides is impressive."

In addition to all the above-mentioned features, Qt/Mac has all the
elements of Qt 3.0. The database capability gives Mac developers the
ability to create applications that are both database- and
platform-independent. Qt Designer is now a fully-fledged GUI builder with
main-window development capability and, and an integrated C++ editor. Qt
Linguist provides easy translation of Qt GUIs to different languages. Qt
Assistant eases browsing and finding information in the Qt Documentation.

Qt/Mac is released under the following licences: The Qt Professional and
Enterprise Editions. Available for the development of
proprietary/commercial software on Windows, Linux, Unix and Mac OS X
The Qt Academic License. Allows schools and universities to acquire and use
Qt for free in relevant courses.

.... some Trolltech stuff at end

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 ?

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

[hack0rama]

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.

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:QT Pricing

[Anonymous Coward]

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

No, it's not. It's free for non-commercial software in a non-commercial setting. GPLed code is not compatible with that unless you add exceptions to the license.

A much better strategy would be to make the Cygwin/mingw port of Xfree86 non-rooted. There exists such a beast for OS/X (see the macgimp project), but the version for Cygwin+friends still requires a root window and non-native window management. I believe the problem with making a Windows port was that the consumer Windows line didn't have the OS guts to handle it - it would only work on NT/2000+. Maybe some uberhacker will read this post and say, "I bet I can force it to work!" and we'll have non-rooted X11 on consumer Windows. :)

With a native non-rooted X11 for Windows, you'd be able to run all existing X applications on Windows with minimal (if any) source tweaking. The disadvantage would be that the widgets used would not be native to the platform. (That's why it's important to port widget sets natively). Still, the advantages are simply huge of having a non-rooted X11 server that can be ported to different platforms.

Re:QT Pricing

[rabidcow]

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.

Do hobby programmers always have to give their stuff away for free? What if I want to write a shareware app and sell it for $20? Sure, it'd be nice for me to give it away, but I'm not rich. Unless it's a very popular program, there's no way I'd get $1500 from something like that.

Sorry Trolltech, your product doesn't interest me in the corporate price range. Microsoft has various versions of VC for this reason, professional, standard, student, etc. Perhaps you guys might wanna look into allowing small customers to license *parts* of the library?

Re:QT Pricing

[Anonymous Coward]

If you're not going to make $1500, then what's your purpose in distributing it at all? Get serious, put in the extra effort, and make your product commercial. Low-income shareware (note: some shareware authors make PLENTY) is really a waste of everyone's time. Write it for free (and release the source, generating al lot more community wealth than $1500), or put in the extra work to make something that people will really pay for (not just pay you $20 occassionally out of guilt, pity, or charity).

Re:QT Pricing

[rabidcow]

Ok, put it this way: I might make enough money to justify paying the fees for this toolkit, I might not. There's no way to know until *after* I've developed and released it, at which point it's too late.

Now, I could assume I'll release it for free and just develop with QT, then decide after it's written if I want to pay the fees or not, (ie, if the program seems like it's worth something) but *my* opinion isn't what's important.

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?

Slaves?

[Mandelbrute]

Exodus 21:7 God recommends acquiring slaves from the nations around you.

Eh?

Loco gringos!

Re:Slaves?

[Anonymous Coward]

What bible did you get that from?

Exodus deals with the fair treatment of slaves, basically a slave girls treatment is more or less equivalent to the divorce of a man and woman in Western civilization:

Chapter 21 7-11 reads the following:

7 When a man sells his daughter as a slave, she will not be freed at the end of six years as the men are.

Here is the rest of that chunk,
8 If she does not please the man who bought her, he may allow her to be bought back again. But he is not allowed to sell her to foreigners, since he is the one who broke the contract with her.
9 And if the slave girl's owner arranges for her to marry his son, he may no longer treat her as a slave girl, but he must treat her as his daughter.
10 If he himself marries her and then takes another wife, he may not reduce her food or clothing or fail to sleep with her as his wife. 11 If he fails in any of these three ways, she may leave as a free woman without making any payment.

"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.

Re:"but MS has succeeded in killing desktop Java"

[LinoNutTom]

> 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.

That can often times be a very big "if."

Even on 1.7GHz machines, I find the JFC to be pathetic. It probably always will be by comparison to C/C++ based user interfaces.

When Java starts to make someone like *me* nostalgic for C++, you know there's something wrong with it!

Re:Stallman's response

[Anonymous Coward]

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

doubtful. stallman's usefulness is finished. he needs to be replaced with someone more mature and not so blinded by ideology.

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?

[Anonymous Coward]

It's amazing how little you know about Qt licensing considering how much you have bitched about it on slashdot.

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?

[fault0]

You can port Qt/X11 to Windows pretty easily (provided you knew enough Xlib and Win32 api). The seperation of X11 code is very well done in Qt (the qfoobar_x11.cxx files, about 20 of them).

Since it is GPL'd, if anyone wants to do it, go ahead :)>.

Their reasoning for different licenses for different platforms is that X11 is based upon free software (so Qt should be free software for it), while Windows, and the vast majority of Windows stuff is not free software (so Qt should not be). It'd really the idea of mixing in with your crowd to be accepted, which is very valid, imho.

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...

[Anonymous Coward]

Grumble, Grumble... wxWindows.org is slashdotted. Just as I'm trying to convince others to try it.

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

Re:Stallman's response

[plastercast]

Yea, who wants someone who believes in something!

Seriously though, whats wrong with an ideology? He doesn't/can't force it on you or anyone else, and many people agree with him on many issues (myself included). I don't understand why so many people feel the need for everything to be seperated from oppinion.

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.

Re:yacc ...

[Anonymous Coward]

They should get rid of moc altogether, IMO.

Re:yacc ...

[Anonymous Coward]

try using biacc.
without the bugs of bison, and with the standardization of yacc.

Re:yacc ...

[_generica]

well, i gave compiling with bison a go anyway... last time i tried this was beta2, and it failed dismally... this time, it seems to have succeeded. So now they're only guilty of misleading/wrong/old documentation. A slightly lesser crime, but still.

Re:yacc ...

[Anonymous Coward]

Huh?

$ which yacc
/usr/bin/yacc

This is on SuSE. What broken distro doesn't have yacc installed?

Re:yacc ...

[_generica]

http://www.linuxfromscratch.org

Why (or how, for that matter) would I install a program that I can't find the source for. Bison is gnu's yacc. Why would I use a program that hasn't been updated in the last 5 years, as compared to one under active development.

Re:Still not open-source though

[Anonymous Coward]

Dumb fucking asshole, Troll$hit will take your free code and then charge you a lot of money if you ever want get a little bit in return by releasing a commercial app.

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:No, it's not

[Accumulator]

Hm. I talked to a couple of Trolltechs employees some weeks ago. They said explicitly clear that they've recently made Qt for Win32 (binary) free for free apps. One of those two, was one of Qt's founders.

Or are you saying the founder of Qt is lying?

Re:Still not open-source though

[colmore]

yeah! i want to use their code for my profit without giving them anything!

it's not like they sank countless R+D $$$ into making the quality product that they're handing out for free.

jackass

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.

Yes, you can.

[fault0]

You've never heard of Qt/Windows Non-Commercial?
You can't develop GPL'd apps (the gpl is incomptible, but you can use less restrictive licences such as BSD and MIT).

precision

[fperez]

just a quick fact: you cant' licence gpl under win32 b/c qt/win isn't itself gpl. But you can use other free software licences (mit, artistic,...).

With this precision, the above stands.

Server Architecture Crucial

[Anonymous Coward]

I absolutely depend on the X server architecture both at work and at home. I run my employer's Solaris software by displaying on my Linux desktop. I often need to display from East Coast to West Coast.

At home I run the apps on my wife's emachine and display on my own Pentium 166 MHz/48 MB.

Marko

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: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:No, it's not - Yes it is

[Raato]

Take a look here [www.troll.no]. So the FAQ is outdated and Qt/Win is available for free for non commercial products (as is the case with Qt/X11).

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:Stallman's response

[Anonymous Coward]

"Seriously though, whats wrong with an ideology? "

There is a difference with a balanced ideology and blind fanatism and RMS is the latter.

Re:Still not open-source though

[aanantha]

It can get more open source. GNOME and GTK+ are LGPL'd, meaning you can compile and sell closed source software that links with them. The GPL forbids this. So if you want to write commercial closed source code with Qt, you need to pay about $1500-$2000 for a Qt Professional license.

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...

[Anonymous Coward]

The "not-deleting" is not that important for me, before I worked with several other libraries, which used the same/sim. aproach: allways on the heap - the toolkit will delete all. What I think would be good, when the toolkit would be avare of deletion (overloaded operator), so a mistake would not produce core - but maybe this is allready fixed - I did not checked.

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...

[Guillaume Laurent]

> primarily the way that the framework breaks the "new/delete" idiom.

It doesn't break it, it hides it from you. That's what any good library should do, hide the complexity from the programmer.

> but for those who're using Qt/KDE is this a big concern ?

It's actually one of the biggest advantages of Qt over any C/C++ UI toolkit I know.

> Do you write a handler wrapper class around widgets that hides this mis-match, or do you just live with it ?

We very happily live with it. What would be the point of resisting this ? Qt frees you of having to delete Qt objects. That's one less chore you have to tend to, and a fairly nasty and error-prone one to boot. Why would you want to get it back ?

This is like saying std::string is bad because it frees you from allocating and freeing char arrays.

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

[MeerCat]

It doesn't break it, it hides it from you. That's what any good library should do, hide the complexity from the programmer [...] This is like saying std::string is bad because it frees you from allocating and freeing char arrays.

Well, YMMV, but from my point of you it doesn't hide it from me - I still have to allocate it but remember not to free it (cf std::string which looks after both parts), and this is in contrast to every other resource I allocate, so it costs me mental space to remember the exceptions (to the rule, not "C++ exceptions").

Note that I'm not denying that you may be able to live with it, I'm just pointing out that I can't without something to help (thanks for the reply anyway) ... see also my longer response to another's reply...

T

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

[Guillaume Laurent]

> so it costs me mental space to remember the exceptions

I suggest you look at Qt before saying this. You seem to make an awful fuss over an extremely simple rule : QObjects have parents, parents delete their children. That's all there is to it. In practice this means that I can do this :

QVBox *box = new QVBox(mainwindow);
new QLabel("a label", box);
new QLabel("another label", box);

and this is not a leak, because box owns the labels. I've been using Qt both at home and at work for almost two years. I've had to do a few emergency patches under pressure. This memory management paradigm has *never* been a problem, because it's so obvious.

> I'm just pointing out that I can't without something to help (thanks for the reply anyway) ...

Come on, every C++ project above 2 kloc has to set some memory management policy for some classes. At some point you have to clearly specify "this object owns this one and is in charge of deleting it, while this other is not". That's one of the nastiest side of C++, and it's never straightforward. And for once, Qt handles this very well.

> see also my longer response to another's reply...

I've read it, it is flawed for two reasons :

- you are still perfectly allowed to delete a widget, it will unmap itself and tell his parent about it

- you generally don't "set" widgets, these aren't attributes you give to a class. You just create them and let them live.

I suggest you take a look at the Qt tutorial, it seems you're just building your opinion on Al Stevens' article.

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

[MeerCat]

I suggest you take a look at the Qt tutorial, it seems you're just building your opinion on Al Stevens' article

I did look at the tutorials (they tend not to talk about it too much, I also have 2 books on Qt and one on KDE), and I have read the article, but nothing compares to using-in-anger-for-6-months (which I haven't done) or, failing that, asking those who have done so.... ;^)

this is not a leak, because box owns the labels

I know this, but the point is that when reading the code I have to know this - every time. What if I read the code of one of my colleagues and he makes an instance of class MyHandyClass and then doesn't free it ? I now have to look at the class definition to see if it is in some way derived from a Qt class to know if this is a bug or not... I'm not doubting that it can work (hell, I've seen all sorts of nasty code that works) but it doesn't make for code that can be easily seen to be correct - and that makes for code that is hard to maintain.

every C++ project above 2 kloc has to set some memory management policy for some classes

Exactly, and the bigger the project the more you aim to have one policy to bind them all. I don't like cosmic class libraries because they force their policy on all my code, similarly I'm not too keen on those that break the core language idioms.

you are still perfectly allowed to delete a widget, it will unmap itself and tell his parent about it

Ah, now that's very handy to know. So when Stevens says:

If you instantiate a widget on the heap as you must but then delete it yourself, as you are conditioned by your proper upbringing to do, the program fails when the parent deletes the widget a second time. Another heap of trouble.

then that's wrong ? Again, I'm not being sarcastic, I just want to know....

you generally don't "set" widgets

True, but I was simply illustrating a common example of a bad class design practice that can work, but tends to break over time - that is giving a resource to someone else to manage. The usual C++ practice, from the C practices before it, is "you are responsible for what you make".

Cheers

T

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

[Bluefire]

Ah, now that's very handy to know. So when Stevens says:

If you instantiate a widget on the heap as you must but then delete it yourself, as you are conditioned by your proper upbringing to do, the program fails when the parent deletes the widget a second time. Another heap of trouble.

then that's wrong ? Again, I'm not being sarcastic, I just want to know....

Yes he's wrong, it just shows hes got lots of opinions on things he don't know about

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

[Guillaume Laurent]

> asking those who have done so

I have, so have many others, and the verdict is always the same : Qt is remarkably easy to use, including on large projects. Especially on large projects, actually.

> I know this, but the point is that when reading the code I have to know this - every time.

I understand, but in practice I really don't think it will take you more than 10 seconds to get used to it. Honestly.

> he makes an instance of class MyHandyClass and then doesn't free it ? I now have to look at the class definition to see if it is in some way derived from a Qt class [...]

But you'll have big hint on whether this is correct or not : the class ctor will have a "parent" QWidget (or QObject) argument. The context of the code will also be a strong indication.

And also, this is something common to most OO languages, you very often have to check what a class is derived from to make sure of how it should be used...

> I don't like cosmic class libraries because they force their policy on all my code,

But that's actually a good thing. That's one less thing to worry about, and less complexity to deal with.

> similarly I'm not too keen on those that break the core language idioms

I disagree. Every midly complex C++ class hierarchy will implement some kind of memory management policy, it will either be value-based or pointer based, etc... thus bending the idiom in his own way.

If a library leaves up to you the task of managing its memory, I think it's a failure. That was one of our main disagreements with Karl Nelson when I left Gtk-- actually, and it seems Murray Cummings (the current de facto maintainer), also thinks like you :-). But in practice, I still find it to be a huge asset.

> then that's wrong ? Again, I'm not being sarcastic, I just want to know....

Well, I've just checked in a small example and it seems I'm right.

> a common example of a bad class design practice that can work, but tends to break over time - that is giving a resource to someone else to manage.

But this is extremely common :-). And I'm not sure how you can avoid this in reality. Or if the added complexity of the code is worth the cost. I think that the only policy which scales well and withstand "real life" is to make an API as easy to use as possible, and choose your policies according to that, not according to what people know or might know. Exposing nuts and bolts because you think it might otherwise confuse people doesn't work.

And as far as "breaking over time" goes, I think that if Qt's design was brittle, KDE would have broken down a long time ago already.

Feel free to email me if you want to push this discussion further, as /. is a bit of a clumsy medium.

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...

[MeerCat]

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.

So why not make a rule that in all these classes the constructors are protected (so they can be derived from) and they also declare a friend of a template class that just makes instances. This means that users of your library can't make instances directly (so they don't accidentally make them on the stack), they always have to do something like...

MyObj * p = Helper::MakeNewOne(args);

Not the prettiest in the world, but hell, I've seen STL and ATL and the above is not too bad.

Why do this ? Well, reading the code I can see that I asked for it to be made, but I didn't actually new it, so presumably I'm not the one to delete it (we actually made the destructors protected too). It also prevents me from making one on the stack (part of the "if I shouldn't do it, then I shouldn't be able to it" philosophy), and it puts the onus on those deriving new classes to follow the rules, rather than those USING the classes - and deriving is always less common and a more responsible task than using ....

Just a thought, but this is the sort of thing I try to do with my own code (for example, a shared-create-on-demand-freed-when-scarce-resource ) and it makes it much easier for people to use a class if they know that anything that they CAN call they are ALLOWED to call... and it makes it easier for the class designer because he knows that his class can't be misused.

Compare this to the deep-copy / shallow-copy problem : the way we fix that is to make the Copy Constructor and Assign Operator private and undefined - that way you use the language to prevent misuse...

Cheers

T

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

[MeerCat]

Exposing nuts and bolts because you think it might otherwise confuse people doesn't work

I work on the basis that you expose only those functions that people are allowed to use - if they're not allowed to make and delete objects in every way they want, then you make the ctor and dtors not available, and expose them via an object or class that controls what you can or can't do. For example, I wrote a smart-pointer based framework for working with databases that had all objects as const objects, the only way to get a non-const pointer to an object was to make a Transaction object and ask that to get you a non-const pointer - it actually gave you back a modifiable copy of the object, locked the original object to prevent it taking part in another Transaction, and then the Transaction object could give you Commit and Abandon functions that would write your copy over the original or discard it. The point of it was that it controlled what you do and when - you couldn't call a non-const member of an object without starting a Transaction... Transactions abandoned themselves unless Committed before destruction, lots of code could share objects knowing that there were language-enforced rules governing what changed what.

[ Don't get me started on the problems of programmers trying to figure how to get the right parameters to call the public method OnPaint() because it's not obvious that in fact they should simply be calling InvalidateRect().... ]

Feel free to email me if you want to push this discussion further

Thank you for the offer, I may well do so... I'm not after "proving I'm right", but I'd like to take a little of your time to ask you more about whether Qt is, in fact, for me for a rather interesting but large product idea I have in mind....

Cheers, and thanks for the answers so far...

T

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...

[Anonymous Coward]

Maybe I'm missing something, but I believe in Qt you can call setAutoDelete( FALSE ); and then the automatic cleanup of objects is *not* done for you, and you can call delete as you require.

Did I miss something ??

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

[MeerCat]

Maybe I'm missing something, but I believe in Qt you can call setAutoDelete( FALSE ); [...] Did I miss something ??

Hey, I'm just asking the questions - I know nothing much about Qt except what I've read, and I'll freely admit it !!

But from what I've seen of the doucmentation I think the setAutoDelete() only applies to the Qt container classes (those derived from QCollection), whereas we're talking about the GUI framework classes (which derive from QObject).

Thanks for heads-up, all these contributions at least let me know that either what I see as a problem tends not to be a problem in practice, and that there may be ways to avoid it that I can investigate anyway.

Cheers

T

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

[MeerCat]

Actually I *want* the users to be able to create the objects on the stack

Without looking at exactly what you want to do, the usual answer in C++ is "add another level of indirection". Make a handler class that people can make and destroy on the stack or the heap as they want, and make that handler class manage the real resource - look at "smart pointer" classes to see how best to do this generically, or you can use hand-coded or template classes if you only have a few classes that need wrapping.

I have tried to stop the copy & assignment by making them private and undefined. Unfortunately the stupid MicroSoft VC++ does not like this

Are you sure ?? This technique has been around for 10+ years, I can't see (even) MS breaking this. I presume you're getting a link time error, in which case it means someone is actually trying to call the CC or AO !! I'd check your code, and if necessary get a port of NM (such as from MinGW to let you examine your object files to see who's listing the CC or AO as a unresolved symbol....

T

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...

[MeerCat]

Maybe we should take it offline (you can mail me at schmerg.com) but if by "shared library" you mean a DLL... well I can compile and link the code below into a DLL, but note that uncommenting either of the two lines stops from building the DLL (note that BadFunc is inlined by the compiler so generates no code unless its called). A DLL is basically a slightly different EXE in that it must have all its external references resolved ... but I can't see why else you'd be prevented unless, as I pointed out, someone is actually trying to invoke the undefined routines... if I run nm over the OBJ then I can see the symbols that it defines and those that are unresolved....


#define WIN32_LEAN_AND_MEAN
#include

class Uncopyable
{
public:
Uncopyable() { _data = 0; }
~Uncopyable() { ; }

void BadFunc() { Uncopyable other = *this; }
private:
// private CC and AO - undefined....
Uncopyable( const Uncopyable& );
Uncopyable& operator=(const Uncopyable&);
private:
int _data;
};

BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved )
{
Uncopyable u, u2;
// Fails to compile with this line : u = u2;
// fails to link with this line : u.BadFunc();

return TRUE;
}


If you mean something else, then I apologise in advance for mis-understanding.... but I would like to know what the problem is (in case it affects me sometime - maybe it's something in the debug info that is causing the problem, are you compiling with something that instruments the code like Purify ??)

Cheers

Tim

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...

[MeerCat]

Ah yes, I see what you mean, if you're declaring APIENTRY (which ends up being #defined to __stdcall) then I can see that MS may well be forcing a requirement for the entry to be defined when you link with it....

Reminds me what I dislike about developing on Win32 (the side effects) ...

The Uncopyable class that I listed, however, can be private within the DLL (with no external linkage) and included as a member variable of the objects you want to prevent copying - that way you don't declare the CC and AO in those classes, and if the compiler tries to make them for you then it'll generate a compile time syntax error...

Of course, if you do this you'd want to reduce Uncopyable to the bare minimum (get rid of the data, the BadFunc, null constructor, destructor) and it'll add very slightly to the size of your objects I guess (4 bytes maybe) ... but I'm fairly sure that would get you what you need...

Regards

T

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:Question about Steven's comments in Dr Dobbs...

[MeerCat]

We should stop chatting like this... people will talk ....

Shared libraries under *nix are genuine simple collections of routines (in the same way that non-shared libraries are effectively just a tar file of a load of object files : no linking has been done) - so they need a further link stage when you load them as they can have undefined symbols.

DLLs under Win32 cannot have any undefined symbols - they have alreayd been linked like an executable and have all symbols resolved (even if that means via an implib stub which then points at another DLL). This makes life easier in some ways as you know that all symbols are resolved before you load the library, but means that you can't do things like "this library, when loaded, expects the code loading it to have defined a function Fred() which it will call at certain times" - the DLL's resolution of Fred must be done when you link the DLL. It also makes loading quicker, as no link is required (and of course the linker is not an integral part of the OS as it is under *nix).

You can emulate some of this with dynamic loading of DLLs where you don't link with an import library but call LoadLibrary() and then use GetProcAddress() to find the functions you want and decide what to do if they're not there (i.e. manual linking within your code), but its a pain on anythign more than the most trivial of cases.

You have to understand just what a DLL is and how it's doing it - back in the old Win16 days you could share data between apps in a DLL as a DLL had its own data page no matter how many times it was loaded, but then you had to frig with the stack pointer on every exported function (SS != DS) !

As for your comments about ugly code I can only agree - I go back to C++ every now and then, and it almost makes me cry how my old favourite has been made as ugly as sin by people with no eye for aesthetics....

Cheers

T

Re:And thats great!

[platypus]

This is not quite true, it's more like they exactly play these games (while not ideologically motivated) more than some gnu software. gpl + "pay-for-commercial-closed-source-use" is more fsf-style than lgpl I think, in that it encourages you to use gpl for your software.

OTOH, the where the parent poster now sees "licencing issues" escapes me. I think he is just confused.

doesn't compile with gcc 3.0.1

[Anonymous Coward]

i didn't think it would

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:Qt? Who needs it...

[tal197]

There is some nice software like Audacity and Roxfiler using it,

ROX-Filer doesn't use wxWindows, it used GTK+.

Re:Qt? Who needs it...

[jonathan_ingram]

Yes, I noticed that about 10 minutes after posting... but what can you do? :)

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.

Re:Still not open-source though

[Anonymous Coward]

And what's so wrong with that? I think it's a good thing that you have to pay for it if you're going to make money with it yourself.

Or write a toolkit like this yourself, so you don't have to pay for it.

Yes, you can use GTK for your commercial products, but in what way do you support the GTK by doing that?

Re:speed of Qt

[mimbleton]

"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. "

I agree that X is slow but WM is not a problem. You can easily bypass WM and do your own window management and you will see that there is no difference in performance.
The problem is somewhere with Xserver or Xlib.

Re:TrollTech should make a portable Virtual Machin

[Androgynous Howard]

That is not true. Virtual Machines do not always result in lower performance. And the benefits of a platform-independent binary format would be *huge*. Imagine having the same binary for KDE/BSD, KDE/Linux and KDE/Solaris. Ordinary people do not want to compile source code. They do not want to know that they have to use --prefix=/usr with debian and --prefix=/opt with suse. They want to remove applications by deleting a directory. All this is trivial with a decent high-level object format, and almost impossible with C++. C++ is not the best language to write large desktop environments. Objective C is much better, and Java or C# would be heaven!

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...

Trolltech, eh?

[PurpleFloyd]

One only wonders where they came up with the name QT: "Hey, man, that Natalie Portman is one QT!"

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:Finally for the Mac! (redundant?)

[Lothar]

> 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.

Sorry for not agreeing with you there. Are you telling me that Qt renders transparency as fast as the native API on Max OS X? I say your wrong. Plus the fact that it's only faking it.

The problem with plattform independence is obvious. You can't take advantage of the plattform dependent optimizations cause that usually breaks your design! This is an inherent problem. You sacrifice performance for interoperability.

Disclaimer: I'm not an Max OS X expert.... but as for Object C - I like it.
Now - how would Object C++ be.....

Re:TrollTech should make a portable Virtual Machin

[Anonymous Coward]

You create your Java "heaven," and I'll stick with my myriad language GNOME/KDE "hell."

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?

You are wrong [ was Re:Finally for the Mac!]

[ettrich]

Where do you get the idea from that Qt fakes transparency on MacOS X? Let me confirm you that you are simply wrong. We do indeed use the MacOS X API rather than operating directly on its framebuffer as you seem to indicate. Speed thus is roughly the same as native Mac applications.