> > 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
>
>
>
