[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-22 10:57:20
Message-ID: 57998.217.80.144.23.1079953040.squirrel () webmail ! sz-online ! de
[Download RAW message or body]

> On Monday 22 March 2004 11:12, dirk.schoenberger@sz-online.de wrote:
>
> I am getting really, really, really tired of this perennial discussion.
> It's
> always the same. James Richard Tyrer chips in saying he'd like to have
> vectors in Krita because he cannot work with pixels,  and besides, if
Krita isn't > going to conform to his wishes it has no business being in
KOffice.

I understand James view, but I don't quite agree with him.

> Then you tag along to tell us that you want an app that binds together
> Karbon
> and Krita in some framework -- I'm surprised you haven't mentioned your
> QPainter-like thing yet -- and besides, Krita has no business being in
> KOffice since it's too complicated and not what you need anyway.

Perhaps there is a misunderstanding.  I (an James, I think)  would like to
see a
more "componentized" KOffice application with more shared functionality,
i.e. at least vector and image editing, hopefully also thinks like page
layout.

What I see currently is a collection of standalone applications which
basically share the same storage API and a shared import/export filter
architecture (did I miss something important?)
I cannot really see the applications as "components" in a bigger framework.

>
> I've heard it all, but I haven't seen the patches yet. So, blow by blow,
> here's what I think of this hoary old discussion:
>
> * If there's consensus among the other KOffice developers that Krita has
> no business being in a future KOffice release, I'll be happy to move to
> kdegraphics. It'll still be a KOffice app, because we use KOffice libs.

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?
This e.g. include things like a proper model-view-controller (or rather
view-model-tool) design, which was basically introduced in KOffice (I have
seen it in Karbon), but what was copied to be used outside of KOffice in
KolourPaint.

>
> * If someone codes up a patch for Krita and Karbon to share code whereever
> practicable, to unify the render interfaces (KisRenderInterface) so both
> apps can share layers, then, if it looks like it works, I'll be happy to
see
> that done and commited.

I cannot speak about Krita, because I don't really understand its design
decisions.
In my own application (not yet released, propbaly never) I was going to
use pure QImages as the things to render.

> * Krita will have to find its own niche on the X11 desktop. The Gimp has
> sewn up the web images (and is being financed to progress to high-bit-depth
> images),
.....
> I would like to have at least one graphics app based on Qt to become the
> number one in its niche. The only niche left is coincidentally also the
> one I'm interested in, and that's the painter-type app.

What I don't understood is about how you separate your application against
the GIMP? I like the last developments in the Krita GUI, and I can't stand
the GIMP GUI, but what are the intended internal differences?

> Sodipodi/Inkscape show promise to become the vector apps of
> choice.

What's really unfortunate, because this "best of breed" application
doesn't work in any component system. At least to me a standalon vector
graphics application is not of much use.

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]