Re: [Gimp-developer] GSoC Questions

Okay, I think I have a good idea of what everyone is thinking. First to clarify to Peter: my initial plan was to make a standalone tool for manipulating and experimenting with GEGL, but, as Michael wrote, designed as a tight GTK+ widget so that it could potentially be plugged into GIMP down the road. However, I respect your position as the one in charge of the UI (I believe) and I think from reading your blog post, comments, and replies in this thread, that I have a good idea of what you want and why. As a casual GIMP user for at least a few years, I think that a nodal editor (yes, a boxes and hoses one) would be really really cool. It would force us to rethink the way we manipulate images and could make some things much easier which were previously a pain in the ass to do. But I also understand that your number one priority with the shift to GEGL is to keep, on the surface, everything as simple and straightforward to use as possible. In the end, the primary users of GIMP are the users. 90% of them won't need to know and won't care about the graph infrastructure. It would be silly to have to design even a small graph to do something as simple as a contrast and a hue shift on a newly developed photograph when it could be done just as well with a few button clicks, as it is now.

I would still like to work on a "boxes and hoses" editor. I really would. But if it isn't appropriate for SoC (and I understand that for the SoC, the top priority really is practicality), then I would love to work on something a bit closer to the end product that Peter has in mind. It really reminds me of the flow of Autodesk Inventor, if any of you have ever used it, and it works quite well. I recommend taking a look if you can. I do want to work on something to do with infrastructure and "the bigger picture." If you think there is a place for a SoC student to get going on the operation stack interface and associated infrastructure, I would love to talk more about it. I really do love GIMP and I'm excited about where it's going. I picked you guys out of the SoC mentor list because this is a project, either on the 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.

And if I do something more practical for SoC to help get the new infrastructure into the hands of real users sooner than later, I can see myself continuing on and working on a more experimental editor down the road after SoC is over. It's a prospect that gets me giddy, but I respect that it isn't the top priority.

On Wed, Mar 28, 2012 at 8:57 AM, Michael Natterer <mitch gimp org> wrote:
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)


> > 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
> on interaction architecture
> _______________________________________________
> gimp-developer-list mailing list
> gimp-developer-list gnome org

gimp-developer-list mailing list
gimp-developer-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]