whither krita -- summary
Boudewijn Rempt
boud at valdyas.org
Thu Sep 24 16:26:38 CEST 2009
On Thursday 24 September 2009, Cyrille Berger wrote:
> On Thursday 24 September 2009, Boudewijn Rempt wrote:
> > Looks like the discussion has run its course, so I want to make a
> > shortish summary, juxtaposing the things mentioned. There were a couple
> > of interesting things noted! But that doesn't mean we've found our
> > direction.
> >
> > There are quite a number of contradictions:
>
> I wouldn't think most of these are contradictions...
>
> > flexible, comprehensive app <---------> polish and usability
>
> Not sure why there is a contradiction here.
Because if we attempt comprehensiveness, we don't (have time to) polish
anything. And comprehensiveness and flexibility come at the expense of a
complicated user interface.
> > platform for experimentation <---------> stable application for users
>
> Hum not a contradiction. Depend of what you are experimenting, if it's
> experimenting on core, then yes, but if it's a platform to allow new
> plugins, then you can have both stable plugins ship to the user and
> experimentation in your personal tree.
Experiments tend to satisfy the experimenter before becoming stable, polished
features. And experiments can very easily disrupt the rest of the application,
even if they are a plugin. The histogram docker is pretty dangerous, for
example.
> > creating images <---------> manipulating images
>
> I have never understood the difference :) Or by "creating images" you mean
> create from scratch ? And manipulating images taking a picture with a
> camera then do funky thing with it ?
>
> For instance, if I open a picture taken with my camera in Krita, I start to
> deform it (colors filters, pixel displacement) then I start to mix it with
> other thing. Did I manipulate an image or create one ?
Manipulate, I'd say. It's creating when you start new image elements yourself,
manipulating if you work with existing elements.
> If by manipulation of images, you mean improving the quality of pictures
> taken by a camera, then ok, but I would argue that neither the gimp or
> krita are the best tool for just that.
>
> > integrated in koffice <---------> attractive to artists
>
> I keep expressing doubts about that one. If you could find someone who has
> such a problem and make it discuss with us, and see if it's just troll,
> ignorence, "the weird idea that artists aren't just like any office
> worker" or if there is a real issue. I also think that the katelier
> concept has not been pushed to its full potential, because it requires
> someone to do it.
For instance, on #mypaint -- none of these guys are trolls:
04.09.2009-16:28 < vlada> guys, have you tried krita?
04.09.2009-16:29 < boud> I've written krita :P
04.09.2009-16:29 < boud> (well, large parts of it)
04.09.2009-16:29 < vlada> boud, I remember your blog :P
04.09.2009-16:29 < vlada> but nick is sooo unassociative :)
04.09.2009-16:31 < Songwind> I tried Krita several version ago, didn't particularly like it.
04.09.2009-16:31 < Songwind> and now I don't want to install KDE and Koffice just to use it.
04.09.2009-16:32 < vlada> reasonable choice
04.09.2009-17:01 < Popolon> The same, I'm not really a krita fan
04.09.2009-17:01 < Popolon> but some articles write their are some promizing features
04.09.2009-17:01 < Popolon> since few years
04.09.2009-17:01 < Popolon> I would like to see them
04.09.2009-17:10 < Popolon> What I most dislike, is the need to install kde office suite to have it
04.09.2009-17:10 < Popolon> else it looks good
04.09.2009-17:11 < Songwind> having too install KOffice wouldn't be a deal breaker for me if it didn't mean I had to have all the KDE
services r
unning. If it was just a Qt app, I would go ahead and invest a few hundred megs of space to check out the drawing program.
04.09.2009-17:12 < jonnor> what kind of services do you need to have running?
04.09.2009-17:14 < Songwind> kdeinit, the kparts, etc.
And, actually, the services a kde needs to have running mean that it's very unlikely
that there will ever be a krita installer for windows or a krita dmg for OSX.
Also, they clearly have noticed that we don't deliver what we are experimenting with.
> > corel painter <---------> photoshop
>
> I am sure an inbetween can be invented, without being a bastard, I see a
> lot of features that are common, after all, most of the artwork you see
> out there was made using photoshop, I don't see why a photoshop with
> natural media can't exist. It might need a lot of work to design a good
> UI.
>
> > competing with gimp <---------> competing with mypaint
>
> gimp/krita and mypaint/showfoto aren't in the same league, it's like
> comparing "dolphin" to "ls", mypaint can do one thing and do it very well.
> Krita and the gimp are swiss knife, they can do a lot of things.
Not if you look at the purpose of the application: gimp states as it purpose
image manipulation and mypaint painting. That's the difference between the
two, not whether one app has already grown up and the other hasn't.
MyPaint is already getting layer palettes and so on; it will certainly get all
the ui trappings and development has the same momentum krita had a couple of
years ago, but with focus and direction.
Krita right now can do a lot of things a little, but there isn't anything at
all that it can do well, let alone excel at. Sometimes that is caused by our
abysmal performance, sometimes it's just because the features are not
sufficiently finished and not well integrated.
> > go all node <---------> continue with the current core
>
> I don't see a contradiction here. For me we continue with the current core,
> until there is a better replacement, as far as I am concern, I would like
> to encourage Dmitry or anyone else to experiment with a "all node" core,
> and when it's ready, we can migrate to the new core. But that development
> should happen in a branch, not in trunk. We need innovation.
More than anything, I'd say, we need user adoption. And for that we need
stability and focus. We have had six new cores during the development of krita
(two before my time, then Patrick's, Casper's, Barts and now Dmitry's).
> > Use cases I've seen in the thread:
> >
> > * photo manipulation
> > * HDR workflow (for film or for pictures?
>
> Not sure what the question is about ? I think the flipbookdocker we have in
> the kross plugin could be extented to allow frame by frame editing of a
> movie (which was kind of the design goal of the flipbook).
Painting hdr backgrounds for use in animated movies is different from
combining multiple exposures into weird-looking photos.
> > * illustrations and comics
> > * sketching
> > * integration with movie workflow, blender
> > * web development (what is that, actually?)
>
> I see it as CSS design.
Then it's certainly one thing we can exclude from krita :-)
> > Can all these things work in one application?
>
> Yes.
But currently we are failing at that: we have lots of features, but none work
well, the discoverability is minimal and the integration into one user
interface sucks because we just add menu items and dockers into one big
basket. So I'd say, if we go for a big integrated can-do-everything app, we
need to come up with a UI strategy that works (after bug fixing and
performance work, of course.)
> > So, what's the vision?
> >
> > The only way I can resolve the above in a mission statement is something
> > like this: "krita is an platform for experimentation for developers and
> > application that surprises its users." I'm not sure whether this is
> > going to be a banner to conquer the world with!
>
> No. But I like our previous idea of "Krita, have fun with your image and be
> creative !"
Still, I'd prefer something a bit more focussed.
Maybe this is a good idea: if we have frequent releases, we could focus on one
use case per release. Like, let's make 2.4 the
bliss-out-enkithan's-comic-book-author-release (easy, _if_ we can do 1000dp
a4 grayscale :-), and the release after that is going to bliss out someone else?
--
Boudewijn Rempt | http://www.valdyas.org
More information about the kimageshop
mailing list