Isaac Wagner wrote:

My name is Isaac and I'm interested in participating in GSoC this year with GIMP. I was discussing project ideas in IRC the other day and I was pointed to this issue in bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=465743. For my proposal I would like to create a node-editor (similar to Unity's Shader Editor and World Machine 2),

as I have blogged here:

a boxes and hoses editor will never be the _main_ interaction in GIMP for non-linear editing.

I certainly would hate to see it in any form (even experimentally) be integrated in GIMP before the (the start of) the actual main interaction is. doing this would send completely the wrong signal to the whole user community what non-linear working in GIMP is all about.

however, if we think a bit further, we can see that the interaction that I am outlining in the blogpost is nothing more than an organised version of the boxes and hoses graph.

starting work on that as a project would contribute to advancing GEGL integration in GIMP.

I would be interested in hearing from some other developers (it was pippin who my project could have potential) about whether this would actually be useful (and thus acceptable for GSoC) to GIMP and GEGL.

I can only really hope, that he meant that in the way I outlined above. because the other way around it is a very good way to derail interaction work on GIMP.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

On Wed, Mar 28, 2012 at 9:30 AM, peter sikking wrote:

I certainly would hate to see it in any form (even experimentally) be integrated in GIMP before the (the start of) the actual main interaction is. doing this would send completely the wrong signal to the whole user community what non-linear working in GIMP is all about.

however, if we think a bit further, we can see that the interaction that I am outlining in the blogpost is nothing more than an organised version of the boxes and hoses graph.

starting work on that as a project would contribute to advancing GEGL integration in GIMP.

Doing that work is unsuited for a student right now and we do desire proper graph based editing for GEGL. We do really want a proper graph based editor for GEGL graphs, whether it has to do with GIMP or not. If we have one we would use it work debugging of the GEGL integration in GIMP. It would also be a way to edit and create new GEGL operations and filters that can be used by GIMP in the brave new world you outline that haven't been fully specified yet. Such a graph editing tool would be developed outside the GIMP tree first as a stand-alone tool. If it works well it would likely become the new default binary UI of GEGL itself - as well as become the core of a graph editing widget that could be used within GIMP for doing advanced things that are difficult to achieve in a hierarchical model (these are few, but one of them is decomposing to a given color model, filtering the components separately; and then recomposing the components.)

I can only really hope, that he meant that in the way I outlined above. because the other way around it is a very good way to derail interaction work on GIMP.

When it comes to derailing, you should read up on the topic of Stop Energy. We want and need people that are capable of prototyping and experimenting with new and novel ways of doing interactions, be that inside branches of GIMP or as external tools and prototypes built on top GEGL. Researchers doing experimental UI prototypes have used GIMP in the past, sometimes it results in research prototypes where the interactions are interesting but the code is unusable, and sometimes it can result in code that can be integrated in mainline GIMP. We cannot enforce that globally all people pulling the future potential of GIMP follow a waterfall development model.

/yvind K.

The future is already here. It's just not very evenly distributed
                        -- William Gibson
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Wed, Mar 28, 2012 at 1:48 PM, yvind Kols wrote:

Doing that work is unsuited for a student right now and we do desire proper graph based editing for GEGL. We do really want a proper graph based editor for GEGL graphs, whether it has to do with GIMP or not.

*cough* mathmap *cough* :)

Alexandre Prokoudine http://libregraphicsworld.org

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

I'm not against stack or node UI because I want to see them both implemented, but in this discussion I agree with Øyvind Kolås.

Stack UI documentation is not finished, for example how to do decomposing to a given color model, multiple file export/save and other operations that I also pointed out in comments on mentioned blog post.

Node based UI is hard and a bit slow to manage, but in big and complex operations it's much easier to work with, comparing to stack based approach.

Stack based UI is clean and organized as a UI, so it's nice for fast and not so
complex work, but with bigger project it creates levels of overloaded options
that are hard to READ because of layered nature. Why, because stack has only simple hierarchy. You can't see how it connects with other layers if their dependency on each other is not simple "do one thing
at the time". Just like decomposing one layer it has many outputs, for RGB there
are three, so at the same time there are 3 different operations, that are independent from each other. If there is many operations like that it ends up hard
for human being to track all of them.

I'm sure node based UI could be designed good and in my opinion it should be
part of stack based approach documentation from the beginning, so they could
co-operate in future seamlessly.

-- n-pigeon

yvind wrote:

peter wrote:

I certainly would hate to see it in any form (even experimentally) be integrated in GIMP before the (the start of) the actual main interaction is. doing this would send completely the wrong signal to the whole user community what non-linear working in GIMP is all about.

however, if we think a bit further, we can see that the interaction that I am outlining in the blogpost is nothing more than an organised version of the boxes and hoses graph.

starting work on that as a project would contribute to advancing GEGL integration in GIMP.

Doing that work is unsuited for a student right now and we do desire proper graph based editing for GEGL. We do really want a proper graph based editor for GEGL graphs, whether it has to do with GIMP or not.

yes, proper graph based editing for for GEGL. so why is then a GIMP SoC slot, a scarce good, spent on it? I can see how it helps GIMP to implement GEGL ops, I am fully in favour of that.

If we have one we would use it work debugging of the GEGL integration in GIMP. It would also be a way to edit and create new GEGL operations and filters that can be used by GIMP in the brave new world you outline that haven't been fully specified yet. Such a graph editing tool would be developed outside the GIMP tree first as a stand-alone tool. If it works well it would likely become the new default binary UI of GEGL itself - as well as become the core of a graph editing widget that could be used within GIMP for doing advanced things that are difficult to achieve in a hierarchical model (these are few, but one of them is decomposing to a given color model, filtering the components separately; and then recomposing the components.)

we have discussed working on components, and it is also in the comments of the blogpost. this is something that GIMP will support very naturally (comparable how GIMP supports working with selections instead of working with masking ops in the graph: same technical result, but with user interaction designed for the domain of GIMP, instead of visual programming).

I can only really hope, that he meant that in the way I outlined above. because the other way around it is a very good way to derail interaction work on GIMP.

When it comes to derailing, you should read up on the topic of Stop Energy. We want and need people that are capable of prototyping and experimenting with new and novel ways of doing interactions, be that inside branches of GIMP or as external tools and prototypes built on top GEGL. Researchers doing experimental UI prototypes have used GIMP in the past, sometimes it results in research prototypes where the interactions are interesting but the code is unusable, and sometimes it can result in code that can be integrated in mainline GIMP. We cannot enforce that globally all people pulling the future potential of GIMP follow a waterfall development model.

compare this:

Mitch is the overall software architect of GIMP and I am sure that if a proposed SoC project would experimentally change the technical architecture in such a way that it is certain that it will never make it in a GIMP release, he would:

a) point that out; b) if needed, veto it.

of course if someone wants to start his/her own project on the GIMP codebase to see where it goes, (s)he is Free to do so. if asked Mitch would still point out a) and b) above.

now, the situation is that I am the interaction architect of GIMP, and a SoC interaction project is proposed that is is certain that it will never make it in a GIMP release.

I think it is my duty to:

a) point that out; b) if needed, veto it.

no?

of course if someone wants to start his/her own project creating experimental tools, to see where it goes, (s)he is Free to do so (btw: copying somebody else boxes and hoses editor does not count experimental, does it?). and since the topic hac come up, and it is 100% interaction, about the most important direction in UI that GIMP is going to take in the near future, I do point out a) and b) above.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Wed, 2012-03-28 at 14:01 +0200, peter sikking wrote:

Øyvind wrote:

peter wrote:

I certainly would hate to see it in any form (even experimentally) be integrated in GIMP before the (the start of) the actual main interaction is. doing this would send completely the wrong signal to the whole user community what non-linear working in GIMP is all about.

however, if we think a bit further, we can see that the interaction that I am outlining in the blogpost is nothing more than an organised version of the boxes and hoses graph.

starting work on that as a project would contribute to advancing GEGL integration in GIMP.

Doing that work is unsuited for a student right now and we do desire proper graph based editing for GEGL. We do really want a proper graph based editor for GEGL graphs, whether it has to do with GIMP or not.

yes, proper graph based editing for for GEGL. so why is then a GIMP SoC slot, a scarce good, spent on it? I can see how it helps GIMP to implement GEGL ops, I am fully in favour of that.

Because GIMP's and GEGL's SoC slots are exactly the same, and having whatever node based SoC stuff done as UI on top of GEGL is a good thing, whether we want that for GIMP or not. Actually, GIMP is now becoming the UI for GEGL, and since we don't want UI experiments in GIMP (I fully agree with you here), we must do them as another view on GEGL. Having proper GEGL-GTK+ widgets nicely done will benefit GIMP in the end, and nobody is asking for using them in GIMP before they are suited.

So everybody please calm down, we are not turning GIMP into some experimental node editor any time soon.

(I think I answered the rest of this mail too)

Regards, Mitch

If we have one we would use it work debugging of the GEGL integration in GIMP. It would also be a way to edit and create new GEGL operations and filters that can be used by GIMP in the brave new world you outline that haven't been fully specified yet. Such a graph editing tool would be developed outside the GIMP tree first as a stand-alone tool. If it works well it would likely become the new default binary UI of GEGL itself - as well as become the core of a graph editing widget that could be used within GIMP for doing advanced things that are difficult to achieve in a hierarchical model (these are few, but one of them is decomposing to a given color model, filtering the components separately; and then recomposing the components.)

we have discussed working on components, and it is also in the comments of the blogpost. this is something that GIMP will support very naturally (comparable how GIMP supports working with selections instead of working with masking ops in the graph: same technical result, but with user interaction designed for the domain of GIMP, instead of visual programming).

I can only really hope, that he meant that in the way I outlined above. because the other way around it is a very good way to derail interaction work on GIMP.

When it comes to derailing, you should read up on the topic of Stop Energy. We want and need people that are capable of prototyping and experimenting with new and novel ways of doing interactions, be that inside branches of GIMP or as external tools and prototypes built on top GEGL. Researchers doing experimental UI prototypes have used GIMP in the past, sometimes it results in research prototypes where the interactions are interesting but the code is unusable, and sometimes it can result in code that can be integrated in mainline GIMP. We cannot enforce that globally all people pulling the future potential of GIMP follow a waterfall development model.

compare this:

Mitch is the overall software architect of GIMP and I am sure that if a proposed SoC project would experimentally change the technical architecture in such a way that it is certain that it will never make it in a GIMP release, he would:

a) point that out; b) if needed, veto it.

of course if someone wants to start his/her own project on the GIMP codebase to see where it goes, (s)he is Free to do so. if asked Mitch would still point out a) and b) above.

now, the situation is that I am the interaction architect of GIMP, and a SoC interaction project is proposed that is is certain that it will never make it in a GIMP release.

I think it is my duty to:

a) point that out; b) if needed, veto it.

no?

of course if someone wants to start his/her own project creating experimental tools, to see where it goes, (s)he is Free to do so (btw: copying somebody else boxes and hoses editor does not count experimental, does it?). and since the topic hac come up, and it is 100% interaction, about the most important direction in UI that GIMP is going to take in the near future, I do point out a) and b) above.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Just a quick note, since it has been discussed before at Peter's blog and it's clear the direction that GIMP will take regarding its UI: I disagree when Peter says that a nodal UI works as a form of visual programming and sort of questions its validity for an application like GIMP. These interfaces have been used successufly in CG and digital compositing for years and probably the best example of that is Nuke, that allows all the features GIMP has (and much more) not only for still frames but for sequences.
Nuke has become a de-facto industry standard for high-end digital compositing and it actually helps complex projects to be organized and manageable. It's not "experimental" and It's not the spaghetti mess most people think nodal compositing is.
This is a simple example (there are dozens) showing how transparent a nodal UI can be.
http://www.youtube.com/watch?v=EMXZ5RWYejU Notice that operations are created from tool icons and it doesn't necessarily take to manually connect nodes. I agree that creating stuff from individual nodes could be cumbersome, but for editing a node tree is a more logical way to visualize and navigate and it's easier to organize (using groups and area containers) than a linear stack, plus all the flexibility it gives when it comes to re-using stuff by simply plugging existing nodes together. As an everyday GIMP user, I'd welcome a nodal UI dialog as an extension to the current UI. The idea of a node-tree window on a second screen makes a lot of sense to me.

just my 2 cents.

On 12-03-28 06:44 AM, Alexandre Prokoudine wrote:

On Wed, Mar 28, 2012 at 1:48 PM, yvind Kols wrote:

Doing that work is unsuited for a student right now and we do desire proper graph based editing for GEGL. We do really want a proper graph based editor for GEGL graphs, whether it has to do with GIMP or not.

*cough* mathmap *cough* :)

You can also see nodal (or box and hose) editing systems in GIMP and in Shaderman.

Cheers!

Kevin.

http://www.ve3syb.ca/           |"Nerds make the shiny things that distract
Owner of Elecraft K2 #2172      | the mouth-breathers, and that's why we're
                                 | powerful!"
#include  |             --Chris Hardwick
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

On 12-03-28 11:29 AM, Kevin Cozens wrote:

You can also see nodal (or box and hose) editing systems in GIMP and in Shaderman.

Ack! Typo. I meant to say Blender and Shaderman. Seems my brain and my fingers weren't quite in sync this morning when I wrote the above.

On Wed, Mar 28, 2012 at 6:32 PM, Isaac Wagner wrote:

GIMP side or the GEGL side or somewhere in-between, that I am genuinely enthusiastic to be a part of. I want to work on something that you actually need.

GIMP will in the 2.10 cycle depend a _lot_ more on GEGL, actually by the end of the cycle everything you normally do in GIMP should be powered by GEGL. Creating test cases, verifying that GEGL behaves correctly as well as developing new operations is easier with a standalone tool. GEGL used to have a GUI sandbox for such experiments that used a tree based representation with clones (see http://pippin.gimp.org/tmp/gegl-foo/ for some screen shots). Such a tool that permits more direct manipulation and testing of the concepts of GEGL (which is a processing graph of nodes) permits faster developer feedback as well as making it easier to construct test cases for verifying the behavior of GEGL - this is something that increases in importance as GEGL is adopted for the core parts of GIMP.

/yvind K.

The future is already here. It's just not very evenly distributed
                        -- William Gibson
http://pippin.gimp.org/              http://ffii.org/
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Thu, Mar 29, 2012 at 12:08 AM, Isaac Wagner wrote:

http://pippin.gimp.org/tmp/gegl-foo/ for some screen shots). Such a tool that permits more direct manipulation and testing of the concepts of GEGL (which is a processing graph of nodes) permits faster developer feedback as well as making it easier to construct test cases for verifying the behavior of GEGL - this is something that increases in importance as GEGL is adopted for the core parts of GIMP.

If I have the support of those in charge of GSoC, and this project would be appropriate for GSoC, I'll work on a detailed proposal outlining UI ideas, features, etc. My original intent was, as you said, for the tool to be useful in testing GEGL and designing independent meta-ops and perhaps eventually serve as a base for integration into GIMP.

I had an idea this morning and I'm curious what you all think of it. I fully understand the appeal of the simplified linear operation stack. The tricky >snip<

Figuring out how it fit's into the future UI vision of GIMP is outside the scope of GSOC, though pondering some such possibilities together with Peter Sikking might be relevant. It is better to consider this a stand-alone development and debugging tool that would be planned and developed in a way that possibly allows reusing it as a component if desired later.

/
--

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list