On 3/6/07, Sven Neumann wrote:

Work on GEGL
Needs a more detailed spec, perhaps even a list of proposed projects.

This is a list showing a todo/roadmap for GEGL in its current state, some of it depends on having a more stable operations API, which is going to be one of
my priorities going forward.

The following three bullet points are things I am thinking about and hope to have done significant work on before the summer starts:

- Caching of intermediate results in the graph - Locking of threaded rendering
- Stabilized operations plug-in API (depends on the two others, as well as general
code cleanup).

The rest are other notable TODO items of interest:

- GeglBuffers that operate over the network. - Network distributed rendering.
- Prototype GEGL backend (operations) that uses GPU instead of CPU for rendering.
- Capabilities to do frequency domain processing. - Bayer demosaicing operations.
- GEGL based Paint core and related operations (brushes, strokes) a minimalistic
paint core was done for a tentative GEGL port of horizon (http://pippin.gimp.org/horizon/) before LGM in 2006.

/Øyvind K.

Sven wrote,

Here are some comments to get us started:

Resource management
This looks like a nice project but perhaps needs to be specified better.

This needs a concept, to start with, which will roll out of the evaluation project. It is more about where do we want to go with brushes, gradients and patterns, than about categorising the current stuff and mechanisms.

Example: I foresee the four basic brushes (pencil, ink (nib), brush, airbrush) being tuned up and specialised as pure algorithm based brushes, with bitmap or vector based brush as a secundairy option.

Create an SDI manager widget
Do we really want to ask someone to waste his/her time with this? It is in my opinion not implementable in a sane way and we would likely not accept the results then. If this is supposed to be kept on the list then we need to agree first that we really want such a thing.

could convert this into the "what is GIMP without an image file?" and "why are the inspectors/toolboxes actually real windows?" project.

Additional file format plug-ins
Shouldn't this perhaps be titled "Improve MNG support"?

is this really part of core-GIMP (as in fits the product vision?)

On-canvas text editing
Nice, but pretty much depends on the port of the display code to Cairo. Perhaps concentrate more on rich text support instead of focusing on the on-canvas editing?

I am not sure on canvas-editing is that desirable, it clashes with the toolbox shortcuts. To be able to style every single character in a piece of text differently is nice though. Well maybe more than nice. Fits the collage and web-pieces scenarios.

We are developing a concept of consolidating multiple text blocks in specialised text layers (not sure if we can get rid of the latter), editable for ever-and-ever, GEGL style.

Search-based menu browser
Nice and probably even reasonably well specified. The student should perhaps do some usability work on this him/herself (with the help of an expert).

now here we got a user interaction can-of-worms. It starts with "why do we need this." There is no easy answer from my side to this first point, the issue is very deep, but it smells to me like flagging usability defeat. Maybe tackle the reasons for this request in another way?

After this has been answered, moving on to actually giving this idea a user-centred concept (vs. technical) is quite a job.

very, very tricky...

Redesign and reimplementation of Save and Export in GIMP. We really need to do this, finally.

concept for this will come out of the evaluation.

SVG brushes
Sounds like a nice project for the SoC.

see resource management. already old-fashioned?

--ps

principal user interaction architect man + machine interface works

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

On 3/6/07, peter sikking wrote:

On-canvas text editing
Nice, but pretty much depends on the port of the display code to Cairo. Perhaps concentrate more on rich text support instead of focusing on the on-canvas editing?

I am not sure on canvas-editing is that desirable

I would kindly suggest you to install some old version of Inkscape where text selectiion could be done via dialog only and rotating/kerning single glyphs wasn't possible at all :)

it clashes with the toolbox shortcuts.

That is a different thing. In my opinion shortcuts need revisiting.

Alexandre

Alexandre wrote:

On 3/6/07, peter sikking wrote:

On-canvas text editing
Nice, but pretty much depends on the port of the display code to Cairo. Perhaps concentrate more on rich text support instead of focusing on the on-canvas editing?

I am not sure on canvas-editing is that desirable

I would kindly suggest you to install some old version of Inkscape where text selectiion could be done via dialog only and rotating/kerning single glyphs wasn't possible at all :)

well, I put that observation immediately in question in the next sentence,that you did not quote. Of course I would not think of doing typography in a separate dialog...

it clashes with the toolbox shortcuts.

That is a different thing. In my opinion shortcuts need revisiting.

now there is a thought-provoking idea, want to discuss it? (off-list if this is a repeatedly-flogged dead horse on this list)

--ps

principal user interaction architect man + machine interface works

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

Sven Neumann writes:

Create an SDI manager widget
Do we really want to ask someone to waste his/her time with this? It is in my opinion not implementable in a sane way and we would likely not accept the results then. If this is supposed to be kept on the list then we need to agree first that we really want such a thing.

Another possible approach which might be more generally useful is tabbed image windows (suggested in bug 121087), combined with moving the toolbox menus into the image window. Then people could dock the toolbox and do everything in one window if they so chose, while others could keep the current separate-windows model.

Additional file format plug-ins
Shouldn't this perhaps be titled "Improve MNG support"?

There are a few other file format plug-ins I've seen discussed here recently, such as GeoTIFF and improved PSD support.

On-canvas text editing
Nice, but pretty much depends on the port of the display code to Cairo. Perhaps concentrate more on rich text support instead of focusing on the on-canvas editing?

Rich text support would be a very useful and fun SOC project.

It might require architectural agreement on how the rich text would be stored in the XCF (which might not be backward compatible). Is that a problem? Or is there already a model for that?

Search-based menu browser
Nice and probably even reasonably well specified. The student should perhaps do some usability work on this him/herself (with the help of an expert).

Peter says this sounds like "flagging usability defeat" and I understand why he says that, but I don't agree. Consider it a type of online documentation. Realistically, any program that offers as many different unconnected functions as GIMP does cannot organize them in a way that will be immediately intuitive to everyone, especially someone who doesn't understand conceptually what the functions do. Consider the person who's following an online tutorial. The tutorial says "Step 12: run HSV Noise." The user may not understand what HSV noise is or why it's needed at this step; they just need to find something matching the name "HSV Noise."

Redesign and reimplementation of Save and Export in GIMP. We really need to do this, finally.

When I saw the header I was hoping this covered things like remembering settings from the various save plug-ins (like, always show JPEG preview, always save exif, never save thumbnail). Turns out that's not covered -- but it would make a nice SOC project that would be very widely useful.

Meta-data plug-in
I would love to see the metadata plug-in finished and the framework used from other file plug-ins. This is crucial for 2.6. Probably up to Raphael to decide if making it a SoC project can help to make this happen.

I think lots of people would like to see this, but everyone is afraid to touch it because the comments in the bug make it clear that Raphael owns the problem and it's presented as a big complicated project. It would be great to see it separated into smaller pieces so other people could attack it.

If a general metadata plug-in is too ambitious, how about a straightforward EXIF and Comment editor? Then if the more general metadata thing ever gets finished, it could replace the simpler one. There's an old exif plug-in on the registry (written by Bill) that might offer a start, though it doesn't currently allow for editing or viewing.

Sven Neumann wrote:

Create an SDI manager widget
Do we really want to ask someone to waste his/her time with this? It is in my opinion not implementable in a sane way and we would likely not accept the results then. If this is supposed to be kept on the list then we need to agree first that we really want such a thing.

Whether to put this on the list depends on how many other projects get proposed and how many different ones students are interested in working on. Having it on the list doesn't obligate us to accept the project. We can always "turn it down" during the voting process.

Plug-in stability effort
The proposal concentrates on possible crashes when plug-ins are passed invalid PDB data. Is that really an issue that is worth working on? It would probably be a lot more worthwhile to improve the PDB API and to add better checks in libgimp.

It is pretty easy to crash many (most?) of the plug-ins when passed bad data from some script. Checks in libgimp can stop GIMP from crashing but will only go so far to stop the plug-in from crashing. I think it would be a worthwhile project to get done at some point. In terms of SoC, it would be a low priority project.

This also raises the question as to whether the plug-in-template can handle being passed bad data or not. If not, it should be updated to show new plug-in authors how to properly write a plug-in to deal with the possibility of receiving bad data.

Additional file format plug-ins
Shouldn't this perhaps be titled "Improve MNG support"?

Are there enough additional file formats to be added that would make this a good candidate for an SoC project? Would it be better to talk about creating additional file format "plug-ins" for GEGL rather than GIMP?

On-canvas text editing
Nice, but pretty much depends on the port of the display code to Cairo. Perhaps concentrate more on rich text support instead of focusing on the on-canvas editing?

A better project regarding text would be to improve the text tools and the API relating to working with text. ie. bugs 122706, 125144, and 169616. On-canvas text editing could be part of the improvements depending on the relatives sizes of the tasks.

Unified UI for scripting
I don't understand this proposal. We provide unified widgets for this in libgimpui and our scripting interfaces use them (well, perhaps Perl-Fu doesn't). So the look and feel should already be pretty much the same. IMO this proposal is based on wrong assumptions. Perhaps what's really needed is a maintainer for perl-fu.

This would be useful. While libgimpui may provide unified widgets it still requires a certain amount of gtk+ coding to build the dialog. For example, pygimp supports radio buttons but Script-Fu does not. If there was a libgimpui routine that took some data with the information needed to build the UI, all language bindings would be able to have dialog boxes without the need to include the gtk+ related calls needed to build a dialog. Adding radio button support to Script-Fu may not be difficult to someone who is used to gtk+ programming but it would be trivial if the dialog box creation was handled by a libgimpui routine.

Unit testing framework
Tests are definitely needed but we might want to make it clearer what exactly needs testing.

[snip]

Benchmarking
The text for this does IMO focus too much on the actual optimization work while it should probably focus more on what we expect from a benchmarking framework. Should probably also include regression testing as it helps a lot to also have a regression test when doing optimizations.

I think the above two items are different aspects of one project. Some of the unit tests could also be used as benchmarks.

On Thu, 2007-03-08 at 01:43 -0500, Kevin Cozens wrote:

It is pretty easy to crash many (most?) of the plug-ins when passed bad data from some script. Checks in libgimp can stop GIMP from crashing but will only go so far to stop the plug-in from crashing. I think it would be a worthwhile project to get done at some point. In terms of SoC, it would be a low priority project.

This also raises the question as to whether the plug-in-template can handle being passed bad data or not. If not, it should be updated to show new plug-in authors how to properly write a plug-in to deal with the possibility of receiving bad data.

On Thursday 08 March 2007 04:12, Sven Neumann wrote: The question is, is this a serious problem at all? If a script is broken and the result is a plug-in that crashes, is that really a problem? A crashing plug-in shouldn't cause further harm and there's a warning that informs the script author that there's a problem. The script can then be fixed.

I fully agree with Sven here. Besides, I can't imagine how this could be something cool, which, IMHO, GSoC stuff should be.

js ->

On Tuesday 06 March 2007 05:03, Sven Neumann wrote:

Hi,

I have read through the list at http://wiki.gimp.org/gimp/SummerOfCode and I think we need to triage the list and try to come up with fewer but more detailed proposals. Here are some comments to get us started:

I added some more ideas to the list on the wiki I think could be feasible as GSoC projects:

* Enhancing Painting with parameter curves
Currently there are quite a few options to use with the paint tools, however, mapping how these options could vary with pressure, tilt, speed, angle of painting is somewhat limited. A complete tabbed dock, where new curves could be added that would map one input variable to paint option could increase several fold the options available to artists. A request for this is drafted in [http://bugzilla.gnome.org/show_bug.cgi?id=119240|bug #119240].
* Categories for brushes, fonts, gradients and palettes
If one adds too many fonts or brushes to GIMP, they quickly become un-manageable through the existing UI. Implementing a way of organizing these resources in sub-categories, in a way that one resource could be present in more than one category (like thrugh the use of tags) in a nice UI could overcome these limitations;

* Font Selector Widget
We need something better. Something that is reusable. Something to turn choosing fonts into a pleasure, rather than a pain. Something to leave the competition on the dust.

And I also came up with this idea, but did not add it to the wiki, because it certainl should have further consideration from the developers, more than the others, to get toeven a rughidea of what will be needed:

* Layer Folders UI

With the upcoming integration of GEGL, there finally will be internal support for layer grouping, even more than one level of it. Aide form the work on the core, we will need a good UI to be the evolution of the current layers dialog. If the GIMP will only allow nested layers, then this should be mroe or less trivial. If GIMP will allow full usage of GEGL, and allow the same layer to be used as source for multiple operations then we will need a brilliant UI.

js
->

On 3/6/07, peter sikking wrote:

it clashes with the toolbox shortcuts.

That is a different thing. In my opinion shortcuts need revisiting.

now there is a thought-provoking idea, want to discuss it? (off-list if this is a repeatedly-flogged dead horse on this list)

Yep, I do. I fact I gave a closer look at shorcuts yesterday and I failed to find toolbox shortcuts clashing with regards to usual text formatting shortcuts. The only one that clashes with usual Ctrl-B and Ctrl-I is 'Edit-Invert' (Ctrl-I). My guess is that changing it to Ctrl-Shift-I to have on-canvas text editing is a minor sacrifice ;-)

Btw, when it comes to text formatting, we should remember that some fonts provide more than usual 4 faces. In an Inkscape feature request's comment one of Inkscape's developers suggested introducing "Make bolder" and "Make lighter" commands. Please bear that in mind when it will be time to design on-canvas text editing ;-)

As for the big picture, I would love to see applications like Scribus, Inkscape and GIMP using consistent shortcuts where applicable. A while ago we did an investigation in our CREATE project:

http://create.freedesktop.org/wiki/index.php/User_interaction_implementations

That may be of some use for you.

Alexandre

Hi,

On 3/9/07, Joao S. O. Bueno Calligaris wrote:

* Categories for brushes, fonts, gradients and palettes

If one adds too many fonts or brushes to GIMP, they quickly become un-manageable through the existing UI. Implementing a way of organizing these resources in sub-categories, in a way that one resource could be present in more than one category (like thrugh the use of tags) in a nice UI could overcome these limitations;

I think that's a very nice idea. In addition to this, a way of organizing resources (brushes, gradients, etc) in collections could be introduced. They could be stored in a single file, so that user could easily share, install or remove many resources in a single step. Using only categories would not solve these problems, especially when number of resources is large. Of course, resources could be organized into sub-categeries inside collections too. And users could have any number of collections installed.

Implementing resource management system during SoC 2007 seems interesting to me. Would it be possible to make such a system work on existing GIMP code (I mean, if such system is implemented, how much of existing code would have to be changed to work with it)?

Thanks

On 3/14/07, Aurimas Juška wrote:

I think that's a very nice idea. In addition to this, a way of organizing resources (brushes, gradients, etc) in collections could be introduced. They could be stored in a single file, so that user could easily share, install or remove many resources in a single step. Using only categories would not solve these problems, especially when number of resources is large. Of course, resources could be organized into sub-categeries inside collections too. And users could have any number of collections installed.

Related entry is: http://bugzilla.gnome.org/show_bug.cgi?id=119874

Alexandre