Trolltech is now previewing Qt 3.0: "Among the new capabilities in Qt 3.0 are: database support; data-aware widgets that provide automotive synchronization between the GUI and the underlying database; a new version of Qt Designer that has become a full-function GUI builder; comprehensive internationalization; and a host of other improvements."
Check out the announcement for full details; Qt 3.0 snapshots can be found here.

Remember, QT isn't just a graphics toolkit. It's a true cross-platform development environment. That means if TrollTech wants QT programs to be able to use a feature, they have to implement it all themselves inside QT so they can guarantee it works exactly the same way on every platform they support, with the same API. That's why they're inventing their own object model and stuff. They have no ambition to create their own OS, they just want to improve their development environment.

CORBA is hardly a component model (though it can be used as the foundation for one, as Bonobo has demonstrated). My guess would be that the main motivation behind this new feature in Qt is to be able to use COM objects on Windows without sacrificing platform independance. COM is after all still the only really widely used component model and a cross platform toolkit must have some support for it. CORBA has got a good foothold in client-server applications, but is really only at an experimental stage in component architectures.

COM is a windows only thing, DCOM is cross platform, but there exist almost no implimentations for it on anything but windows. DCOM is also horribly complex, more-so than CORBA, it's easy to use in VB but it's heavily wrapped. CORBA works fine as a component model, it just takes alot of extra code.

Qt3 will have HTTP support, database access and even its own component model. KDE already has (or at least in CVS) all of these things, is there any concern about this duplication of efforts? Having a functionality twice seems like bloat to me :(

However, we all appreciate the wizardry that's going on at Trolltech. I'm looking forward to Qt3 a lot!

I'm interested in learning Trolltech component model as oppose to KParts. And how will this new component model communicate ... is it via DCOP or CORBA.

Another question, will the new Qt designer replace KDevelop? Or will it complement KDevelop? From the features list I think Qt designer is going all out as a RAD which KDevelop has been doing for over 3 years.

TrollTech's main concern is money(at least I hope so), what they sell is an XP tool kit. There's X toolkits just as good that are free(please don't flame me for saying that, IMHO Fltk, Gtk and Motif are just as good) the reason that most people _buy_ Qt is because it's XP.

Since most Linux users tend to smoke crack, I'm going to say that this is not a troll, so please be nice, it's just my opinion.

Atilla, you chose your name wisely. No need to attack someone for this justified question. You're right that Trolltech is formally independent from KDE, but what would Qt be without KDE? Trolltech must be and surely is aware of KDE.

But quite some core KDE developers are employed by Trolltech, and I'm sure they all know what they are doing.

"The correct behavior can be summarized as follows: CLIPBOARD works just like the clipboard on Mac or Windows; it only changes on explicit cut/copy. PRIMARY is an "easter egg" for expert users, regular users can just ignore it; it's normally pastable only via middle-mouse-click."

Will KDE 3.0 be adopting this behaviour (I personally find the standard X, 'copy to clipboard on select' unusable, and would like to just turn it off and forget it)?

The article says nothing about the format of the clipboard - are there any inter-operability issues between, say the GNOME clipboard format, and the KDE one? I know that KDE 1.x had just 2 data types, but KDE 2.x can copy any mime type, but not much more. What format will the Qt 3.0 clipboard have?

I like the way as described from the paper Qt 3.0 ways from using cut and paste.

Select should copy the selection to the PRIMARY and using "Ctrl-X" to put selection to clipboard is the proper way.

Coming from a windoze world, this is one of the most useful feature. It took me over 4 months to relearn the "cut and paste" in the windoze world to accomodate for KDE lack of paste over selection feature.

In Konqueror, KDE team create an "X" button on the address bar to clear the line so you can paste URL if you intend to do "paste over selection". I find that annoying after a while :)

>Will KDE 3.0 be adopting this behaviour (I personally find the standard X, 'copy to clipboard on select' unusable, and would like to just turn it off and forget it)?

Yes, of course, since KDE is based on QT. This is probably my favorite feature of the new QT. Finally!

>are there any inter-operability issues between, say the GNOME clipboard format, and the KDE one? What format will the Qt 3.0 clipboard have?

Support for multiple clipboards is built into X itself. Right now, everyone uses only one of the X clipboards by general convention. The new QT will use more than one. I believe the general effect will be that GNOME or other apps will only be able to "see" one of QT's 2 clipboards.

Yes, I think the solution with 2 clipboards should work well. It should be able please both types of users - 'normal' (like myself) and 'X power user' (like yourself). I assume some KDE code will need changing in moving from 2.x to 3.0, I don't think it will happen just by linking against Qt 3.0.

Copy and paste in a modeless editor was invented by Larry Tesler at XEROX Parc for the Smalltalk-76 programming environment, in 1973-76. In Smalltalk, when you selected some text you had a large number of commands you could apply to the selection; 'again', 'copy', 'cut', 'paste', 'doit', 'compile', 'undo', 'cancel', 'align'. So it less likely that the command you would want to use 80% of the time would be 'copy'.

In the original world of X-Windows, you just had 4 xterms. If you selected some text, the *only* command you could do was 'copy'. Hence, the origination of this shortcut I believe.

I would like to have a few of those Smalltalk commands back via a right click of the mouse - more convenient than cntrl+C etc. And what about an option to have scrollbars on the left again (the correct side for ragged right justified text)? The old ideas are still often the best!

The primary clipboard is built in, always active, and in fact there IS no other clipboard.

Klipper, and the QT clipboard, would have to be expanded to allow more then text to be added, and accomodate by, say, inserting "", if attempting to do something stupid like copy a png from kword into kedit.

Klipper displays a list of recently selected items, using perhaps konqy technology to provide image previews, and if an item is clicked, klipper copies that item to the real clipboard. Middle mouse button becomes a shortcut for paste.

Klipper would also have an option, "Selected items automatically copied to clipboard"

Then, we could add a "Klipmarks" menu to klipper, to allow the user to permanently store any item in the clipboard. In addition to this, klipper would now also display the current clipboard contents.

This way, you would have only one clipboard, but still would have the power to do selection-to-clipboard, if you so chose.

As for copying & pasting graphics, I think that's one of the most useful things with Mac or Windows, especially the Mac. I can select part of a graphic (say, a screenshot) and then paste that directly into Word (or some other word processor).

It's a whole lot faster than creating the graphic, saving it, and then inserting it into the document.

I guess they are trying to emulate ActiveX style data binding. The easiest example is you can have a GUI table widget that mirrors the information in a Database Table. The only place this is widely used is in the Visual Basic world. It's a nice gee whiz feature, but makes for poor program design in my book. The GUI should never be so closely linked with the backend database.

Wow this sounds great! Finnally Linux will have a RAD tools comparable to Delphi and Borland Builder. (Of course we allready have in the form of Kylix, but I prefer Qt and this will give us a RAD tool for free. As long as we do open source devel of course).

That sounds nice. You mean they will make it free for open source devel or are they going to opensource the whole program?

I know Kylix is based on Qt but I have tried Borland Builder and even though it was a great well integrated IDE I prefer Qt. I think the modularity and the design of the class hierarchy is one of the great strenghts of Qt. Even Borland Builder doesn't have that well designed class hierarchy.

I really hope Kylix will be successfull on Linux though. It's important for Linux that companies like Borland make Linux products.

Borland's compiler and IDE will be closed source, but there will be a free version that can be used to write GPL software(like Qt), the problem with Kylix though is that it's linux x86 and windows only.

Many modern windows applications (e.g. winamp I think) have different sections to their GUI that all move as one window but can be dettatched from each other, and then attached again.

Normally I think this looks ugly but sometimes there is a need for this type of feature. Kppp's debug window doesn't seem right separated from kppp. Although I'm sure some would like the option to do that.