GimpToolGui
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| GimpToolGui | Sven Neumann | 30 Jan 11:13 |
| GimpToolGui | Nathan Carl Summers | 31 Jan 01:23 |
| GimpToolGui | Michael Natterer | 31 Jan 11:41 |
| GimpToolGui | Sven Neumann | 01 Feb 23:50 |
| GimpToolGui | Sven Neumann | 13 Feb 12:05 |
| GimpToolGui | Sven Neumann | 17 Mar 12:32 |
GimpToolGui
Hi Nathan,
when I updated my gimp tree this morning I was surprised to see this commit:
2003-01-30 Nathan Summers
* app/tools/gimptoolgui.[ch]: GimpToolGui, a new class descended from GimpObject to be used to separate GUI from logic. Heavily inspired by GimpDrawTool. Not actually used by anything yet.
Would you mind to explain what you have in mind here? Looks a lot like the GimpDrawTool actually and I'd like to hear about your plans for the tools since of course Mitch and me have a plan as well. I must admit that we haven't told you about it neither but we are actively working towards a massive tool redesign for quite some time now.
Salut, Sven
GimpToolGui
On 30 Jan 2003, Sven Neumann wrote:
Hi Nathan,
when I updated my gimp tree this morning I was surprised to see this commit:
2003-01-30 Nathan Summers
* app/tools/gimptoolgui.[ch]: GimpToolGui, a new class descended from GimpObject to be used to separate GUI from logic. Heavily inspired by GimpDrawTool. Not actually used by anything yet.
Would you mind to explain what you have in mind here?
Not at all. I think I posted this before, but basically, I'd like to have a GimpToolGui class and a GimpToolLogic class, which both inherit from GimpObject. The appropriate GimpToolInfo structure would then have to have the GType for both the gui and logic classes. A GimpTool can then be created that contains a pointer to both a GimpToolGui and GimpToolLogic.
Looks a lot like the GimpDrawTool actually and I'd like to hear about your plans for the tools since of course Mitch and me have a plan as well. I must admit that we haven't told you about it neither but we are actively working towards a massive tool redesign for quite some time now.
I would love to hear what you have in mind.
Rockwalrus
GimpToolGui
Nathan Carl Summers writes:
On 30 Jan 2003, Sven Neumann wrote:
Hi Nathan,
when I updated my gimp tree this morning I was surprised to see this commit:
2003-01-30 Nathan Summers
* app/tools/gimptoolgui.[ch]: GimpToolGui, a new class descended from GimpObject to be used to separate GUI from logic. Heavily inspired by GimpDrawTool. Not actually used by anything yet.
Would you mind to explain what you have in mind here?
Not at all. I think I posted this before, but basically, I'd like to have a GimpToolGui class and a GimpToolLogic class, which both inherit from GimpObject. The appropriate GimpToolInfo structure would then have to have the GType for both the gui and logic classes. A GimpTool can then be created that contains a pointer to both a GimpToolGui and GimpToolLogic.
Hi Nathan,
I don't understand what you want to do here. A GimpTool already *is* a GUI-only object. The separation of a GimpTool holding core and GUI objects is exactly the madness we had in 1.2 and which was just painfully removed to create a class hierarchy of tools.
Remember, in GIMP 1.2 we had for instance the selection_tools which had to allocate a draw_core just to render to the canvas. To acheive this, they somehow had to dispatch the events they got to the draw core object, introducing additional (and error prone) indirection.
Now we have GimpDrawTool the selection tools can inherit from and transparently get the correct drawing behviour.
I don't see how an aggregation of objects can be a more useful abstraction than a derivation that simply has proven to work.
Again, GimpToolGui and GimpToolLogic is IMHO the wrong way, since tools are GUI-only objects (at least they are in 1.3).
Looks a lot like the GimpDrawTool actually and I'd like to hear about your plans for the tools since of course Mitch and me have a plan as well. I must admit that we haven't told you about it neither but we are actively working towards a massive tool redesign for quite some time now.
I would love to hear what you have in mind.
It's more a tool_options redesign. GimpToolOptions will be derived from GimpContext and not have a GimpContext. So it will inherit all (de)serialization stuff. All option values will be GObject properties so the tool options GUI can be created from gimppropwidgets.c (which will be extended to fit all tool option needs).
The draw tool also needs some overhaul, preferrably with an API that deals with vectors and control points instead of drawing. (the drawing API should probably stay there for special porpose stuff that can hardly be abstracted away).
The best thing would IMHO be a GimpDrawTool subclass which abstracts the draw stuff away (using GimpdrawTool's API). Tools are then derived from the subclass and can decide whether to use the drawing or the vectory/control point API. This would also give a smooth transition path instead of breaking everything at once.
But then we would like to get GIMP 1.4 out this year, so a feature freeze (at least for starting fundamental resedigns) should not be too far away.
ciao,
--mitch
GimpToolGui
Hi,
It's more a tool_options redesign. GimpToolOptions will be derived from GimpContext and not have a GimpContext. So it will inherit all (de)serialization stuff. All option values will be GObject properties so the tool options GUI can be created from gimppropwidgets.c (which will be extended to fit all tool option needs).
to get an idea of this concept, you could have a look at the text tool in an uptodate CVS checkout. I've today replaced the old-style ToolInfo memebers with a GimpText object. This is not exactly what we have in mind as the final situation but it already shows how tools will store their parameters as object properties and how the GUI is a view on these properties. The ToolInfo reset method is down to a one-liner and it would be trivial to implement saving and loading of tool parameters now.
The draw tool also needs some overhaul, preferrably with an API that deals with vectors and control points instead of drawing. (the drawing API should probably stay there for special porpose stuff that can hardly be abstracted away).
The best thing would IMHO be a GimpDrawTool subclass which abstracts the draw stuff away (using GimpdrawTool's API). Tools are then derived from the subclass and can decide whether to use the drawing or the vectory/control point API. This would also give a smooth transition path instead of breaking everything at once.
The new text tool will also need some of these so I'd welcome to see such a GimpDrawTool subclass soon.
But then we would like to get GIMP 1.4 out this year, so a feature freeze (at least for starting fundamental resedigns) should not be too far away.
yes, we need to figure out and write down what absolutely needs to be done before 1.4. IMO this is merely getting the text and path tools to work.
Salut, Sven
GimpToolGui
Hi,
Nathan, you didn't answer to our mails but I'd like to continue this discussion until a decision has been made. I don't like the idea of having unused code in CVS, so we should get to a point about gimptoolgui.[ch]. I'll try to pick up the decision where it was left abandoned:
It's more a tool_options redesign. GimpToolOptions will be derived from GimpContext and not have a GimpContext. So it will inherit all (de)serialization stuff. All option values will be GObject properties so the tool options GUI can be created from gimppropwidgets.c (which will be extended to fit all tool option needs).
this basically has happened in the meantime and works quite nicely. There is less code (due to reduced code duplication) that provides more features.
The draw tool also needs some overhaul, preferrably with an API that deals with vectors and control points instead of drawing. (the drawing API should probably stay there for special porpose stuff that can hardly be abstracted away).
The best thing would IMHO be a GimpDrawTool subclass which abstracts the draw stuff away (using GimpdrawTool's API). Tools are then derived from the subclass and can decide whether to use the drawing or the vectory/control point API. This would also give a smooth transition path instead of breaking everything at once.
this is still desirable and should probably be done at least to some extent. I'll see if I can get something started when I add box handling to the text tool. I can imagine that at least the crop tool could use the same code for interactive rectangle handling. We might even consider to use it for the selection tools as well in order to finally get interactively resizeable selections.
However this new code I'm proposing here should IMO not live in a separate object but should be implemented as a GimpDrawTool subclass as Mitch suggested.
Comments?
Salut, Sven
GimpToolGui
Hi,
following up to myself ...
Nathan, you didn't answer to our mails but I'd like to continue this discussion until a decision has been made. I don't like the idea of having unused code in CVS, so we should get to a point about gimptoolgui.[ch].
I'm still waiting for an answer here. My opinion has not changed, so what about yours? I won't wait another month ...
Salut, Sven
