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.
i tried 1.6 some time ago -- mostly because i needed something access-like on Linux. the database app on the surface looks a lot better than the horror the ooo thingy, except that it didn't work with pre-existing sql databases. one has to create a database from scratch, and there wasn't an easy (UI) way to even hookup an existing database after one creates a custom one. since my needs were really simple, i gave up, and instead used knoda (http://www.knoda.org/) which is similar, and works nicely for the kind of thing I needed.
:)
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
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.
I'm a Gnome user (after road-testing KDE for a good six months), but I've been infected with the hype about KDE 4, and in particular, Koffice. If it's really as good as they say, there's a good chance I'll switch over. My job uses Macs, and I've found NeoOffice too unstable to use (four crashes in two hours). Supposedly, there will be a Mac OS X-native version of Koffice, which would fit the bill to replace friggin' MS Office.
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.
What if I do the same thing, and I do get different results?
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.
Why is it that Kontact does not have KOffice integration and Kerberos support. Kontact+eGroupware would be an Exchange Killer IF Kontact and eGroupware supported Kerberos so that I don't have to setup kwallet with Domain login and passwords for remote Calendars/Tasks/Address Book with XML-RPC.
Why no love of Kerberos!
Because once they realized they'd need a name MORE CLEVER than "Microsoft Office" and "Open Office dot Org", they threw in the towel. Seriously, it's an office suite. Its name doesn't need to elicit feelings of euphoria or anything.
oo
OfficeSweet.
-Docvert converts MSWord to OpenDocument, clean HTML
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
You're not kidding:
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-glib libpoppler1-qt
libruby1.8 libwv2-1c2
Suggested packages:
khelpcenter koffice-doc-html fam koffice-i18n koffice-dev koffice-doc
wordnet tetex-extra
Recommended packages:
perl-suid openoffice.org-mimelnk kghostview latex-xft-fonts ruby libkscan1
libarts1-akode
The following NEW packages will be installed:
karbon kchart kdelibs-data kdelibs4c2a kexi kformula kivio kivio-data
koffice koffice-data koffice-libs koshell kplato kpresenter kpresenter-data
krita krita-data kspread kthesaurus kugar kword kword-data libarts1c2a
libavahi-qt3-1 libopenexr2c2a libpoppler1-qt libruby1.8 libwv2-1c2
The following packages will be upgraded:
libpoppler1 libpoppler1-glib
2 upgraded, 28 newly installed, 0 to remove and 112 not upgraded.
Need to get 76.7MB of archives.
After unpacking 187MB of additional disk space will be used.
Do you want to continue [Y/n]? n
Abort.
How we know is more important than what we know.
15 seconds? My 4 year old laptop running gusty can get a cold start on OOo in about 5 seconds. Subsequent startups take about 2-3 seconds. Of course this is still an eternity compared to the near-instant starts of MS Office though.
The link you pointed to shows Pixel is proprietary... I imagine this might be a problem for its inclusion into KOffice (which already includes the much-loved Krita)
Kexi is already the Access-like db-app, and I believe they already use Kivio for their flowcharting app. Correct me if I'm wrong, but I just wanted to point out that they (the KOffice folk) aren't building their own KOffice apps when other KDE apps already exist.
Bill
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 use access all the time when people send me CSV files that have more than 65,000 rows in them, and therefore won't open in most spreadsheets. It's nice for one-time-use databases or just doing simple queries on csv files that clients have sent you. I wouldn't use it for any kind of permanent database, but that's usually how access applications get started, Somebody needs a quick and dirty database to use for a week to analyze some data, and 3 years later, it's still running, because somebody thought it would be easier to keep on using access than to upgrade to a real database.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
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?
Despite it's horrible VBA scripting, Access is a great tool to build GUI frontend applications. In fact, I think Access is the main reason why many people cannot move from Windows to Mac or Linux. They have a vital Access application, and there is no easy way to replace it. I have several clients with such applications. In some instances, I moved the data to PostgreSQL on a Linux server, but the forms are still in Access.
I'm very much looking forward to an Access alternative.
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
I don't care what bells and whistles are added, what shiny new GUI paint is applied, how much faster the app runs, etc, etc, etc. Office 2007 is on the street, and we are going to be hit with a barrage of OOXML files that can't be opened by anybody who's not running Microsoft. Any contender in this space needs to address this problem, and right now.
Loading...
For example, a few years ago my ex-girlfriend had to make a large database of English loanwords used in China for her undergrad thesis. I tried to get her to use MySQL, but the lack of any GUI at the time was a turnoff. She used MS Access successfully instead.
I hear that Kexi (KDE-based) is a very nice and rapidly improving Access replacement, but haven't tried it. Nothing like it for GNOME, AFAIK.
My bicyles
> 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.
...
My views are based on my experience with KDE.
I was a KDE and supporter from the start.
I switched to XFCE. I have tried GNOME, but it's not for me currently.
> 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.
> 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.
It's one thing to provide extra functionality possibly missing from the toolkit underneath.
It is quite another if the library ties the application to a specific desktop and ties to other random daemons.
Example: run konsole in non-kde, and it launches random things like the arts sound daemon.
I would not expect that a Qt Console would launch a sound daemon. I don't think kdelib has any constrained purpose. (except the vague purpose you stated: "to work well with the KDE desktop").
My problem with KDE was that there was no clear boundaries for dependencies.
The daemons that are not desktop specific, should not be part of the desktop. Sound daemons, printer daemons, and other daemons should be independent of the desktop.
No, the dependency problem is not unique to KDE, but KDE"s kitchen sink packages, like kdebase do not help my impression of it.
I am in favor of separate packages for individual apps and libs. The kitchen sink approach masks dependency problems.
I use XFCE because it is simple and functionally complete for me. The bonus side effect of using XFCE is that it is not easy or natural to use apps that have funky dependencies on gnome or kde.
Perhaps KDE4 has fixed some of the dependency problems. If I can install konsole without installing or launching the kitchen sink, then I will look at it again.
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.
What about a Vector graphic editing tool?
That would be Karbon14. (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.)
-- Alastair
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)
That list of deps (installing Koffice on a Gnome based system) is about the same size as installing only Gnumeric (which is largely Gnome based) on a simple KDE based system.
Hard drive space is cheap.
The difference lies in the Qt4 licensing versus Qt3.
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 autoconf/automake (cmake) probably helps a lot too.
The reason a port is useful is because there are some very good applications in KDE that really deserve more exposure. And I suspect there are quite a few people like me who have to use windows at work and are frustrated to be unable to use some of those nice KDE apps at work.
Just what is it that slashdotters find so interesting about medium sized stringed instruments?
Cogito, ergo sig.
I propose we adopt a new standard. Viola is getting old.
Cello!
If moderation could change anything, it would be illegal.