Re: [Gimp-developer] GSoC Questions

[peter sikking <peter mmiworks net>]

Ø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