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
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
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.
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
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.
http://ranger.users.finkproject.org/kde/index.php/Home
viola
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
$pdf2ps document.pdf
(Part of ghostscript.)
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
That's Karbon, which has seen awesome improvement for 2.0.
Boudewijn Rempt, KOffice Release Dude
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)
... and in the times of StarOffice 5 it even came with a GUI that looked like a separate desktop.
Perl's a natural fit for people who already know BASIC -- lots of $ all over, doesn't enforce any particular programming style, not particularly object oriented, etc.
If moderation could change anything, it would be illegal.
These projects are all odf converters, mostly MS Office plugins. They do not make it possible to open OOXML in anything other than MS Office.
Loading...