Slashdot Log In
KDE Readies KOffice 2.0 As OpenOffice Competitor
Posted by
kdawson
on Tue Oct 09, 2007 06:52 PM
from the another-country-heard-from dept.
from the another-country-heard-from dept.
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.
Related Stories
[+]
Review of KOffice 2.0 Alpha 8 – On Windows 162 comments
4WebChimps writes "As featured previously on Slashdot, the KOffice project is working towards a cross-platform, open source office suite for Linux, Windows and Mac OS X. The most recent release, KOffice 2.0 Alpha 8, achieved that goal by being the first release for all three operating systems simultaneously. Want to try KOffice on Windows? TechWorld has a review (with screenshots) of KOffice on Windows, including the installation process which is as simple as clicking a few buttons (the online installer does the rest). Hopefully it won't be long before KOffice sits alongside OpenOffice.org as a usable cross-platform open source productivity suite."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
KOffice 2.0 is FAST! (Score:5, Interesting)
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.
Re:KOffice 2.0 is FAST! (Score:4, Insightful)
I can certainly say the formula editor is miles ahead of oo.org's in terms of ease of use. I get a font error right away though in starting the formula editor, so I guess I'm off to file a bug report.
Parent
Re: (Score:3, Interesting)
It has been my office app of choice since then.
Re:KOffice 2.0 is FAST! (Score:4, Insightful)
In the end, I guess it is fast for KDE users; people using other desktop environments will see no difference.
[Just guessing here, from my experience with older KOffice parts running inside GNOME. Yes, they run and will still run.]
Parent
Re:KOffice 2.0 is FAST! (Score:4, Insightful)
Parent
Re:KOffice 2.0 is FAST! (Score:5, Interesting)
Parent
Re: (Score:3, Informative)
(Part of ghostscript.)
PDF to ODF conversion (Score:4, Informative)
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)
Parent
Go for the gold (Score:5, Funny)
freedom not numbers (Score:2)
Re:freedom not numbers (Score:5, Insightful)
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"?
Parent
Uh...he's right (Score:3, Insightful)
If open source didn't give people more choices, would there really be any point to it?
i hope the database app delivers (Score:3, Informative)
the rest of the office implemenation seemed to almost work. of course, it wasn't completely compatible with OO, but i liked the interface better and would have used it if it had a useful PDF output. However the PDF i got out of it was really jagged (the letters jumping up and down around the line), and the opinion on the mailing list was at the time 'it isn't our problem', so I switched back to OO in the end.
I hope 2.0 delivers. I'll give it a try anyway
Please try my database libraries / app (Score:4, Interesting)
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
Parent
Re:Please try my database libraries / app (Score:4, Funny)
I think you are a little late to the party. Didn't Access commit suicide like 5 years ago?
Parent
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
WTF dude? This is the 2nd post that's complained about my attitude to OO languages, whereas I said nothing of the sort. I said that Pyth
I, for one, welcome more ODF-based office suites (Score:3)
My fallback -- and I'd just like to take this opportunity to veer off-topic, here -- is to put Ubuntu on a used CPU and run LTSP, with the Macs as thick clients. One way or another, I can't stand to see my office sink any more money into proprietary software.
That's all good. Except... (Score:2)
And while you are at it, please work on the print selection thingy sometime eh?
Re:That's all good. Except... (Score:5, Funny)
Parent
Slightly off topic, but related, Kontact (Score:3, Interesting)
Why no love of Kerberos!
Re:Slightly off topic, but related, Kontact (Score:4, Funny)
Why no love of Kerberos!
Especially since it already starts with a "K"!
Parent
Native Mac Version (Score:4, Informative)
http://apple.slashdot.org/article.pl?sid=04/01/02/1930232 [slashdot.org]
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!
My office will be even -better-. (Score:5, Funny)
Can it open OOXML files? (Score:3, Insightful)
Re: (Score:3, Informative)
Re:"Competitor" my ass... (Score:4, Informative)
KDE 4's framework is cross-platform.
They plan to release this on Windows as well.
Parent
Re: (Score:2)
Re:"Competitor" my ass... (Score:5, Informative)
Parent
Re:"Competitor" my ass... (Score:5, Informative)
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
Parent
Re: (Score:2)
Re:It doesnt compete with anything (Score:5, Funny)
Here, check this out:
http://en.wikipedia.org/wiki/Qt_(toolkit) [wikipedia.org]
(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.
Parent
Re:It doesnt compete with anything (Score:4, Funny)
Just what is it that slashdotters find so interesting about medium sized stringed instruments?
Parent
Re: (Score:3, Funny)
Cello!
Re: (Score:2, Insightful)
Re:why don't they think of a catchy name (Score:5, Funny)
At least you have been spared the pain of trying to bring credibility in marketing to The Gimp.
Parent
Re:Why don't we think of a catchy name? (Score:5, Funny)
Parent
Re: (Score:3, Insightful)
sudo apt-get install koffice
Password:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
karbon kchart kdelibs-data kdelibs4c2a kexi kformula kivio kivio-data
koffice-data koffice-libs koshell kplato kpresenter kpresenter-data krita
krita-data kspread kthesaurus kugar kword kword-data libarts1c2a
libavahi-qt3-1 libopenexr2c2a libpoppler1 libpoppler1-gli
Re:GNOME or other wms (Score:5, Informative)
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.
Parent
Re:GNOME or other wms (Score:4, Informative)
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.
Parent
Re: (Score:3, Interesting)
Hard drive space is cheap.
Re: (Score:3, Insightful)
Qt3 was available with a GPL license only for X11, so the previous effort to port KDE to windows had to reimplement a GPL version of Qt for win32 from scratch, which is quite a big undertaking.
Qt4 is available under the GPL for every platform, so that big roadblock is cleared. And the KDE project is officially supporting and ecouraging the win32 port this time.
Also, some other things like KDE switching to a much nicer and cross platform build system than a
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Access (Score:3, Informative)
I cannot quite understand how you cannot see what Access is used for. When you need a databse application with a GUI, what do you build the GUI with? HTML? That's fine for many tings, as the web demonstrates. But for a real desktop GUI application, what do you suggest instead of Access? Perl/Tk? C++? Visual Basic?
Des
Re: (Score:3, Informative)
http://entropy.homelinux.org/ [homelinux.org]. I'm also working on a new website ( with updated screenshots and also snapshots of the libraries ), at: http://entropy.homelinux.org/axis_new [homelinux.org].
It's written in Perl, and uses Gtk2 for the GUI. It's open-source and cross-platform, and soon will get a GUI object builder ( click the 'future' link for some screenshots ).
Re: (Score:3, Interesting)
Anyways, I have a question. I can't think of a single good reason to use Access (or Access-like databases). Can somebody tell me what sort of applications would actually call for a wretchedly limited application like that?
Access *is* truly wretched as far as an actual DB backend. The early versions of MySQL were far more powerful and fast, for example. But the real killer feature of Access is the ability to create tables and interfaces to them graphically. It's actually very good at that, and I haven't seen a decent replacement for Linux. A non-technical person can sit down with Access and make, say, a database of their recipes, or book collection, or company purchase orders... and make a decent GUI to do CRUD on it.
For
Re:Would rather it be GTK or Qt based. (Score:5, Informative)
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 [kde.org]
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
Parent
Re:Would rather it be GTK or Qt based. (Score:4, Insightful)
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.
Parent
Re: (Score:3, Informative)
That would be Karbon14 [koffice.org]. (KDE seems to have gone through a few iterations of vector graphic tools, or maybe the same tool under different names. I know KIllustrator was renamed because of pressure from Adobe, to Kontour. And there was a Krayon in there too. I don't know how many of these may actually have been different codebases.)