Back in November, Reginald Stadlbauer announced a new rich text widget for Qt. That widget could provide, he said, a very stable base for KWord. So a rich text branch of KWord was started and became the focal point of KWord development... The problem was that the new widget was only slated to appear in Qt3. Recently, Thomas Zander reasoned that a stable Qt3 was too far off and considering that current users needed more support right now, came to the conclusion that it might be best to drop the coolness-enhanced branch. Fortunately, David Faure valiantly tackled the task of backporting the Qt3 rich text widget to Qt2 and succeeded! This could be a big boost to rapid KWord development.

It's at the moment in the koffice source tree, but it might be moved to a more common place (kdelibs) in case KWrite and/or e.g. ksirc want to use it too.

Basically, if the next KOffice is ready before Qt 3, those classes will be part of it if nothing changes. But I doubt that will happen, I expect that Qt 3 will be out before KWord is done - unless you all give a hand :)

... and many new features. Like, in the current KWord you can't even put some margin at the right of a paragraph (also called "indent", not sure which term is better for the right). The UI for it is there but disabled.

This is ,of course, Great!. Kudos to the Koffice team. BUT, IMHO if Kword doesnt have REALLY GOOD M$WORD import/export filters, it won't "Catch up", even if it is (and I do think it is) technically superior from other products..

A lot of distributions advertice their newest version with the "cool" KDE2 that includes a complete Office program. I don't thinkt that this is a good idea. Kword already can do a lot, but there is still a far way to go and I wouldn't do my daily work with it because it is not that stable as I would wish it. Don't get me wrong, I think it is(will be) a great application and I really have my respect from all these programmers that write this application, but I think that is not a good idea to call it "stable" yet.
I am very happy about these news, that means that the development goes on (when I took look on the homepage of kword it didn't make the impression to me that the development was still alive). Maybe someone can put news/informations about kword on the homepage?

No offense to the KWord people but KWord kinda sucks(it's beta-ish), why not just work on OpenOffice, not everything has to be written in Qt. OpenOffice has good MS inport, export filters, alot more features, and is more stable. OpenWriter has allready been seperated from OpenOffice. Not only that OpenOffice has alot more developers.

This is not some kind of troll post, please don't respond that I'm stupid, or go away troll. I'm really curious as to why not.

Sure, but they've been in development for a lot longer than KWord has. However, QT is good, GTK sucks, a lot. What will happen is that we'll get this boost, and maybe, perhaps, a developer will start actually coding KWord, and then we'll get ahead of OpenOffice, just like everything else that is QT.

Just like Noatun and XMMS! Charles, what's the future of Noatun anyway? Something I noticed the other day, I can't play all media types with on program. Noatun plays mp3 and all normal sound files but video is still a little bit off. This isn't a complaint but I wonder if the following will happen after KDE 2.1:

Avifile now has a beta arts plugin, will it get into kdemultimedia? Dispite this plugin noatun doesn't support .avi extentions. I guess that streaming support will also be added although it looks as if arts will need a bit of a redesign for streaming support and there are some threading issues with mpeglib.

IMHO these two features would mean that I never had to bother with XMMS again.. Noatun would handle every important media type out there currently, this is something that I would really like in KDE... A good Multimedia framework.

Charles (who posted the first in the thread), Simon and Martin who have done a lot of the kdemultimedia implimentation are some of the biggest stars of KDE and get very little press. These guys deserve a lot of credit and I'm sure we will be seeing a lot more info about kde's multimedia infrastructure after 2.1 as it's going to be a very big feature.

Noatun identifies a file by mime-type, then gets arts to create the proper type. But you see, mpeglib identifies Divx files with video/x-avi , while noatun/kde identifies it with video/x-msvideo. the latter being the correct one :) Fix your $KDEDIR's .mcopclass files. Same also goes with certain versions of mpeglib.

About anything making it into kdemultimedia. Not for 2.1, possibly for later versions. For KDE 2.2, we're planning many changes into the arts framework, which will make lots of very cool things happen, like multitrack files, and Video frame embedding, and most importantly, true streaming. However, Noatun already is 100% network-transparent.

That's correct, QT rules and GTK really looks amateurish. Just look at how inheritance is done in GTK, it makes me sick, to say the least. I think that the argument that GTK people use to justify why they use GTK instead of QT (that is, GTK is written in C, QT in C++ and there is no C++ compiler on every platform) is really obsolete.

This is a pretty lame argument. All you're saying s that "QT 7u13z!!" For example, QT's signal-slot mechanism is dated and could be done a lot better, IMHO. GTKMM does signals very well and is significantly faster than QT's signal/slot mechanism. This "design problem" as I put it can be seen from the fact that QT requires a pre-processor (moc) before cpp (the C-Pre Processor, not not mention c++) gets to it. Plus your "C++" widget code ends up looking something like this:

class MyWidget {
Q_OBJECT
proteced slots:
protected signals:
};

What are things like Q_OBJECT and the "keywords" 'protected slots' and 'protected signals' doing in there? Did Bjarne add some new features to C++ that I'm not aware of? If you want to talk about bad inheritance design, I suggest that you look first in your own back yard, otherwise you'll be forced to say that GOB is actually kind-of nice, since it accomplishes exactly the same kinds of things in a very similar manner...

On the whole, QT is *very* nice from an API standpoint, esp. when compared to say MFC or some parts of GTK+. But then again, so is Inti (C++ wrapper around GTK+ and Gnome) and it has the benefit of utilizing an outstanding signaling mechanism (GTKMM). GTK+ isn't that bad of a library. GTK2.0 is *very* nice and does some things that won't be available until at least QT3.0

First of all, it doesn't matter how fast gtk--
signals are. They are used in areas which are
not time-critical at all. Also, most of the
signals in a gtk-whatever program are emitted
in event handling, which _is_ time-critical,
and in this area Qt's virtual methods are much
faster.

As for the class declaration, it makes headers
very nice to read and self-documenting. Tools
like kdoc and doxygen can use these tags to
extract a nice class documentation. Where do
you look up the signal documentation in a gtk
program? In the source code.BTW, moc is _not_
a preprocessor.

And who cares about the things gtk 2.0 does when
it isn't released? You better look at what is
released, and find that gtk doesn't even support
Unicode, which Qt does for about 2 years now.

Gtk-- signals are more flexible than Qt's, that's true. That they are faster is, as it was already pointed out, unimportant because they are used to respond to user input.

However it's also true that Qt's "C++ extensions", regardless of whether Bjarne Stroustrup sanctified them or not, are more readable, easier to use, and good enough in 99% of the cases. And the remaining 1% is easy enough to work around.

In short : yes, moc is a less-than-ideal solution. No, that doesn't make Gtk-- or Inti easier to work with than Qt. Just look at their respective documentations for a start.

Another thing : as of today, Inti does NOT wrap Gnome, and does NOT uses Gtk--'s signal library (libsig++), but a very simplified version of it.

libsigc++' signals are not more flexible than Qt's, they are different. The system gtk+ uses is string-based, just like Qt's original implementation - and they know why.

A template based solution is very appealing for static applications (runtime type checking, speed), but Qt's solution is way more flexible. A GUI designer like Qt Designer that queries dynamically loaded components for signals and slots or a library that constructs GUIs including signals and slots connections from XML is simply not possible with a template based solution like libsigc++.

Some other features, like the available return type, may appear like flexibility, but all they indicate is bad design if you use them.

Another important factor is stability. What happens if you emit a signal to 5 receivers, and the receiver 4 is destroyed as a result of receiver 3 getting the signal. Can libsigc++ handle that without crashing? The situation is not as rare as it looks like, in fact, cross-dependencies like this happen a lot when using signals and slots extensivly. Those safety cost time.

If pure speed is what you were looking for (for example a network class that emits each single byte it receives), you may not want to use signals and slots in your Qt application. But why would you want to use a generic connection mechanism for this kind of task anyway if all classes know each other and there's only one single listener? You could simply use a standard C++ function call instead.

Last but not least: nothing prevents you from using libsigc++ with a Qt application if you want to.

>A template based solution is very appealing for static applications (runtime
>type checking, speed), but Qt's solution is way more flexible. A GUI designer
>like Qt Designer that queries dynamically loaded components for signals and
>slots or a library that constructs GUIs including signals and slots connections
>from XML is simply not possible with a template based solution like libsigc++.

How so? You can do dynamic slots with sigc++ as simply as will Qt. Simply
make a map from charactors to slots of some type. Then you can look up slots
by name. Just because it does static checking doesn't make it restricted
to purely compile time usage.

>What happens if you emit a signal to 5 receivers, and the receiver 4 is
>destroyed as a result of receiver 3 getting the signal. Can libsigc++ handle
>that without crashing? The situation is not as rare as it looks like, in fact,
>cross-dependencies like this happen a lot when using signals and slots
>extensivly. Those safety cost time.

Yes, it does that is its entire point. If an connection is broken the
system handles it cleanly by skipping the disconnected slot and then removing
it from the list later.

Here is a problem i've been noticing a lot on the dot: People complaining that so-and-so KDE app isn't as stable as it's GNOME counterpart, or doesn't have so-and-so feature that GNOME does, or whatever. This is great, because this is open source, and unlike some closed source companies (coughcoughmicro$hitcoughcoughaolcoughcough), such feature requests are valuble. Thus, they should be placed in bugs.kde.org (after checking to make sure they are not already there), where they will be more useful to the developers. Most developers are busy making KDE awesome to have time to read every dot comment, and bugs.kde.org allows the developers to easily organize bug reports and requests. Go OSS!

KOffice team never claimed that KOffice was anything more than Beta, in fact it wasn't long ago when the project was Apha-stage. QT is way better than GTK - that the simple reason.

Besides when KOffice is done it will be much more supperior than Open Office, the Koffice team aren't simple going to forfiet they project in faivour of Suns, the two group have defferent design goals, and different roadmaps - besides Linux is all about Choice!

I'm 100% behind KDE/Koffice, in fact, I'm learning QT so I can't contribute! As for import/export filters, Its not as easy as you might think, Open office has a difernt "toolkit" than Qt, so it will take time to get all the filters in. Another problem is see is that, some features that M$ Office supports are not yet implemented in K Office so, theres no real way of translating that data to the new program.

With that said, I belive the KOffice team will have KOffice good and ready soon enough, but as for now, its still Beta.

First of all OpenOffice dosen't use Gtk. All the responses I got were Gtk flames(It's not my favorite GUI lib, but it's one of the better ones). OpenOffice is written in very OO C++, as well as a little Java, you can write parts in almost any language though. OpenOffice does use Corba, as well as UNO, and XPCOM. This means any midleware midleware(it's not really slow) for those protocols that works for the KDE protocols will work. OpenOffice will probably never use Gtk, theres allready too much code. OpenOffice is really quite advanced, even if KWork had 15 developers, it would still take at least a year and a half to catch up to OpenWriter. During that time OpenOffice is being developed. OpenOffice also has a Windows port. This is very important considering that 95% of desktops use windows. This means that if OpenOffice ever get popular then switching people to Linux/UNIX is even esier. KOffice will probably never have a windows port. The only disadvantage to not using Qt, is that there are a more people that know Qt than the open office API though(allthough the APIs will be LGPL, and kept somewhat seprate), and that startup time will be a little slower.

Still, openoffice is a HUGE pile of code - and of over-engineering. KWord now has a very clean and solid basis, and it won't take a year and a half (as you say).

Windows ? Couldn't care less. The goal of KDE is to provide a free (and open) solution for Linux/BSD/Unix systems - so that people can get free from Windows, if they want to.

This sounds just like Konqueror vs Mozilla. Different goals (including target platforms), and different speed of development (did you notice how fast Konqueror became a first-class browser?). Sure, it doesn't work under Windows, but that's also why we didn't have to develop our own toolkit for it [like mozilla does].

In openoffice, it's everything that is redeveloped, from the toolkit to the component model and middleware. We already have all that working well with Qt/KDE, and that's why KOffice can evolve quickly on top of that.

I have nothing against those other 2 projects. I just point out that the goals are different, and hence so are the technical solutions, and the speed of development.

A year and a half? With David Faure working on it? Hahaha, it'll be ready next week. Even as I type the KDE scientists are doing experiments to try and clone Mr. Faure (& Waldo Bastian), if sucessful the completed Koffice will be released by the end of Feb and roled out to all Microsoft locations by the end of March.

When will we get to see this and the kde installer? When to the developers expect to have word support? I think that is also a major issue.
Will it be kde 2.2 sometime this summer? I'm really getting excited about linux and kde specificly. Good jod koffice developers!!!

Have you guys ever thought of implementing some of the cool features Apache.org is offering ? I'm thinking of Xalan / FOP in particular, i.e. taking the KOffice Files (which are XML-Formats, right?) and then transform them _directly_ to PDF. This works really good, even if the version of FOP is 0.16. Better than Ghostscript & PDFWriter, IMHO. Think about it.