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

List:       koffice-devel
Subject:    Re: Krita features
From:       dirk.schoenberger () sz-online ! de
Date:       2004-01-14 14:08:56
Message-ID: 57353.212.185.245.5.1074089336.squirrel () mail ! sz-online ! de
[Download RAW message or body]

> On Wed, 14 Jan 2004 dirk.schoenberger@sz-online.de wrote:
>
>> What about KPainter then? (kdenonbeta/kapinter)
>> More complex rendering model, but unfortunately rather neglected in the
>> last time due to being not used in applications ;)
>
> I wouldn't know. Once I decided that Krita was going to
> be the best jumpstart for the kind of app I wanted to
> make, I went to work on Krita. I mean, Krita has been
> through at least three redesigns of its core -- I figured
> it didn't need another heart transplant.
>

The problem I see is that your engine is both foreign (as in not known to
e.g. a Qt developer) and over exposed (e.g. KisPainter provides access to
the tiles, which IMHO are an implementation detail)
Because of this problem you cannot reuse tools from other applications
like KolourPaint, which may have a more naive core, but more features.

The idea behind an interface is to provide a layer where 3rd party
developers can work with, without having to know the gory details, just
IMHO of course.

If you want to implement tools in your application which need access to
the lower details (say, more than 4 colour components), fine, provide
subclasses which expose these features. But make your base classes
compatible to the common API (QPainter, QPaintDevice), so that the tools
may be ported.

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]