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

List:       koffice-devel
Subject:    Re: KOffice potential, a call for developers
From:       Raphael Langerhorst <raphael-langerhorst () gmx ! at>
Date:       2005-01-09 13:21:39
Message-ID: 200501091421.39547.raphael-langerhorst () gmx ! at
[Download RAW message or body]

On Sunday 09 January 2005 10:56, Thomas Zander wrote:
> 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.

ok, that's good. As I said, startup time is not everything and in 
general OOo works fast once its up and running.

>
> > 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.

Does anyone know if Qt 4 brings any improvements regarding postscript?

> 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.

Yes... that's actually the issue. (see also below) You have probably 
even a much better understanding of what's (still) 
wrong/unfinished/unstable all around the place.

>
> Ok, this turned out a bit more sour then I wanted.

I can understand that, Nicolas seems to be somewhat sad about the 
situation as well (just as me, too).

> 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.

Since KOffice was started before OpenOffice.org was open sourced a 
major development factor was surely that now complete office suite 
was available. Now that OOo is out there a question that arises (you 
probably discussed that in length before I came in) is if KOffice is 
still needed. And I also think these issues should not be surpressed. 
Nevertheless it is also important that IF it is decided to carry on, 
then there should also be a clear view of what the project is 
targeting at.


Currently there are - just as you say - many many features around, and 
even new components being added. New features are of course very 
welcome, especially if they make the office suite more complete. But 
the contributors for existing components should more concentrate on 
keeping/making the component stable before adding new features (ok, 
we have quite exceptional situations, also because of the OASIS spec 
and what not). The other thing is, that for example the Krita devs 
probably wouldn't like to do bug fixing for ... say ... KSpread but 
want to work on their graphics app. So it's difficult to move 
developers between components if they prefer one of them. This leads 
probably to the problem of having too few developers. Still, if the 
problem of having too few devs is there then I think it's also 
important to get a clear view on what should be done and just going 
for the most important issues and trying to coordinate improvements 
rather than letting people venture themselves around KOffice and 
letting them do what they prefer (I shouldn't build complicated 
sentences). Ok, this might be a bit in contrast to the open source 
model, but maybe only on the first view. In a project the most 
important aspect is the project itself and what the "project" as such 
wants to reach. Then devs should work towards that goal, of course 
with the freedom of choice - so the goals need to be on an abstracted 
level (like a feature set, or simply quality assurance of specific 
components - say, printing for example). This needs of course be 
prioritized... probably I'm getting a bit ahead of myself.

But I think getting organized, and especially setting priorities is an 
important aspect when not enough manpower is available. I probably 
can't judge that all that much, still, I think we could or even 
should get clear of what we want, maybe listing these things 
somewhere (wiki?), giving priorities and walk through these things 
accordingly. As the situation currently is, this would probably mean 
1-2 person / task, but that's ok. Also we should probably take the 
bugs into account, take a look at what is in a worst state and decide 
if this even should be fixed (for example if it takes much time but 
has little effect on overall stability)...... [I'm stopping here, 
cause I'm repeating myself and the email gets too long, post your 
thoughts/critics/suggestions on this if you have some/any]

Best Regards,
-- 
Raphael Langerhorst, JID: raphael@jabber.pilgerer.de
G System, The Evolving Universe - http://www.g-system.at
_______________________________________________
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]