[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 13:48:11
Message-ID: 57402.212.185.245.5.1074088091.squirrel () mail ! sz-online ! de
[Download RAW message or body]

> On Wed, 14 Jan 2004 dirk.schoenberger@sz-online.de wrote:
>>
>> More interesting is the basic design of Krita.
>> If a "simple" design of one QImage or multiple layered QImages will be
>> used, you can achieve quick results, because the infrastructure is
>> there.
>> This design should be enough for basic office editing tasks (basically
>> insert an image to use as clipart in a word processor document).
>> For an idea about what would be doable with this approach look at
>> kolourpaint in
>> kdenonbeta. The application is less than a month (I believe) old, but
>> already rather useable.
>
> Wasn't it based on Paintworks? Anyway, I've seen it, but, well... It's not
> the application that makes me dump XPaint.

- its a nice proof of concept that image editor applications in KDE don't
need multiple years for completion ;)
- I don't know PaintWorks, but it reminds me of MS Paint.

>
>> However, Krita wants to be a full blown image editing application, with
>> a
>> internal data model similar to the GIMP (layers and tiled images)
>> There exists no infratsructure for doing such things yet
>> (notwithstanding
>> GIMP core internally), so most of the current work is base research.
>> This may lead to better results in the future, at the expense of much
>> more
>> work now and in the near future.
>
> I don't know what _Krita_ wants to be :-) -- I know what _I_ want it to
> be, and
> for that you need a solid core. As soon as you want to work with alpha
> channels,

I am not sure about alpha channels, but I agrre if you want things like
more complex colormodels that RGBA (think more than 4 colour components)
or proper undo (if you implement undo by storing the full image, it could
become rather resource intesive. If you use tiles, it should become much
more handleable)

> life becomes much easier if you don't use QImage, but something home
> grown. Anyway,
> the tile manager, the colour model core, image import and export, it's all
> there. The KisPainter should be expanded with some more primitives, but
> what's
> there is solid. I expect some architectural changes to the way tools are
> loaded
> (now hard-coded, in the future kparts), and I want to have more
> intelligent
> brushes, but the core is done, basically. You don't need to hack the tile
> manager anymore (until one wants to have pixels defined by more than five
> integers,
> that is).

I am not sure about the KisPainter thing, but hey, I am just a bystander ;)
I believe in separation of concerns with common base interfaces.
Basically you have you painter and your paint device.
If tools want to integrate into your application, they use the standard
QPainter.
Your backend may be either simple (QPixmap paint device) or complex (Krita
tile based paint device).
Layers are done as multiple paint devices which are composited (actually I
am not quite sure about the last, because IMHO QPaintDevices are not
transparent. You have to hack around with masks, basically 1 bit
transparency)

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]