Alexandre Prokoudine wrote:

Here is the list of proposed changes in 2.6 that Sven asked for:

Tools

- full use of cairo for the select/crop tools (?) - color-neutral toolbox icons that are quick to recognise and work with (?)

The ? character after a name means that exact intentions of that person are unknown.

why are there question marks after these two items?

Let me know if I missed something.

compiled from my own summaries:

* next generation size entries * finishing of: Heal Tool, Sample Points, Foreground Select Tool * Floating Selections
* Alpha Channel
* Layer boundaries

* skipping annoying dialogs by default (individual assessment first)

* solve user request #1, part 1: one menu bar, keep window with menu bar open when no image is open, try floating inspectors

--ps

founder + principal interaction architect man + machine interface works

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

On 09/11/2007, Alexandre Prokoudine wrote:

Layers

- vector layers (Henk Boom?)

I would be glad to continue work on this if there are possibilities of it getting into the main branch in the near future. The only issue is that I would only be available to develop this starting either mid-December or January, as for the next month I'm quite busy with the end-of-semester rush of exams, projects, etc. Is there room for this in the 2.6 timeframe?

Henk Boom

Hi,

On Mon, 2007-11-12 at 08:29 -0500, Henk Boom wrote:

- vector layers (Henk Boom?)

I would be glad to continue work on this if there are possibilities of it getting into the main branch in the near future. The only issue is that I would only be available to develop this starting either mid-December or January, as for the next month I'm quite busy with the end-of-semester rush of exams, projects, etc. Is there room for this in the 2.6 timeframe?

Before we add this, we should get some feedback from the UI team. I wouldn't want to add vector layers without a good specification of the user interaction and user interfaces involved. You can't start before this has happened and I am not sure if we have the resources to get this done in time for 2.6.

Sven

Sven Neumann wrote:

On Mon, 2007-11-12 at 08:29 -0500, Henk Boom wrote:

- vector layers (Henk Boom?)

I would be glad to continue work on this

Before we add this, we should get some feedback from the UI team.

Well, this topic is not so clear cut. There are many factors:

- the relationship with vector apps, especially inkscape. we saw during the user scenario weekend that live update of linked-in svgs as they are saved by inkscape would fit a symbiosis between the two.

- yes, GIMP needs to be able to paint simple shapes, but we do not want to go overboard here with the variety of shapes.

- GEGL vs. vector, where is the dividing line when in the future with GEGL everything added to the image remains modifiable and removable?

Somehow we need to find a balance here where trivial stuff can be done in an obvious way within GIMP, we do not branch out into specialised inkscape territory and come up with something that fits the GEGL architecture.

--ps

founder + principal interaction architect man + machine interface works

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

From: peter sikking

Well, this topic is not so clear cut. There are many factors:

- the relationship with vector apps, especially inkscape. we saw during the user scenario weekend that live update of linked-in svgs as they are saved by inkscape would fit a symbiosis between the two.

- yes, GIMP needs to be able to paint simple shapes, but we do not want to go overboard here with the variety of shapes.

I agree with this completely. The obvious things that GIMP should be able to support are lines, rectangles, and ellipses. The UI for manipulating rectangles and ellipses already exists in GimpRectangleTool, which was created partly with that thought in mind. The UI for handling lines should be much simpler -- as I said earlier, it should be possible to derive this straightforwardly from GimpRectangleTool. The remainder of the UI would consist of edge/fill options, which would presumably go into the tool options. A full-fledged vector layers capability introduces a lot of UI questions, which, as you say, might not even be desirable to support, but for the most basic things, it should all be reasonably straightforward. I can't tell you how many times I've needed to create a simple arrow pointing to something, and been annoyed to have to hack around to do it.

The idea of invoking Inkscape to edit SVG layers makes a lot of sense, and in fact I have suggested this myself in the past -- but, as Sven pointed out, it is very tricky to pull off such an interaction without it feeling awkward and creating a large potential for breakage. This is certainly nothing that could be done in the hoped-for 2.6 time frame.

Best wishes,

-- Bill

______________ ______________ ______________ ______________ Sent via the CNPRC Email system at primate.ucdavis.edu

On 12/11/2007, peter sikking wrote:

Well, this topic is not so clear cut. There are many factors:

- the relationship with vector apps, especially inkscape. we saw during the user scenario weekend that live update of linked-in svgs as they are saved by inkscape would fit a symbiosis between the two.

This use doesn't sound like it even requires vector layers to work. The only advantage of vector layers is that it is easy to edit them from within GIMP, which isn't so important if you are editing them only in Inkscape. I agree that this would indeed be a very cool feature =).

- yes, GIMP needs to be able to paint simple shapes, but we do not want to go overboard here with the variety of shapes.

Right now the layers operate on arbitrary paths, so any shape which you can make a path out of can be made into a vector layer. This makes them very powerful, but I can see that you would want special cases for a couple of simple shapes. You can get a rectangle using the rectangular select tool, then converting the selection to a path, but when you go to edit the path afterwards it won't be constrained to a rectangular shape anymore. Also, going through selections isn't very intuitive.

- GEGL vs. vector, where is the dividing line when in the future with GEGL everything added to the image remains modifiable and removable?

I'm not sure what the question here is, wouldn't vector layers only help this philosophy? As far as I understand their purpose is to avoid having to do permanent "stroke path" operations, instead making the shape easily modifiable and impermanent.

Somehow we need to find a balance here where trivial stuff can be done in an obvious way within GIMP, we do not branch out into specialised inkscape territory and come up with something that fits the GEGL architecture.

I see vector layers as being a replacement for most uses of the current stroke/fill path. It accomplishes the same thing, but has the advantage that you don't have to keep re-doing it when the path is changed, as it updates automatically.

I agree with what Sven said about waiting for UI design though, as to develop without waiting for specs nearly always leads to wasted effort.

Henk Boom

On Nov 13, 2007 6:16 AM, Henk Boom wrote:

On 12/11/2007, peter sikking wrote:

- GEGL vs. vector, where is the dividing line when in the future with GEGL everything added to the image remains modifiable and removable?

I'm not sure what the question here is, wouldn't vector layers only help this philosophy? As far as I understand their purpose is to avoid having to do permanent "stroke path" operations, instead making the shape easily modifiable and impermanent.

Somehow we need to find a balance here where trivial stuff can be done in an obvious way within GIMP, we do not branch out into specialised inkscape territory and come up with something that fits the GEGL architecture.

I see vector layers as being a replacement for most uses of the current stroke/fill path. It accomplishes the same thing, but has the advantage that you don't have to keep re-doing it when the path is changed, as it updates automatically.

When it comes to SVG integration with other applications, a layer tree or similar based on GEGL would probably automatically support this not much differently from how text layers would be supported, and the SVG-loading operation for doing so is already in place.

I plan to make an experimental stroke-history based paint engine on top of GEGL. Doing experiments with this is soon becoming possible since the caching infrastructure I've been adding to GEGL in the last half year seems to be getting solid enough. This would work by storing stroke path, pressure, tilt etc information along with the brush settings for every stroke in a sequence of operations that apply paint/dabs to the underlying drawable. Each ops would contain it's own cache to speed up the application of another stroke on top (this per-node/op caching infrastructure is getting it's final polish for the next GEGL release). This will allow editing the properties of the strokes of a regular paint tool, and even removing an individual stroke after it has been made. The interesting question to be answered when a prototype is mocked up is whether it will be responsive enough for interactive painting.

/Øyvind K.