On Tue, Feb 16, 2010 at 4:16 PM, Olivier wrote:

I discovered some weeks ago the new Paint Dynamics feature of version 2.7 and the git one, but I would like to find some explanations about its use. One point which bothers me is that I thought there was some way to control the shape of the answer curve between some varying parameter (pressure, velocity, tilt, etc.) and some brush characteristic (opacity, hardness, size, etc.). However, I don't see this anywhere.

Curves don't exist in UI yet, because I personally suck at getting GTK to do what I want... If you know somebody with good GTK bending skills willing to help out, direct him/her to us. I could really use some help...

Hello,

On Tue, Feb 16, 2010 at 4:40 PM, Alexia Death wrote:

Curves don't exist in UI yet, because I personally suck at getting GTK to do what I want... If you know somebody with good GTK bending skills willing to help out, direct him/her to us. I could really use some help...

Can you give some explanations of what is needed? It suprises me that there is a problem with a curves widget, when we can "steal" most of the code from the existing curves dialog of the curve tool... I would like to know some more about this, maybe this is something that I can do (I probably won't be able to do it since my GTK programming skills aren't so great, but let's give it a try).

~LightningIsMyName

On Tuesday 16 February 2010 22:22:17 LightningIsMyName wrote:

Can you give some explanations of what is needed? It suprises me that there is a problem with a curves widget, when we can "steal" most of the code from the existing curves dialog of the curve tool... I would like to know some more about this, maybe this is something that I can do (I probably won't be able to do it since my GTK programming skills aren't so great, but let's give it a try).

Curves widget is not a problem. Problem is the general making of Peter's spec[1] so that developers who do know gtk, dont faint in disgust at the sight of the code. for example, one dock needs to hold 2.5 distinct views. the check gird and two very similar variants of curves views switched by the drop down. I cant even imagine a solution for this in gtk terms.

[1] http://gui.gimp.org/index.php/Paint_dynamics_specification

-- Alexia

Hello

On Tue, Feb 16, 2010 at 10:45 PM, Alexia Death wrote:

Curves widget is not a problem. Problem is the general making of Peter's spec[1] so that developers who do know gtk, dont faint in disgust at the sight of the code. for example, one dock needs to hold 2.5 distinct views. the check gird and two very similar variants of curves views switched by the drop down. I cant even imagine a solution for this in gtk terms.

[1] http://gui.gimp.org/index.php/Paint_dynamics_specification

Wow! This seems to be an amazing idea, and probably extremly long to implement...

So let's do some analyzing: 1. We need to implement a check grid. This seems to be pretty simple using a GtkTable (if we pick the simple way), or if we use a GtkTreeView (which can actually show a table) with GtkCellRendererToggle.
2. The painting of the matrix as showed in the specifications seems very hard, and I doubt it worths it. We can easily implement different colors for each row, and users will have to settle for a little border between the columns. If we agree to give up the proposed matrix painting and choose what I suggested, it can be done with GtkTreeView without any special changes, but it will leave the simpler GtkTable our of the question (which is fine with me). 3. Adding the images with the link's color should be a bit tricky, but I assume that it can be done dynamically (by drawing those images after acquiring the link's color, instead of embedding ready bitmaps). 4. Popup window: Part 1 - the curves widget. This can definetly be stolen from the curves tool, no need to work twice. The only needed modification is that we can show some other curves at the background, and that we add min and max arrows.
5. Popup window: Part 2 - switching the tabs. This doesn't seem to bad, especially since we already have similar functionality in the curves tool.

only two things seem problomatic: A treeview widget can't have a bitmap in it's header, And adding the bitmaps as the first row is ugly and probably not the right way to do this. The guys on the GTK mailing list will probably be able to help us out here.
And another questions is, why do we have the same header images at the bottom? Adding a footer to a GtkTreeView isn't possible. Do we really need that? Here i'm defintly sure it's not worth the coding amount that it will require, and I personally find it confusing.

I haven't seen anything that scary in here, but I doubt that I'll have time to touch it in this month. If I implement something like this on a dummy GtkWindow (instead of hacking GIMP's source code, which I don't excel at) as a stand-alone Gtk application, will it help? If so, I'll try to give it a shot.
If you want to see how to use the TreeView and the CellRenderer, the gtk-demo program (which comes with GTK) has a nice example under "Tree View/List Store". The code is very simple and in one of the columns you'll see the Toggle renderer.

for example, one dock needs to hold 2.5 distinct views

I haven't understood that sentence. Can you please explain (or, have I referred to it already)?

Just one offtopic comment: Some of the icons seem very unintuitive - even as an "old" GIMP user I'm still confused by the fifth one from the left. What does it stand for?

~LightningIsMyName

On Wed, Feb 17, 2010 at 8:24 AM, LightningIsMyName wrote:

Hello

On Tue, Feb 16, 2010 at 10:45 PM, Alexia Death wrote: 2. The painting of the matrix as showed in the specifications seems very hard, and I doubt it worths it. We can easily implement different colors for each row, and users will have to settle for a little border between the columns.

http://www.pygtk.org/docs/pygtk/class-gtktreeview.html

Looks like it is possible to disable cell borders (and I think it may be necessary when the cells are small like this-- we want to avoid the borders visually overwhelming the cell content.

If we agree to give up the proposed matrix painting and choose what I suggested, it can be done with GtkTreeView without any special changes, but it will leave the simpler GtkTable our of the question (which is fine with me). 3. Adding the images with the link's color should be a bit tricky, but I assume that it can be done dynamically (by drawing those images after acquiring the link's color, instead of embedding ready bitmaps). 4. Popup window: Part 1 - the curves widget. This can definetly be stolen from the curves tool, no need to work twice. The only needed modification is that we can show some other curves at the background, and that we add min and max arrows.
5. Popup window: Part 2 - switching the tabs. This doesn't seem to bad, especially since we already have similar functionality in the curves tool.

only two things seem problomatic: A treeview widget can't have a bitmap in it's header, And adding the bitmaps as the first row is ugly and probably not the right way to do this. The guys on the GTK mailing list will probably be able to help us out here.
And another questions is, why do we have the same header images at the bottom? Adding a footer to a GtkTreeView isn't possible. Do we really need that? Here i'm defintly sure it's not worth the coding amount that it will require, and I personally find it confusing.

I believe that this kind of measure is usually taken when the number of input variables is anticipated to increase (so perhaps you won't be able to see the top and bottom at the same time)

I haven't seen anything that scary in here, but I doubt that I'll have time to touch it in this month. If I implement something like this on a dummy GtkWindow (instead of hacking GIMP's source code, which I don't excel at) as a stand-alone Gtk application, will it help? If so, I'll try to give it a shot.
If you want to see how to use the TreeView and the CellRenderer, the gtk-demo program (which comes with GTK) has a nice example under "Tree View/List Store". The code is very simple and in one of the columns you'll see the Toggle renderer.

for example, one dock needs to hold 2.5 distinct views

I haven't understood that sentence. Can you please explain (or, have I referred to it already)?

I think I understood it: one dockable must hold a) the matrix,
b) the input mapping, and
c) the output mapping

I thought this was a fairly simple problem in GTK terms.

1. Put the matrix inside its own VBox. Pack it at the start of the window. (This may require nesting inside another VBox.) 2. Put the input and output mapping in another VBox (one they share.) in the following manner:
1. Presets (shared between input and output) 2. Inputs selector
3. Outputs selector
4. Curve display (shared?)
5. 'Inputs' label
6. 'Outputs' label
7. Inputs treeview
8. Outputs treeview
9. 'Show current input'
3. When switching modes, we:
1. If switching to matrix mode, hide the input/output vbox. Show the matrix vbox. Done.
2. If switching away from matrix mode, hide the matrix vbox. 3. If switching to inputs or outputs mode, we need to iterate over the widgets in the VBox; Hide any widgets not specific to the mode in question.
I think there is a widget grouping mechanism in GTK that allows for this kind of distinction.

That is in fact somewhat ugly. There is probably another solution involving packing the input/output widgets on the fly. That would be neater code-wise, and somewhat slower.

I don't know whether the above would argue with the dockable's idea of how tall it ought to be. That might be what Alexia was talking about.

Just one offtopic comment: Some of the icons seem very unintuitive - even as an "old" GIMP user I'm still confused by the fifth one from the left. What does it stand for?

It looks like it's probably meant to be 'random'. I got that from the list, not the graphic, though.