Nabble - kimageshop

Re: a nice concept idea that we can adopt

2009-12-08T22:58:36Z

On Tuesday 08 December 2009, Martin Renold wrote:
> On Sun, Dec 06, 2009 at 11:00:01AM +0100, Boudewijn Rempt wrote:
> > I think I've seen the app before -- it won't run under wine, at least not
> > for me, because of some administrator issues.
>
> SAI 1.0.0 runs well in wine (using wine 1.0.1 at the moment but I'm pretty
> sure I used other versions before) except for the lack of pressure support.

Hm... I've got wine 1.1.9 and it tells me that CreateProcess failed with error
2.
--
Boudewijn Rempt | http://www.valdyas.org

_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: a nice concept idea that we can adopt

2009-12-08T10:52:26Z

On Sun, Dec 06, 2009 at 11:00:01AM +0100, Boudewijn Rempt wrote:
> I think I've seen the app before -- it won't run under wine, at least not for
> me, because of some administrator issues.

SAI 1.0.0 runs well in wine (using wine 1.0.1 at the moment but I'm pretty
sure I used other versions before) except for the lack of pressure support.
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

koffice

2009-12-07T10:30:54Z

SVN commit 1059942 by berger:

krita/trunk now requires KDE 4.3.x

CCMAIL:kimageshop@...

M +7 -2 CMakeLists.txt

--- trunk/koffice/CMakeLists.txt #1059941:1059942
@@ -82,6 +82,11 @@
include (MacroAdditionalCleanFiles)
include (MacroAddFileDependencies)

+#
+# Test for KDE >= 4.3.0
+#
+macro_ensure_version( "4.3.0" ${KDE_VERSION} KDE4_3_0 )
+
###########################
############################
## Required dependencies ##
@@ -350,9 +355,9 @@
endif(NOT BZIP2_EXECUTABLE )

### Krita: pigment, blitz, eigen2, exiv2
-if(NOT BUILD_pigment OR NOT BLITZ_FOUND OR NOT EIGEN2_FOUND OR NOT EXIV2_FOUND)
+if(NOT BUILD_pigment OR NOT BLITZ_FOUND OR NOT EIGEN2_FOUND OR NOT EXIV2_FOUND OR NOT KDE4_3_0)
set(SHOULD_BUILD_KRITA FALSE)
-endif(NOT BUILD_pigment OR NOT BLITZ_FOUND OR NOT EIGEN2_FOUND OR NOT EXIV2_FOUND)
+endif(NOT BUILD_pigment OR NOT BLITZ_FOUND OR NOT EIGEN2_FOUND OR NOT EXIV2_FOUND OR NOT KDE4_3_0)

### KPlato: kdepimlibs
if(NOT KdepimLibs_FOUND)
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: Fwd: Re: koffice/krita/ui

2009-12-07T08:18:35Z

> It's the first time I hear of it, and I don't know how to fix it. Gentoo is
> weird...
>
I have never used Gentoo so I don't know :)

> Btw, one little warning from me - if you happen to (or going to) have gluon
> on your system, be advised that they bundle and *install* FindGLEW.cmake
> (and some others) modules that is incompatible with koffice one, and as
> it's installed in <prefix>/share/apps/cmake/modules - it shadows koffice
> private one causing libkritaui linking issues.

Actually our FindGLEW.cmake could land in kdelibs probably so that we can
share it with gluon project [1] as it seems to be KDE library. But I don't see
into the problem, I just guess.

[1] http://gluon.tuxfamily.org/
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: Fwd: Re: koffice/krita/ui

2009-12-07T08:02:31Z

On Monday 07 December 2009, LukasT.dev@... wrote:

> FindGLEW.cmake is problematic, did you know that?

It's the first time I hear of it, and I don't know how to fix it. Gentoo is
weird...

--
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Fwd: Re: koffice/krita/ui

2009-12-07T07:49:39Z

FindGLEW.cmake is problematic, did you know that?

Lukas

---------- Forwarded Message ----------

Subject: Re: koffice/krita/ui
Date: Monday 07 December 2009
From: Maciej Mrozowski <reavertm@...>
To: "LukasT.dev@..." <lukast.dev@...>

On Monday 07 of December 2009 15:54:06 dev wrote:
> Hi, this is correct fix. I'm author of that code. Thank you for fix, I
> don't compile without opengl, you do?

Hi
Yeah, I'm packaging KDE SC for Gentoo and I happen to occasionally test
various compilation configurations in trunk. And when I feel some fix is
harmless or obvious, I commit it right away. Feel free to spank me when I'm
wrong :)

Btw, one little warning from me - if you happen to (or going to) have gluon on
your system, be advised that they bundle and *install* FindGLEW.cmake (and
some others) modules that is incompatible with koffice one, and as it's
installed in <prefix>/share/apps/cmake/modules - it shadows koffice private
one causing libkritaui linking issues.

> On Monday 07 December 2009 04:14:12 Maciej Mrozowski wrote:
> > SVN commit 1059624 by mmrozowski:
> >
> > Fix building krita without OpenGL
> >
> >
> > CCMAIL: kimageshop@...
> >
> > M +4 -1 kis_3d_object_model.h
> >
> >
> > --- trunk/koffice/krita/ui/kis_3d_object_model.h #1059623:1059624
> > @@ -55,8 +55,9 @@
> > //void parseModel();
> > void parseMaterial(const QString &fileName);
> >
> > -
> > +#ifdef HAVE_OPENGL
> > GLuint displayList();
> > +#endif // HAVE_OPENGL
> >
> > private:
> > QString m_fileName;
> > @@ -71,7 +72,9 @@
> > void debug(Material m);
> >
> > bool m_cached;
> > +#ifdef HAVE_OPENGL
> > GLuint m_displayList;
> > +#endif // HAVE_OPENGL
> > };
> >
> > #endif // KIS_3D_OBJECT_MODEL_H
>

--
regards
MM

-------------------------------------------------------
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: koffice/krita/ui

2009-12-07T07:31:14Z

On Monday 07 December 2009, Lukáš Tvrdý wrote:
> SVN commit 1059822 by lukast:
>
> Probably some debug code. I had thumb.png in every folder I run Krita :)
>
> I guess shicmap used it? Is it ok to comment?
>

It's my fault, i think. It can be completely removed.

--
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

koffice/krita/ui

2009-12-07T05:10:54Z

SVN commit 1059822 by lukast:

Probably some debug code. I had thumb.png in every folder I run Krita :)

I guess shicmap used it? Is it ok to comment?

CC:kimageshop@...

M +1 -1 kis_doc2.cc

--- trunk/koffice/krita/ui/kis_doc2.cc #1059821:1059822
@@ -456,7 +456,7 @@
newSize.scale(size, Qt::KeepAspectRatio);

QImage image = m_d->image->convertToQImage(QRect(0, 0, newSize.width(), newSize.height()), newSize, 0);
- image.save("thumb.png");
+ //image.save("thumb.png");
return QPixmap::fromImage(image);
}
return QPixmap(size);
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

koffice/krita/ui

2009-12-06T19:14:12Z

SVN commit 1059624 by mmrozowski:

Fix building krita without OpenGL

CCMAIL: kimageshop@...

M +4 -1 kis_3d_object_model.h

--- trunk/koffice/krita/ui/kis_3d_object_model.h #1059623:1059624
@@ -55,8 +55,9 @@
//void parseModel();
void parseMaterial(const QString &fileName);

-
+#ifdef HAVE_OPENGL
GLuint displayList();
+#endif // HAVE_OPENGL

private:
QString m_fileName;
@@ -71,7 +72,9 @@
void debug(Material m);

bool m_cached;
+#ifdef HAVE_OPENGL
GLuint m_displayList;
+#endif // HAVE_OPENGL
};

#endif // KIS_3D_OBJECT_MODEL_H
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: #ifdef INFINITE_CANVAS

2009-12-06T05:12:22Z

On Saturday 05 December 2009, Dmitry Kazakov wrote:

> Lukas, is there any way to draw decorations on some transparent "layer"
> (QImage) and then just paint this at the top of the base image?

That reminds me of the 1.x way of doing things, where masks and selections
were drawn within the recomposition stack.

--
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: #ifdef INFINITE_CANVAS

2009-12-06T04:57:10Z

On Saturday 05 December 2009 23:14:19 Dmitry Kazakov wrote:

> On Fri, Dec 4, 2009 at 2:21 AM, LukasT.dev@...
> I think we should merge them somehow.
>
> What we have at the moment (in update order):
>
> image->rootLayer()->projection() - stores image without any borders and
> decorations (using tiles)
> view->prescaledProjection()::d->projectionBackend - stores unscaled
> original (either tiles or QImage - config-dependent)
>
> view->prescaledProjection()->prescaledQImage() - i'm not sure what stuff is
> painted in this image. It stores scaled-down image, shifted according to
> view state. As far as i know it doesn't have any selections, flakes(?)
> inside - they are painted in canvas->drawDecorations().
>
> <-- here we want to have another copy of it with prepainted decorations
>
> After this we paint an outcome onto the window.
>
>
> Lukas, is there any way to draw decorations on some transparent "layer"
> (QImage) and then just paint this at the top of the base image?

I'm not sure :/ because sometimes you want to paint the decorations, brush
outlines on the border of the canvas. Maybe we can find some way how to tile
the canvas qimage so that borders are separated rectangular tiles and canvas
image is the one from the methods you mention. But then I don't know how to
paint stuff easily :(

> Btw, i still don't fully understand what is "INFINITE" =) I haven't found
> such a name in QPainterCanvas. It is the feature that i can paint outside
> actual image, isn't it?

Sorry, it is typo, it is INDEPENDENT_CANVAS and I named it that way because it
brings independence to platforms regarding the rendering the UI stuff. Windows
uses raster engine AFAIK, Linux has X11, but this way you can force the widget
to use Raster and I don't know about Mac OS but same applies to Mac - Raster
is used for the one widget.

I was thinking about Why not run krita like krita --graphicssystem=raster (not
exactly sure) but then raster is used for every widget. Raster is slower (I
read it somewhere) then X11 because of some optimizations I suppose..

_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: a nice concept idea that we can adopt

2009-12-06T02:00:01Z

On Sunday 06 December 2009, Vera Lukman wrote:
> Hello all,
>
> I found a very nice idea (or rather concept) on a Japanese painting
> program. The program is called SAI, it runs on windows (I hope you can
> have wine to try this program out). Visit this website for an English
> version of it http://sai.detstwo.com/sai/. I like how you can rotate
> your canvas (not transform) to easily sketch.

That was part of Lukas' gsoc project, but he didn't have time to finish it.
It's something we really want to have, but even a plain canvas mirror would be
really useful already.

> They also have nice
> brushes. Lukas, since you were giving the idea of 'I can design, and
> you can code', how about this? :) It will be a great GUI improvement
> for Krita.

I think I've seen the app before -- it won't run under wine, at least not for
me, because of some administrator issues.

--
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

a nice concept idea that we can adopt

2009-12-05T22:03:20Z

Hello all,

I found a very nice idea (or rather concept) on a Japanese painting
program. The program is called SAI, it runs on windows (I hope you can
have wine to try this program out). Visit this website for an English
version of it http://sai.detstwo.com/sai/. I like how you can rotate
your canvas (not transform) to easily sketch. They also have nice
brushes. Lukas, since you were giving the idea of 'I can design, and
you can code', how about this? :) It will be a great GUI improvement
for Krita.

Cheers,
Vera
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: #ifdef INFINITE_CANVAS

2009-12-05T14:14:19Z

On Fri, Dec 4, 2009 at 2:21 AM, LukasT.dev@... <lukast.dev@...> wrote:

Hi,

I commited fix for the outline of the selection by outline tool and I wanted to
ask what we will do with the buffer I added to QPainter canvas? Should I still
produce two versions code? One for the canvas with buffer compiled and one
without? I added black background to the dotted line as second version btw.

When I added the QImage as another buffer there were some things about the
speed. So do we plan to leave the buffer or remove? Or merge somehow with
projection? But how? QImage in QPainter canvas = projection image + gray
borders => RasterOp_XOR works for tools

The QImage is used so that every platform uses RasterOp for the canvas so that
we get RasterOp_XOR working and having visible tool outlines.

On the other hand it may be slowing down the performance because of another
buffer. I did not notice any difference but I don't know how to measure it.

So what? Remove the ifdef and use INFINITE or produce two versions? That means
support 3 canvas types = OpenGL and QPainter with and without RasterOp_XOR.

?

I think we should merge them somehow.

What we have at the moment (in update order):

image->rootLayer()->projection() - stores image without any borders and decorations (using tiles)
view->prescaledProjection()::d->projectionBackend - stores unscaled original (either tiles or QImage - config-dependent)

view->prescaledProjection()->prescaledQImage() - i'm not sure what stuff is painted in this image. It stores scaled-down image, shifted according to view state. As far as i know it doesn't have any selections, flakes(?) inside - they are painted in canvas->drawDecorations().

<-- here we want to have another copy of it with prepainted decorations

After this we paint an outcome onto the window.

Lukas, is there any way to draw decorations on some transparent "layer" (QImage) and then just paint this at the top of the base image?

Btw, i still don't fully understand what is "INFINITE" =) I haven't found such a name in QPainterCanvas. It is the feature that i can paint outside actual image, isn't it?

--
Dmitry Kazakov

_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: #ifdef INFINITE_CANVAS

2009-12-05T02:45:17Z

On Friday 04 December 2009, LukasT.dev@... wrote:

> Hi,
>
> I commited fix for the outline of the selection by outline tool and I
> wanted to ask what we will do with the buffer I added to QPainter canvas?
> Should I still produce two versions code? One for the canvas with buffer
> compiled and one without? I added black background to the dotted line as
> second version btw.
>
> When I added the QImage as another buffer there were some things about the
> speed. So do we plan to leave the buffer or remove? Or merge somehow with
> projection? But how? QImage in QPainter canvas = projection image + gray
> borders => RasterOp_XOR works for tools
>
> The QImage is used so that every platform uses RasterOp for the canvas so
> that we get RasterOp_XOR working and having visible tool outlines.
>
> On the other hand it may be slowing down the performance because of another
> buffer. I did not notice any difference but I don't know how to measure it.
>
> So what? Remove the ifdef and use INFINITE or produce two versions? That
> means support 3 canvas types = OpenGL and QPainter with and without
> RasterOp_XOR.
>

I have to admit that I really haven't got a clue here :-(, so I cannot make
any pronouncement ex cathedra about the issue.

--
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: Color source for paintops

2009-12-05T02:44:04Z

On Saturday 05 December 2009, Matthew Woehlke wrote:

> Cyrille Berger wrote:
> > As discussed with Lukas on IRC last week, here is a patch that allow more
> > flexibility on the color source used to colorize the dabs.
> >
> > It introduce a new base class KisColorSource, which abstract color
> > sources. There are two types of color source, uniform color sources,
> > where the color is the same on the whole dab (but might be different at
> > each stroke), and those who can have different color for each pixel of
> > the dab. And we want to apply transformation to those color source
> > (mostly color transformation).
>
> Well... I haven't been much for KDE work lately, and I'm not likely to
> be poking this until it is in trunk, at best. However, it reminds me of
> an idea I've had around for some time.
>
> Long time ago I had developed some PS hacks for painting decent-looking
> fur without a huge lot of effort. Partly this involved applying color
> jitter to multi-count brushes (not sure what the correct term is for
> each paint operation, i.e. what happens every <spacing> px, paints the
> brush shape multiple times, with jitter factors applied separately each
> time).
>
> Anyway, what I would really like to do is have a 2D-gradient color
> source, where I can assign various parameters to either axis. (I imagine
> this as a series of normal 1D gradients that act as stops in another 1D
> gradient, if that makes sense; if not, holler, and I can explain
> better.) Parameters would be e.g. time, distance along stroke, pressure,
> stroke angle (stroke angle is actually the one I care about)... and also
> something like 'brush part'. For multi-count brushes, divide the axis
> evenly by the count to get the color for each part.
>
> You could also assign an axis spatially, which would be like the above,
> but with a second axis of variation.
>
> However, the real gold is doing this with bristle brushes, where each
> bristle gets assigned an axis value /randomly/. So it is like dipping
> your brush in a paint swatch that is poorly mixed. But better, it gives
> you instant peppered fur :-).

It should be easy enough to extend the sumi-e brush with this; in fact, we
should probably rename it bristle brush once the preset saving/loading is
done, so we can have a sumi-e, and oilpaint and whatever presets.

> (Then if you want to get *really* fancy, you add 'cross-contamination',
> such that over time, the paint from one bristle mixes with that of the
> other bristles it touches...)

I'm not sure about the sumi-e brush, but my old chinese paint brush (which is
no longer compiled) did have paint stealing between bristles, which is easily
extended to mixing paint between bristles.

>
> I do have to wonder if this (stick-with-a-bristle) is how this patch is
> supposed to work, though... and if not, if maybe that should be an
> option :-).
>

--
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: weird behaviour?

2009-12-04T22:08:35Z

No, mine is 32 bits. Here is the console output

Calling appendChild() on a null node does nothing.
krita(3558) KisDoc2::undoIndexChanged: trying to clear undo stack to
index 1 : no command at that index
krita(3558) KisDoc2::undoIndexChanged: trying to clear undo stack to
index 1 : no command at that index
krita(3558) KisDoc2::undoIndexChanged: trying to clear undo stack to
index 2 : no command at that index
krita(3558) KisDoc2::undoIndexChanged: trying to clear undo stack to
index 2 : no command at that index
krita(3558) KisDoc2::undoIndexChanged: trying to clear undo stack to
index 0 : no command at that index
krita(3558) KisDoc2::undoIndexChanged: trying to clear undo stack to
index 0 : no command at that index

On Fri, Dec 4, 2009 at 11:02 AM, Boudewijn Rempt <boud@...> wrote:

> On Friday 04 December 2009, Vera Lukman wrote:
>> If you mean weird behaviour by this:
>> > krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to
>> > index 1
>> >
>> > : no command at that index
>> >
>> > krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to
>> > index 1
>> >
>> > : no command at that index
>> >
>> > krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to
>> > index 2
>> >
>> > : no command at that index
>> >
>> > krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to
>> > index 2
>> >
>> > : no command at that index
>>
>> then I get it all the time. It seems that you are using the pop up
>> palette. Is it a bug in the pop up palette? Do you get the same
>> problem if you select the brush normally (ie. not using the palette?)
>>
>
> Yes, just when painting -- without having opened the palette. Do you use a 64
> bits system?
>
> --
> Boudewijn Rempt | http://www.valdyas.org
> _______________________________________________
> kimageshop mailing list
> kimageshop@...
> https://mail.kde.org/mailman/listinfo/kimageshop
>

_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: Color source for paintops

2009-12-04T16:56:33Z

Cyrille Berger wrote:
> As discussed with Lukas on IRC last week, here is a patch that allow more
> flexibility on the color source used to colorize the dabs.
>
> It introduce a new base class KisColorSource, which abstract color sources.
> There are two types of color source, uniform color sources, where the color is
> the same on the whole dab (but might be different at each stroke), and those
> who can have different color for each pixel of the dab. And we want to apply
> transformation to those color source (mostly color transformation).

Well... I haven't been much for KDE work lately, and I'm not likely to
be poking this until it is in trunk, at best. However, it reminds me of
an idea I've had around for some time.

Long time ago I had developed some PS hacks for painting decent-looking
fur without a huge lot of effort. Partly this involved applying color
jitter to multi-count brushes (not sure what the correct term is for
each paint operation, i.e. what happens every <spacing> px, paints the
brush shape multiple times, with jitter factors applied separately each
time).

Anyway, what I would really like to do is have a 2D-gradient color
source, where I can assign various parameters to either axis. (I imagine
this as a series of normal 1D gradients that act as stops in another 1D
gradient, if that makes sense; if not, holler, and I can explain
better.) Parameters would be e.g. time, distance along stroke, pressure,
stroke angle (stroke angle is actually the one I care about)... and also
something like 'brush part'. For multi-count brushes, divide the axis
evenly by the count to get the color for each part.

You could also assign an axis spatially, which would be like the above,
but with a second axis of variation.

However, the real gold is doing this with bristle brushes, where each
bristle gets assigned an axis value /randomly/. So it is like dipping
your brush in a paint swatch that is poorly mixed. But better, it gives
you instant peppered fur :-).

(Then if you want to get *really* fancy, you add 'cross-contamination',
such that over time, the paint from one bristle mixes with that of the
other bristles it touches...)

I do have to wonder if this (stick-with-a-bristle) is how this patch is
supposed to work, though... and if not, if maybe that should be an
option :-).

--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Ok, so the quotes aren't entirely original.

_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: weird behaviour?

2009-12-04T11:02:45Z

On Friday 04 December 2009, Vera Lukman wrote:

> If you mean weird behaviour by this:
> > krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to
> > index 1
> >
> > : no command at that index
> >
> > krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to
> > index 1
> >
> > : no command at that index
> >
> > krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to
> > index 2
> >
> > : no command at that index
> >
> > krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to
> > index 2
> >
> > : no command at that index
>
> then I get it all the time. It seems that you are using the pop up
> palette. Is it a bug in the pop up palette? Do you get the same
> problem if you select the brush normally (ie. not using the palette?)
>

Yes, just when painting -- without having opened the palette. Do you use a 64
bits system?

--
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: weird behaviour?

2009-12-04T10:36:18Z

If you mean weird behaviour by this:

> krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 1
> : no command at that index
> krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 1
> : no command at that index
> krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 2
> : no command at that index
> krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 2
> : no command at that index

then I get it all the time. It seems that you are using the pop up
palette. Is it a bug in the pop up palette? Do you get the same
problem if you select the brush normally (ie. not using the palette?)

Vera
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

weird behaviour?

2009-12-03T23:57:35Z

I'm seeing some very weird behaviour this morning: first I was painting with
the sumi-brush, then added a gradient. My _last_ stroke _before_ I added the
gradient was shown on top of the gradient, as if the temporary layer was still
in the recomposition queue.

When painting again, it disappeared. All the while, the konsole spewed
messages like:

krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 1
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 1
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 2
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 2
: no command at that index
[KisToolPaint] MidButton: calling palette
[KoFavoriteResourceManager] popup palette called
[KisPopupPalette] mouse position: QPointF(62, 69)
[KisPopupPalette] favorite brush position: 2
[KoFavoriteResourceManager] Calling brush: "sumibrush"
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 3
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 3
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 4
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 4
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 5
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 5
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 6
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 6
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 7
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 7
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 8
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 8
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 9
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 9
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 10
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 10
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 11
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 11
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 12
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 12
: no command at that index
[KisToolPaint] MidButton: calling palette
[KoFavoriteResourceManager] popup palette called
[KisPopupPalette] mouse position: QPointF(146, 69)
[KisPopupPalette] favorite brush position: 1
[KoFavoriteResourceManager] Calling brush: "spraybrush"
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 13
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 13
: no command at that index
QLayout: Attempting to add QLayout "" to QWidget "KritaShape/KisToolDynaoption
widget", which already has a layout
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 14
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 14
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 15
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 15
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 0
: no command at that index
krita(28090) KisDoc2::undoIndexChanged: trying to clear undo stack to index 0
: no command at that index
QThreadStorage: Thread 0x60da70 exited after QThreadStorage 2147483615
destroyed

I'm wondering whether this is because I'm using a 64 bit system now. I get the
following warning when compiling:

In file included from
/home/boud/kde/src/koffice/krita/image/tiles3/kis_memento_manager.h:24,
from
/home/boud/kde/src/koffice/krita/image/tiles3/kis_tiled_data_manager.h:32,
from
/home/boud/kde/src/koffice/krita/image/kis_datamanager.h:29,
from
/home/boud/kde/src/koffice/krita/image/kis_transform_worker.cc:30:
/home/boud/kde/src/koffice/krita/image/tiles3/kis_memento_item.h: In member
function ‘void KisMementoItem::debugPrintInfo()’:
/home/boud/kde/src/koffice/krita/image/tiles3/kis_memento_item.h:163: warning:
format ‘%X’ expects type ‘unsigned int’, but argument 2 has type ‘quintptr’
/home/boud/kde/src/koffice/krita/image/tiles3/kis_memento_item.h:163: warning:
format ‘%X’ expects type ‘unsigned int’, but argument 3 has type ‘quintptr’
/home/boud/kde/src/koffice/krita/image/tiles3/kis_memento_item.h:168: warning:
format ‘%X’ expects type ‘unsigned int’, but argument 2 has type ‘quintptr’
/home/boud/kde/src/koffice/krita/image/tiles3/kis_memento_item.h:168: warning:
format ‘%X’ expects type ‘unsigned int’, but argument 3 has type ‘long long
unsigned int’
/home/boud/kde/src/koffice/krita/image/tiles3/kis_memento_item.h:170: warning:
format ‘%X’ expects type ‘unsigned int’, but argument 2 has type ‘quintptr’
/home/boud/kde/src/koffice/krita/image/tiles3/kis_memento_item.h:170: warning:
format ‘%X’ expects type ‘unsigned int’, but argument 3 has type ‘long long
unsigned int’

--
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

#ifdef INFINITE_CANVAS

2009-12-03T15:21:45Z

Hi,

I commited fix for the outline of the selection by outline tool and I wanted to
ask what we will do with the buffer I added to QPainter canvas? Should I still
produce two versions code? One for the canvas with buffer compiled and one
without? I added black background to the dotted line as second version btw.

When I added the QImage as another buffer there were some things about the
speed. So do we plan to leave the buffer or remove? Or merge somehow with
projection? But how? QImage in QPainter canvas = projection image + gray
borders => RasterOp_XOR works for tools

The QImage is used so that every platform uses RasterOp for the canvas so that
we get RasterOp_XOR working and having visible tool outlines.

On the other hand it may be slowing down the performance because of another
buffer. I did not notice any difference but I don't know how to measure it.

So what? Remove the ifdef and use INFINITE or produce two versions? That means
support 3 canvas types = OpenGL and QPainter with and without RasterOp_XOR.

?
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: bug bug bug (pop up palette)

2009-12-03T01:48:57Z

Thank you Cyrille. I have changed the behaviour that allows the user
to hide the palette by left clicking outside the palette.

On Thu, Dec 3, 2009 at 12:12 AM, Cyrille Berger <cberger@...> wrote:

> Hi Vera,
>
> I tried yesterday, looks promising. The only thing that annoyed me is the way
> to hide the palette, currently you have to press middle-click to show/hide. I
> think it would be better to also hide the palette when the user click outside
> of the palette, this would make the behavior of the palette consistant with
> other pop up.
>
> --
> Cyrille Berger
> _______________________________________________
> kimageshop mailing list
> kimageshop@...
> https://mail.kde.org/mailman/listinfo/kimageshop
>

_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: bug bug bug (pop up palette)

2009-12-03T00:12:53Z

Hi Vera,

I tried yesterday, looks promising. The only thing that annoyed me is the way
to hide the palette, currently you have to press middle-click to show/hide. I
think it would be better to also hide the palette when the user click outside
of the palette, this would make the behavior of the palette consistant with
other pop up.

--
Cyrille Berger
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: bug bug bug (pop up palette)

2009-12-02T12:58:16Z

> I think that 7-9 would be best, and to have an uneven number. It just feels --
> more right, or something.

all right, I'll take the greatest of 7 and 9 :)
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: bug bug bug (pop up palette)

2009-12-02T12:49:35Z

On Wednesday 02 December 2009, Vera Lukman wrote:

> >> The number of
> >> total favorite brushes is limited to 8
> >
> > Sounds good -- especially since some research in the sixties seems to
> > have proved that people only can remember between 7 and 9 items anyway
> > (I've never read the research, but it gets quoted a lot, so it must be
> > good!).
>
> I actually updated the code again last night and changed it back to
> 12. The math works fine with 12 now. Maybe I should switch it back to
> 8? I know from my GUI course that humans can only remember from 5 - 7
> items, so it's good to put at most 7 menus. Maybe I should follow this
> rule and go back to 6 or 9?

I think that 7-9 would be best, and to have an uneven number. It just feels --
more right, or something.

> > I'll make a new screenshot for next week's this week in krita :-)
>
> Thank you boud! :D
>
> Cheers,
> Vera
> _______________________________________________
> kimageshop mailing list
> kimageshop@...
> https://mail.kde.org/mailman/listinfo/kimageshop
>

--
Boudewijn Rempt | http://www.valdyas.org
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: bug bug bug (pop up palette)

2009-12-02T12:22:33Z

>> The number of
>> total favorite brushes is limited to 8
>
> Sounds good -- especially since some research in the sixties seems to have
> proved that people only can remember between 7 and 9 items anyway (I've never
> read the research, but it gets quoted a lot, so it must be good!).

I actually updated the code again last night and changed it back to
12. The math works fine with 12 now. Maybe I should switch it back to
8? I know from my GUI course that humans can only remember from 5 - 7
items, so it's good to put at most 7 menus. Maybe I should follow this
rule and go back to 6 or 9?

>
> I'll make a new screenshot for next week's this week in krita :-)

Thank you boud! :D

Cheers,
Vera
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: bug bug bug (pop up palette)

2009-12-01T23:23:52Z

On Wednesday 02 December 2009, Vera Lukman wrote:
> Hey all,
>
> I am glad to announce that the bugs are now gone. I set the wrong
> option for the widget. I found another bug and I have fixed it,
> although the solution is not so pretty. Thank you for your help
> Cyrille :)
> I have once again updated the widget. I removed KisFavoriteBrushData
> because it is not necessary to save the icons anymore. The number of
> total favorite brushes is limited to 8

Sounds good -- especially since some research in the sixties seems to have
proved that people only can remember between 7 and 9 items anyway (I've never
read the research, but it gets quoted a lot, so it must be good!).

> or the pop up palette will be
> too cramped and the math formula that I used to detect brush index on
> the array will not be precise anymore (maybe I have to find a better
> formula to detect the brush index). Right now, the widget's background
> is dark gray. I am not sure why the colour is off, but it's all good
> so far.

I'll make a new screenshot for next week's this week in krita :-)

--
Boudewijn Rempt | http://www.valdyas.org

_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: bug bug bug (pop up palette)

2009-12-01T20:13:39Z

Hey all,

I am glad to announce that the bugs are now gone. I set the wrong
option for the widget. I found another bug and I have fixed it,
although the solution is not so pretty. Thank you for your help
Cyrille :)
I have once again updated the widget. I removed KisFavoriteBrushData
because it is not necessary to save the icons anymore. The number of
total favorite brushes is limited to 8 or the pop up palette will be
too cramped and the math formula that I used to detect brush index on
the array will not be precise anymore (maybe I have to find a better
formula to detect the brush index). Right now, the widget's background
is dark gray. I am not sure why the colour is off, but it's all good
so far.

Cheers,
Vera

On Tue, Dec 1, 2009 at 1:30 AM, Vera Lukman <vla24@...> wrote:

>>> 1. How to set offset point in case the window is not positioned on
>>> top left? To produce the bug:
>> You can use mapToGlobal:
>> http://doc.trolltech.com/4.5/qwidget.html#mapToGlobal
>
> I might did something wrong. I tried to use mapToGlobal but it didn't
> work. It seems to map to global with respect to the main window. So
> it's not helpful.
>
>>> 2. Pop up palette does not show up. To produce the bug:
>>> - start a canvas and another new canvas, close the older canvas.
>>> Seems like creating a new canvas/file doesn't create a new pop
>>> up palette. How can I detect/fix this?
>> where is the popup palette created at the moment ?
>
> It's created in KoFavoriteResourceManager
> (ui/ko_favorite_resource_manager.cpp). KoFavoriteResourceManager is
> created in KisView2 line 772, called by KisControlFrame line 119.
>

_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: 2.2 Release plan

2009-12-01T07:30:23Z

2009/12/1 Cyrille Berger <cberger@...>:

> On Tuesday 01 December 2009, Jaroslaw S wrote:
>> From the packagers POV:
>> But how to do that if Krita comes in the same tarball as the other apps?
>>
>> Is there a plan to have #ifdefs in Krita to support builds for OSes
>> that are based on Qt 4.5
>> (OK for those that agree with the degraded feature(s) or performace)?
> To be explicit, Qt 4.5 => no krita 2.2, there is no #ifdef that can save you
> from that, since what we are interested in the bug fix deep in Qt 4.6 that
> makes tablet work out of the box, instead of having to tell users that they
> need to edit their hal files.
> Since Krita is advertised as a paint application, it is a must have. So OSes
> that are based on Qt 4.5 and won't have 4.6 (is there any ?) won't have krita
> 2.2.

This is your choice of course and the discussion is not new.
It is 100% OK assuming:

a) all supported users are tablet users

b) there are no improvements in 2.2 other than tabled support

c) only users able to upgrade their OSes can benefit from advancements
made in Krita
(not all users can: not all own the running computers, suboptimal
policies e.g. in schools can prevent that,
or technically upgrade is not possible because the OS is based on
LiveCD/DVD/other readonly medium)

Why I am asking is not because _I_ cannot upgrade or I cannot help
others to do so:
I am trying to extract a more generic idea how to behave in such case
when we can offer the folowing options:
1. Stay with previous version of an app
2. Allow to devote some new features in exchange of giving some other new
(all the above assuming the option can be made with little development effort)

--
regards / pozdrawiam, Jaroslaw Staniek
Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org)
KDE Libraries for MS Windows (http://windows.kde.org)
http://www.linkedin.com/in/jstaniek
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: 2.2 Release plan

2009-12-01T06:14:29Z

On Tuesday 01 December 2009, Jaroslaw S wrote:
> From the packagers POV:
> But how to do that if Krita comes in the same tarball as the other apps?
>
> Is there a plan to have #ifdefs in Krita to support builds for OSes
> that are based on Qt 4.5
> (OK for those that agree with the degraded feature(s) or performace)?
To be explicit, Qt 4.5 => no krita 2.2, there is no #ifdef that can save you
from that, since what we are interested in the bug fix deep in Qt 4.6 that
makes tablet work out of the box, instead of having to tell users that they
need to edit their hal files.
Since Krita is advertised as a paint application, it is a must have. So OSes
that are based on Qt 4.5 and won't have 4.6 (is there any ?) won't have krita
2.2.

--
Cyrille Berger
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: 2.2 Release plan

2009-12-01T06:00:45Z

On Tue, 1 Dec 2009, Jaroslaw S wrote:

> But how to do that if Krita comes in the same tarball as the other apps?

When we make the move, I want Krita to be disabled if Qt 4.6 isn't present.

>
> Is there a plan to have #ifdefs in Krita to support builds for OSes
> that are based on Qt 4.5
> (OK for those that agree with the degraded feature(s) or performace)?

For 2.2 and later I really don't want to make Krita availalble for
Qt 4.5.

Boudewijn

_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: 2.2 Release plan

2009-12-01T05:45:45Z

2009/12/1 Cyrille Berger <cberger@...>:
> On a side note, about Qt/KDE dependencies. We had a lot of discussion in the
> past on the subject, but no real conclusion. What is sure is that Krita 2.2
> will require Qt 4.6 (and therefor KDE 4.4), the reason is that 4.6 brings
> important fix to tablet support. Since there is no real reason to impose that
> dependency on other applications (unless other applications want to), that
> requirement would apply only to Krita.

From the packagers POV:
But how to do that if Krita comes in the same tarball as the other apps?

Is there a plan to have #ifdefs in Krita to support builds for OSes
that are based on Qt 4.5
(OK for those that agree with the degraded feature(s) or performace)?

--
regards / pozdrawiam, Jaroslaw Staniek
Kexi & KOffice (http://www.kexi-project.org, http://www.koffice.org)
KDE Libraries for MS Windows (http://windows.kde.org)
http://www.linkedin.com/in/jstaniek
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: 2.2 Release plan

2009-12-01T04:40:21Z

On a side note, about Qt/KDE dependencies. We had a lot of discussion in the
past on the subject, but no real conclusion. What is sure is that Krita 2.2
will require Qt 4.6 (and therefor KDE 4.4), the reason is that 4.6 brings
important fix to tablet support. Since there is no real reason to impose that
dependency on other applications (unless other applications want to), that
requirement would apply only to Krita. As for the deadline, I suggest to wait
after the 4.4 release, and to wait for Krita developers to have available
upgrades from their distributions.

--
Cyrille Berger
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop

Re: bug bug bug (pop up palette)

2009-12-01T01:30:31Z

>> 1. How to set offset point in case the window is not positioned on
>> top left? To produce the bug:
> You can use mapToGlobal:
> http://doc.trolltech.com/4.5/qwidget.html#mapToGlobal

I might did something wrong. I tried to use mapToGlobal but it didn't
work. It seems to map to global with respect to the main window. So
it's not helpful.

>> 2. Pop up palette does not show up. To produce the bug:
>> - start a canvas and another new canvas, close the older canvas.
>> Seems like creating a new canvas/file doesn't create a new pop
>> up palette. How can I detect/fix this?
> where is the popup palette created at the moment ?

It's created in KoFavoriteResourceManager
(ui/ko_favorite_resource_manager.cpp). KoFavoriteResourceManager is
created in KisView2 line 772, called by KisControlFrame line 119.
_______________________________________________
kimageshop mailing list
kimageshop@...
https://mail.kde.org/mailman/listinfo/kimageshop