On 3/27/10, Jenny wrote:

But as far as I know, gegl has had a GUI.

Not any more :)

Alexandre

On 03/27/2010 12:26 PM, Jenny wrote:

GEGL shipped an GUI application for test, with which user takes many OPs on the default image. But this application can not load images.

I want to write a user-friendly GUI for GEGL as my GSoC project. I think this application should provide many drag-able "block"s, where each block assigns an operation. User drags blocks and connects them to process image. Kinda like the simulink (http://en.wikipedia.org/wiki/Simulink).

Expecting feedback.

IMHO, GEGL should only be a great image processing library, not an image processing library + an advanced UI tool. Also being the latter adds considerable maintenance and development burdens, making it harder to focus on the core functionality. It'd be fine to create an external project that has a GEGL dependency though, of course.

/ Martin

Jenny wrote:

GEGL shipped an GUI application for test, with which user takes many OPs on the default image. But this application can not load images.

I want to write a user-friendly GUI for GEGL as my GSoC project. I think this application should provide many drag-able "block"s, where each block assigns an operation. User drags blocks and connects them to process image. Kinda like the simulink (http://en.wikipedia.org/wiki/Simulink ).

Expecting feedback.

the graph/boxes and hoses/visual programming metaphor will one day be in GIMP, because we have 'researching cutting edge image algorithms' in the vision.

but it is certainly not how I see anybody creative or production working. that is much more hands-on, a continuation of the way you see right now in GIMP: hand-tools, a free combination of selections + filters/operations + layer techniques.

the graph thing can be added _after_ all of these normal things have been adapted to GEGL.

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On 03/27/2010 01:25 PM, Jenny wrote:

Thanks Matin's feedback. :)

Another question: could developing a stand alone but gegl-based application be a GSoC project?

I'm not a GSoC authority, but my guess is "no".

/ Martin

On Sat, 2010-03-27 at 21:40 +0800, Jenny wrote:

But... it is on the idea list, names "Basic gegl based paint tool".

It's on the idea list for gimp - i.e. a gimp paint tool that's based directly on gegl, I would think was meant. Maybe one that lets you apply gegl operations to a brush-sized area as yo u"paint", rather like brushes in Krita (a KDE drawing/painting program).

There's a certain amount of flexibility around the GIMP projects, but I rather think they do actually have to involve GIMP :-)

Liam

On Mon, Mar 29, 2010 at 6:34 PM, Jenny wrote:

Here is my draft proposal
https://docs.google.com/Doc?docid=0ARZjTPkuA386ZGRmY3JteG1fOTRoZmJ4cm1keg&hl=en thanks,
Jenny

No, that was not even in the same ballpark as the idea. Integration with gimp was said to be optional but the project is for a paint tool in gimp sense. Like paintbrush tool or airbrush tool using gegl as the back end. The aim of this idea is the creation of that back end with optional GIMP integration. That back end should support paths with outputs and rendering of those paths either using stamping of a bitmap or some other sort of creation of a stroke(for example the kind ink tool in gimp uses now). Essentially an implementation of paint core in gegl.

On Mon, Mar 29, 2010 at 5:41 PM, Alexia Death wrote:

On Mon, Mar 29, 2010 at 6:34 PM, Jenny wrote:

Here is my draft proposal
https://docs.google.com/Doc?docid=0ARZjTPkuA386ZGRmY3JteG1fOTRoZmJ4cm1keg&hl=en thanks,
Jenny

No, that was not even in the same ballpark as the idea. Integration with gimp was said to be optional but the project is for a paint tool in gimp sense. Like paintbrush tool or airbrush tool using gegl as the back end. The aim of this idea is the creation of that back end with optional GIMP integration. That back end should support paths with outputs and rendering of those paths either using stamping of a bitmap or some other sort of creation of a stroke(for example the kind ink tool in gimp uses now). Essentially an implementation of paint core in gegl.

Note that there already is code in GEGL that could serve as a starting point/inspiration that does stroking of paths using bitmaps/potato stamps with a procedurally generated brush, as well as a minimal experiment testing it. Since performance of GEGL based things in GIMP is going to be hampered by the lack of native use of GeglBuffers it probably makes sense to also be able to experiment with such new infrastructure outside GIMP.