Re: Multiplatform Support

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent
thread

Re: Multiplatform Support
by Robert Knight on Wednesday 20/Feb/2008, @15:59

> The goal of KOffice is to be a ligth-weight Office Suite that
> covers 90% of office use cases, which require between 10-20% of
> features from OOo and Ms Office.

That only works if those "90% of the people" all need the same "20% of the features." I suspect that assumption is faulty.

The other assumption there is that a "light-weight" office suite is valuable. On my four-year old laptop OpenOffice.org starts up in about 12 seconds from cold and about 3 seconds warm. Times for Microsoft Office were about 5 / 2 seconds respectively. Memory usage, running performance and UI complexity are all with acceptable ranges as well. Back when KOffice was started in 1999 I can see the logic of that. Beyond 2002 I'm not so sure.

If you're looking at low-end hardware (eg. OLPC) then low memory usage and good performance are important, but you're competing with AbiWord and Gnumeric which are pretty good established solutions.

Related Links

·   Articles on KDE Office Suite
·   Also by Robert Knight
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: Multiplatform Support
by Sebastian Sauer on Wednesday 20/Feb/2008, @21:10

> That only works if those "90% of the people" all need the same
> "20% of the features." I suspect that assumption is faulty.

It depends what this 20% are. Let's look at KWord for example. Each users needs the functionality to 1) load a document, 2) edit that document and 3) save that document. And there you have already the basic functionality each user needs :)

Now let's look how additional functionality is integrated, for example Variables like displaying the current date/time or like the scripting plugin. They are both done as plugins.

What you gain from this? A defined small(er) set of basic functionality that just needs to work 100% correct for anybody on the one hand and a very modular architecure on the other. Those does provide then;
* easy way to add or remove plugins without any recompile
* a clear API and separation for functionality
* it's not needed to know about all details to add new functionality
* things are more reusable, look at the Flake-architecture here as example
* it's easy to tailor an app to special needs like the kids-office, mobile devices or full-powered desktop's
* a more cleaner codebase
* etc.

Someone already did mention firefox and imho we could also look at amarok or even plasma here. Provide base functionality that is just needed in any use-case and go with plugins for more specialized additional functionality.

Well, that's at least my pov here :)

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"There are some gaps in my recollection of the past, I always assumed that was sleep." -- Rob Kaper
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.