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

List:       koffice-devel
Subject:    Re: OASIS file format for Krita
From:       dirk.schoenberger () sz-online ! de
Date:       2004-03-24 9:24:05
Message-ID: 59108.212.185.245.126.1080120245.squirrel () webmail ! sz-online ! de
[Download RAW message or body]

>> Thomas Zander wrote:
>> >>Perhaps more of KOffice base libs can be put into the core libs? So
>> >>that
>> >>standalone applications can be built usind KOffice technology, without
>> >>actually be KOffice components?
>> >
>> >
>> > You can't have one without having the other, so what's the point?
>> > Naming?
>>
>> The point is what shipped with the suite.
> The KDE project does not decide what is shipped with what; for example the
> debian packagers ship each application separate; its easy to install kword
> without kpresenter if you want.
> So this is something you have to take up with the individual packagers, at
> best KDE can write a packager-guidelines file for koffice.

Perhaps the application could be shipped, but not shown in the component
chooser of KOffice.
So basically Krita would be a standalone application, just no KOffice
component (as in loadable module?)

>
>> It is perfectly OK to have
>> additional applications based on KOffice libraries.  But, Krita (and
>> probably Karbon14 as well) are becoming large artist's applications
>> which
>> are not what the average office suite user needs.  No complaints at all
>> about the existence of these applications.  My point is that the suite
>> needs to ship with a simpler graphics application that can do simple
>> stuff
>> for DTP and presentation slides.  That is: Artist != Office-Suite-User.
>> Office-Suite-Users do not need DSP (convolution) based water color
>> painting
>> simulation -- it is nice but not needed by this class of user.
>
> Ok; that might be a reasonable assumption; but I fail to see why we should
> dumb-down the office-suite because users won't use features; we just have
> to make sure that the simple things stay simple usability-wise. What
> concerns me more is that the simple things should be possible in the first
> place. With this I mean that we should not make the mistake that artsd
> made; create a really nice app that does lots of thins quite-ok, but fails
> to do the thing most users use it for really well.
>

Or have some more mix and match, ie. components for

- text editor - simple, advanced
- image editor - simple, advanced
- vector editor - simple, advanced?

Regards
Dirk
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]