Krita 1.6

[Boudewijn Rempt]

On Sunday 05 February 2006 21:29, Michael Thaler wrote:

> What do you think?

This is quite a complex problem with all kinds of little niggles. Sure -- we 
can do a lot with Qt3 yet. We don't even exhaust the possibilities of Qt2 
yet :-). There are a couple of things we _need_ Qt4 for:

* Threading. If we want to have a responsive gui even when there's something  
  doing something complicated in another window, we need Qt4's threading 
  support.
* Blending. If we want functional part layers, we need Qt4
* Text tool. For a good text tool, we need Scribe, or rather, a kotext
  based on scribe.
* OpenGL. If we want to move our OpenGL support forward, we need Qt4.
* Dockers. It seems that Qt4 finally solves much of the messed-upness of 
QDockWindow. 
* Anti-aliased hsv color picer. With all the anti-aliased goodness, the 
pixelly-blockiness of the hsv wheel is starting to grate.

For many other things we can just build on what we have:

* More functionality, more features. This includes filters, tools, paint ops,
file formats -- but also core functionality like the selection methods Michael 
is implementing now.
* More robust implementation (checking pointers before deferencing them, 
blush)

Then there's the consideration what wainting to release until we can release 
with KDE4 will do. Realistically, for KDE4 we're looking at mid 2007, which 
is a Bad Thing, and one that I've gotten really angry about. Give me a stable 
libs in March, and we can release our next version, with Qt4 goodness in 
October. But we're apparently not going to get that. And while we have a 
technology lead now in the free X11 software world, it's not solid, so we 
cannot afford pulling a gimp and telling people they'll have to wait a couple 
of years for the next version.

And then again, there are some things to avoid: if we do a 1.6 based on 
KOffice 1.5, and at the same time a port to 2.0, I am very, very sure that 
both Krita's will wildly diverge as to their core api's, which may even mean 
creating a nearly-perpetual fork, a kind of gimp-gegl situation, where the 
cool technology is Qt4/KDE4 based, but the functionality Qt3/KOffice 1.5 
based, and too much to port, ever.

One possible solution is a 1.6 release with small core updates (but not 
changes in, e.g. the colorspace api, just adding stuff, not changing existing 
things) and lots of new filters, plugins and other fun stuff. After all, 
there are people who like doing core stuff (me, Casper, Bart, Adrian), and 
people who prefer adding features (Cyrille, Michael, me again) (and tell me 
if I've got you pigeon-holed wrong). So it would not mean less hands to work 
on the port, and it would mean only marginally less hands working on the 
features for 1.6. In that case, we need to really agree & keep our promises 
on keeping the 1.6 basicaly a 1.5 + features, not more.

On the other hand, if kdelibs4 offers us a relatively stable library -- even 
if the api is not stable, I'm just talking about being to compile against a 
snapshot and run the app without it crashing because of kdelibs, then porting 
Krita to Qt4 will take less than a month. And then we can start hacking 
features again and having fun with snapshot releases that include our copy of 
kdelibs4.

Finally, I would like to note that, historically, we've never been able to do 
more than one release a year. And that's not laziness: releases cost time, 
freezes take three months, the thinking and mulling about new development 
takes a coupe of months, there are holidays and so on. A 1.6 release in 
September would mean a different release dude from me, too :-).

So: options are:

1.6, but no core hacking, just fun features and plugins. Release in September 
(which means freeze in July!) 2.0 in parallel.

2.0, but a quick port followed by a thoughful implementation of new features. 
Freeze in December, release in February, March 2007

Additionally:

Release of Cyrille's cool plugins pack whenever we hit a milestone there. 
Maybe every two months?


No options should be, for me: 

* porting to kdelibs4 and keep porting to new snapshots all the time and 
wasting our time and energy on that kind of non-productive fun.

* forking an api incompatible 1.6 and 2.0 branch and doing core work in both

* creating a 1.6 and releasing it in 2007


-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kimageshop/attachments/20060205/b62cd68d/attachment.pgp