Slashdot Mirror
KDE Readies KOffice 2.0 As OpenOffice Competitor
Da Massive writes in with a link to a story on KOffice 2.0, the next generation of the KDE office suite due sometime next year. In an interview with KDE spokesman Sebastian Kugler, Computerworld reports that KOffice 2.0 will be leaner, faster, and enjoy a cleaner code base than OpenOffice. It will also feature more applications, including an Access-like database creator, a flowcharter, and an image manipulation tool. KOffice is not yet fully compatible with ODF but the claim is that 2.0 will be.
RTFA:
KDE 4's framework is cross-platform.
They plan to release this on Windows as well.
"Giving money and power to government is like giving whiskey and car keys to teenage boys" P. J. O'Rourke
The main benefit KOffice 2.0 brings is that it's sleek and fast. Unlike OpenOffice.org, KOffice has a very sensible architecture. Now, part of that is because KOffice is a far newer application. It builds directly on top of Qt, rather than implementing its own UI layer (like OpenOffice.org does). It also has a far more sensible component model, that suffers from only a small fraction of the bloat of the OO.o model.
While OpenOffice.org may have a larger feature set at this point, it just won't be able to compete with KOffice when it comes to being responsive and memory-efficient. Having built the KOffice source code from SVN just last week, I can tell you that you'll notice the difference immediately. OpenOffice.org just feels really damn sluggish, while KOffice is quick.
The point of the "open source" movement is to improve the way software is developed by opening it up and distributing it.
The point of the "free software" movement is to ensure that software is freely redistributable, and modifiable by the users of the software.
As for this "choice" thing you're talking about. That's the function of the market isn't it? Wouldn't just proprietary software give people "choice"?
How we know is more important than what we know.
You know if you took a few seconds to research something you're writing - or even speaking - about, it may help others think you're not such a dumbass. You might even up your intelligence. Alas, this is slashdot. The barrier of entry for intelligence here is so low, you don't even need to remember your username to post.
Here, check this out:
http://en.wikipedia.org/wiki/Qt_(toolkit)
(That's a link, you can click it and it will take you to another place on the internet). As you can see, QT4 is ported to Windows, and other non-x11 OSs. In an amazing twist of coincidences, Koffice is written in QT4.
As for this "choice" thing you're talking about. That's the function of the market isn't it? Wouldn't just proprietary software give people "choice"?
If open source didn't give people more choices, would there really be any point to it?
This is my sig.
OfficeSweet.
-Docvert converts MSWord to OpenDocument, clean HTML
Why no love of Kerberos!
Especially since it already starts with a "K"!
At least you have been spared the pain of trying to bring credibility in marketing to The Gimp.
KOffice 2.0 will run natively on OS X:
:D ), and iWork 2008 out starting last month, Mac users willing to pay for a good office suite will have even more choice.
http://apple.slashdot.org/article.pl?sid=04/01/02/1930232
This will benefit Mac users tremendously, as NeoOffice is too bloated (although making good progress at getting more efficient) and the native version of OpenOffice is probably several months away at best.
There is no lean, simple free and/or open source spreadsheet app for Mac yet. When KOffice 2.0 comes out, cheap Mac users (like me) will have more choice. When MS Office 2007 comes out for Mac in January 2008 (sorry, had to poke fun at Microsoft
This will also benefit the KDE team, as their installed based will expand by one (and possibly two) OS's, giving them more bug reports and feature requests.
Everybody wins!
This space left intentionally blank.
I've been working on my own Access-killer for a couple of years now. It's a suite of open-source, cross-platform Perl libraries, using Gtk2 for the GUI. The old website ( complete ) is at: http://entropy.homelinux.org/axis/. I'm right now working on a revamped website ( incomplete, but with up-to-date download links and new screenshots ) is at: http://entropy.homelinux.org/axis_new/.
... :)
There are 3 main components: a form object, a datasheet object, and a reporting module ( which exports to PDF via PDF::API2 ). I'm also working on a GUI object builder that exports XML for all 3 objects. Click on the 'future' link to see some screenshots of it in action. Note that I'm also looking for developers to help out, and maybe create a commercial project out of it ( I'm as-yet undecided whether to do this or not ).
I've had a number of large, complex production systems built on these libraries in use for about 2 years now. Please try it out, comment, report bugs, help out
While I can't speak volumes about Gnome and GTK. I can say that you views of KDE and QT do not appear to be based on facts, but more assumptions and preconceived notions.
:(
KDE is NOT simply QT plus bloat, the goals of the KDE library are to provide a consistent API to applications to work well with the KDE desktop. In the grand scheme of things it is actually very light as far as things it adds to QTs very complete API. For example, it will provide a KPushButton which inherits from the QPushButton class to add a few small integration features. Also KDE offers many common widget combinations as a reusable widget in itself, this is good library design as a whole. Making libraries of reusable code is a GOOD THING.
Don't mis-interpret this as KDE zealotry, I imagine that Gnome provides some sort of API to help applications integrate well with the desktop as well.
And what is your general issue with using c++ and moc? I hate to break it to you, but moc IS "real c++". There is nothing wrong with having utilities to generate code, there is huge gain to doing it with moc instead of templates...runtime bindings. moc just hides these details for you, and to be honest, you usually don't even have to worry about it at all if you use the QT build system.
As for what is wrong with GTK + C? Well nothing is wrong with it but it's not the only choice. One thing to keep in mind though is that graphical displays usually consist of conceptual objects "windows", "buttons", "listboxes", "textboxes", etc. These are all "things" which to be honest, creating code to describe "things" is what object oriented programming excels at.
You will never see a port to GTK of KOffice because it would not be a port, but a litteral re-write as the whole code base is built around the KDE/QT libraries.
And why not start with AbiWord? Heh, this statement is a shinning example of a preference not based on the merits of what you want, but instead on an arbitrary dislike for the competition. You are of course entitled to your opinion, nothing is perfect. But you provide no real reason why something built on KDE libraries is inherently bad. Secondly, Abiword is a single word processor application with no integration into an "office solution". KOffice is looking to provide the whole shebang.
I imagine you are going to reply with "KDE is bloated", "KDE is slow". But these generalizations aren't really based on real facts. KDE is actually quite lean (and KDE 4.0 is going to be leaner because QT 4.0 is a vast improvement of 3.0). Its memory usage is nothing crazy, the reason for this is that there is a LOT of code reuse. Using the KDE libraries is effectively "free" as far as memory usage goes because modern operating systems do code sharing of dynamic libraries and the whole damn desktop uses these libraries! There are benchmarks that show that Gnome and KDE are actually quite comparable: http://ktown.kde.org/~seli/memory/desktop_benchmark.html
I'll even not go so far as to say KDE is better than Gnome in memory usage because I know that there are many factors and a single set of benchmarks by one person doesn't really prove much...but it does show that they are at least in the same ballpark.
All in all, I find your argument against using a modern library not founded in facts
proxy
In 2009, I will ship my office suite, Stork Office. It will be fully open source, be even leaner than koffice, and not have the stupid Access-like tools. Then, if KDE isn't finished their 4.0 desktop, and fix the register view in KDevelop, I may just write my own GUI and IDE to go with it, for release in 2009. Oh, and I'll have Duke Nukem Forever as a game that ships with my system!
This is my sig.
And just to expand on that, there are really several different things going on:
:D.
1) Qt 4, the underlying system library is now dual licensed GPL/commercial on the Windows platform by Trolltech, before only commercial on Windows.
2) As a result, the kdelibs (the core KDE libraries) for KDE4 has been made cross-platform. Like KDE4, they're still unreleased (at beta 2 still I think) but I did manage to get a KApplication compiled and running on Windows.
3) Since the KDE libraries are going cross-platform, so is all KDE applications that doesn't have additional *nix-specific dependencies. Note that KDE is trying to be a complete application framework not just an UI library, so this should be true for most.
4) Since the move from KDE3 to KDE4 is major, most applications like KOffice are also doing major rewrites not only because of the framework changes but also "if you want to change and break something, now's the time".
End result? Well it's always though to say with unreleased software but the general idea is that it'll be a three-pronged attack:
1. It's now cross-platform, so new markets
2. All applications should see a 20-30% speed improvement because of library improvements
3. Major new version with new features
Only downside is that it's taking quite long - Qt 4.0 was released in June 2005, though in personal experience it was a poor release but none the less it's taken a few years and KDE4 is still in development. The release of KDE4 is scheduled for December 11th, and I'm very much looking forward to it. It should bring the Gnome vs KDE flamefest to new heights
Live today, because you never know what tomorrow brings
I actually knew someone who definitely needed "print selection". He had never heard of the concept of files, much less folders. He had ONE Word document on his Mac desktop, and only ever typed into that. Then he would select the part he needed and print that. I'm not kidding! Luckily, I was in a hurry and was able to refrain from getting into helping him. Anyway, he didn't want or need help. I have no idea how it ended, and whether eventually someone showed him the light. But maybe he wouldn't have been interested. It worked for him, with all his writings in a single huge Word file...
A lot of those packages are simply the individual applications and their supporting data. Once you ignore those, the required supporting packages are simply:
The rest of the packages are optional. Furthermore, if you only want a couple of the applications, e.g. KWord, you can install them individually. And of course, on a KDE desktop, you'll already have much of this installed anyway. Considering the size of things like OpenOffice and Microsoft Office, I'd say that's not too bad.
Bogtha Bogtha Bogtha
Blame your distribution. They are optional. Whoever packaged it for your distribution decided that they should be required. I have KOffice installed, and I haven't got all of those packages installed.
Bogtha Bogtha Bogtha
surely, in fact, the linux kernel uses object oriented programming in things like the VFS layer. The thing is, doing OOP in C is no more efficient than C++, it really is just a matter of syntax. And if you have a language which gives you OOP and is generally efficient..then why not use it.
It's just another tool in the toolbox, i like using many languages and it's just a matter of choosing the right tool for the job.
Converting a PDF document into an editable form is like taking a screenshot of slashdot and trying to reconstruct what the HTML and CSS was.
Postscript, the precurser to PDF, is basically a layout system; draw a string here, draw a string there, etc. It is very good at preserving layout. However, some information is lost. Consider an embedded table, for instance. In the original document, a table might be defined with
-table
-row
-Firstname
-Lastname
-row
Jack
Bauer
-row
Anonymous
Coward
-endtable
Once converted to pdf, it might be represented by
Drawline(200,200,400,200)
Drawline(200,300,400,300)
Drawline(200,400,400,400)
Drawline(200,500,400,500)
Drawline(200,200,200,400)
Drawline(300,200,300,400)
Drawline(400,200,400,400)
PaintString("Firstname", 200,400)
PaintString("Lastname", 300,400)
PaintString("Jack", 200, 300)
PaintString("Bauer", 300, 300)
PaintString("Anonymous", 200, 200)
PaintString("Coward", 300, 200)
Just what is it that slashdotters find so interesting about medium sized stringed instruments?
Cogito, ergo sig.