Re: [Gimp-developer] GSoC Questions

[Øyvind Kolås]

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

[Gimp-developer] GSoC Questions

[Isaac Wagner]

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

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 thing is how GIMP might offer a more complicated node editor in
addition to that so that users can perform more involved operations. One
option is to simply force the user to stay within the complicated node
editor once he/she has started playing around with it and once it can no
longer be simplified into a linear stack. But this switching between the
complex view and the linear simplified view could be avoided altogether;
there could be, in the linear operation stack UI in GIMP, a "meta-op"
operation which can be added. The user can "enter into" this meta-op
component (e.g. with a double-click) and within it is a fully-featured
box-and-hose editor. It can have decomposition and non-tree structures, as
long as it has an input and an output, sort of how "groups" work in World
Machine.
It would let the user create a black-box operation of sorts which would fit
nicely into the linear stack, but allow more control and more flexibility
within itself. If someone wanted to work exclusively with a box-and-hose
editor, he/she could just add a single meta-op operation to the stack and
use nothing else, or the user could use a combination of the linear stack
and the complicated node editor, or use no meta-ops and just use the linear
stack, essentially mimmicking how GIMP is used now.

Did I explain that well?

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

Re: [Gimp-developer] GSoC Questions

[Øyvind Kolås]

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

Re: [Gimp-developer] GSoC Questions

[Kevin Cozens]

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.


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

Re: [Gimp-developer] GSoC Questions

[Isaac Wagner]

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

Re: [Gimp-developer] GSoC Questions

[Kevin Cozens]

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

On Wed, Mar 28, 2012 at 1:48 PM, Øyvind Kolås 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

Re: [Gimp-developer] GSoC Questions

[gespert...@gmail.com]

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.
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] GSoC Questions

[Michael Natterer]

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

Re: [Gimp-developer] GSoC Questions

[peter sikking]

Ø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

Re: [Gimp-developer] GSoC Questions

[Przemyslaw Golab]

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
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] GSoC Questions

[Alexandre Prokoudine]

On Wed, Mar 28, 2012 at 1:48 PM, Øyvind Kolås 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

Re: [Gimp-developer] GSoC Questions

[Øyvind Kolås]

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

Re: [Gimp-developer] GSoC Questions

[peter sikking]

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



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

[Gimp-developer] GSoC Questions

[Isaac Wagner]

Hello,

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 
Editorand
World
Machine 
2),
resolving bug 465743 in the process as well as other changes that would
need to happen for the editor to be useful. I would create it as a
standalone tool both for meta-op creation as well as a sandbox for testing
new operations, and design it such that it could potentially be popped into
GIMP as a widget without much modification, either for creating/loading
metaops or for editing the current image's graph itself (I don't know what
the plan is for revealing this to the user). I saw the email about what is
expected of students interested in developing GEGL ops, and I would like to
know if I should send in an identical set of information (the code review,
dummy gegl op patch, etc), or if I should send in something different which
is more tailored to my proposal.

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.

Thank you very much,

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