[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KOffice potential, a call for developers
From:       Thomas Zander <zander () kde ! org>
Date:       2005-01-09 9:56:48
Message-ID: 200501091056.52223.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 08 January 2005 18:04, Raphael Langerhorst wrote:
> > On a different note; your post does not give me any reason to
> > believe you on the potential KOffice has, and what I could add to
> > it.  But writing something is better then nothing, I guess.
>
> Maybe some personal description here (it's difficult to write that in
> an article):
[snip parag 1]
> ... ok, just tested startup time (after a fresh boot) of OOo Writer
> 1.1.3 on FreeBSD 5.3 on my Athlon 1 GHz machine: 20 seconds.
Its said that the 2.0 (beta?) version of OOo is MUCH faster in this respect.

> The content of paragraph 1 shows already that KOffice has huge
> capabilities and potential, without the need to implement all this in
> the KOffice sourcecode itself(!), with _ALL_ consequences on
> performance, managability, integration, etc.. This is an advantage no
> other office suite will ever have on KDE.

KOffice is the first suite that brought OLE-type embedding to the next level 
with inline editing in a full version of the target application.
Unfortunately embedding printing and moving from top/left is still broken.

Koffices authors have first put a lot of attention to get the basis right. 
The ability to work in all languages, so opening arabic/chinese/etc 
languages in documents will work flawlessly, but also having the UI in 
those languages to having the files you created called names in chinese is 
no problem in KOffice.
These basic capabilities are shared with KDE allowing allt the work in KDE 
to be immidiately available in KOffice.

Now if only Qt would someday get a mature Postscript generator and font 
management we could actually print all that pretty stuff we create in 
KOffice.
KPresenter itself is a project that could make an end-thesis for a usability 
expert with all the expected-but-not-present usabiltiy features.
KWord had been extended with a set of features that are all unfinished, 
unstable and just make the application feel worse.  And nobody seems to 
care to finish their features before putting them in the application. For 
the life of me I can't understand why the 'type anywhere cursor' is still 
part of the applcation.
The koffice libs and the kword libs at least need a refactoring to make all 
the objects less fat (less members) and more delayed initialisation to make 
it possible to instantiate an object without linking in the whole of 
kdelibs.  This is desperately needed to be able to build unit tests which 
are the only way to allow stability accross the platform when new patches 
come in which potentially break functionality of an author that is not part 
of the project anymore.

Ok, this turned out a bit more sour then I wanted. I just don't feel that 
asking for more developers are going to solve any of the problems since the 
learning curve is still way to high.
-- 
Thomas Zander

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]