Re: [Gimp-developer] GSoC Questions

[Michael Natterer <mitch gimp org>]

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