Von: Dave Neary

Hi all,

I have registered the GIMP as a mentoring organisation for the Summer of Code (I had been in contact with Google before the announcement), we should be up on the page over the next couple of days.

It would have been nice to know this a bit earlier. As you can see in the other thread, we were already preparing stuff...

Michael

What about "official" Red eye plug-in, possibly with SIOX, as Sven suggested? Also some kind of healing brush can be useful.

On Tue, Apr 18, 2006 at 10:04:27AM +0200, Dave Neary wrote:

I have registered the GIMP as a mentoring organisation for the Summer of Code (I had been in contact with Google before the announcement), we should be up on the page over the next couple of days.

Maybe there's a big chunk of work in GEGL nobody dared to do yet?

Bye,

Tino.

Dave Neary wrote:

I have registered the GIMP as a mentoring organisation for the Summer of Code (I had been in contact with Google before the announcement), we should be up on the page over the next couple of days.

Thanks Dave for taking the initiative. Does this mean that you are volunteering to be the "coordinator", as described in the SoC FAQ?

Our next requirement is a list of project ideas for people to take on - these should be:
- Suitable for an advanced student, for 10 weeks work (1/2 weeks planning, 4 weeks coding, 2/4 weeks refining, 1/2 weeks for report) - Have a mentor associated
- Be on a publicly accessible web-page (the wiki will do) - Be interesting and useful (perhaps it goes without saying, but "document the API of library X" would not qualify)

We should settle on half-a-dozen well-defined project ideas, because having too many choices leads to brain freeze, and people who want to work with GIMP but don't like any of the suggestions are always free to come up with ideas of their own. And it would be nice to put them on a page on the developer web site as opposed to the Wiki.

The way I see these projects being integrated into CVS is: [. . .]

I think this timeline is unrealistic, and that it would be better to aim for the results of the student projects being incorporated in the 2.4 release.

Here are some suggestions I have heard that I like. without credit to the people who first suggested them:

1) Color management. Sven and others have made a start on this, but quite a bit more needs to be done.

2) Resource management. Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, which greatly limits the number of items a user can deal with. People love to make collections of things, so this would greatly enhance the user experience.

3) System for saving presets for plug-ins. Sven and Mitch have been clearing the way for this, but there is good bit still to do to make it happen.

4) Vector layers and tools to manipulate them -- allowing adjustable rectangle and ellipse shapes, lines with arrow, etc.

5) Create a manager widget that will allow all of GIMP's windows to be contained in a single parent window, as requested hundreds of times by Windows users. (This would be optional, not forced on people who don't want it.)

-- Bill

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

On Tue, 18 Apr 2006, William Skaggs wrote:

Date: Tue, 18 Apr 2006 09:41:40 -0700 From: William Skaggs
To: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] GIMP and Google SoC

5) Create a manager widget that will allow all of GIMP's windows to be contained in a single parent window, as requested hundreds of times by Windows users. (This would be optional, not forced on people who don't want it.)

Is there a good reason why something this would need to be done as a whole new project?

Gimpshop uses:
"Gimp Background window version 2.1, Copyright (C) 2004"

As far as I can tell is what is less flatteringly but better know as the GIMP Deweirdifyer since the source archive for it is labelled BackgroundWindow.

Is there some techincal reason making it impractical to integrate this instead?

Sincerely

Alan Horkan

Inkscape http://inkscape.org Abiword http://www.abisource.com
Open Clip Art http://OpenClipArt.org

Alan Horkan wrote:

Is there some techincal reason making it impractical to integrate this instead?

- MS-Windows-only
- who will maintain it afterwards?

Also, some users have complaint about stability issues after installing this plug-in. This is something that could be handled in the SoC project, however.

HTH,
Michael

Hi,
dneary@free.fr (2006-04-18 at 1004.27 +0200):

I had some ideas:
- Scripting languages and the GIMP - work on ruby or python bindings

What is missing in python one? About more langs... well, it is nice, but it is also nice to have things that are completly finished instead of many half done.

- Plug-ins: Save for web for example (too small to be a project, but could be part of one)

- Reorg the save workflow so there is only the save dialog and then the "per format" dialog, which should include the current export (flatten or save current drawable or as anim, apply masks or discard, etc) and format details (compression, comments, sampling ratio...).

- Effect layers - I think this is fairly straightforward with the GIMP as it is, it's a nice chunk of a project, and would be a nice feature for users

If you mean what PS calls adjustment layers, we were talking about this and layer groups in IRC yesterday. Running filters could be a bit more tricky (what about multiple drawable input?) specially as some are way slower than composing a bunch of layers in a slight different order than current (groups) and with other extra formulas (adj) that are still per pixel.

- Vector layers (or replace GFig plug-in by Inkscape plug-in?)

Layers sounds better as it allows "in line" work.

Related would be: Non ortogonal guide system, useful for perspective works. Which could then be grouped to:

- Integrate the paths more into the system (vlayers, snap to vectors, auto fill and stroke after changes...) and increase the tools they provide (polygons, circles, "sun rays" shape for perspective...), instead of just being something you load to and save from selections or use a helper for stroking.

- Tools - shapes, intelligent eraser?

If you have vectors, and shapes means "make rectangle", shapes becomes a bit mot, as it is non editable.

- Improved brush system: make system use pixmaps and svg as source for the editable brushes (instead of some geometrical shapes only), better interpolation of strokes (specially mouse), randomization of all kind of aspects (position, size, colour, opacity...), pressure curve remapping for tablets and full strokes, editable settings for GIH (while loaded, no save and refresh "dance"), make airbrush behave more airbrushy ...

- Healing tool: like clone tool with extra steps and special blend mode.

A different thing:

- Improve the save session support. Currently dock order and other details are remembered. Remembering dettached menus and open/close of expander widgets would be nice too, so would be values for plugins.

GSR

Hi,

"William Skaggs" writes:

Here are some suggestions I have heard that I like. without credit to the people who first suggested them:

1) Color management. Sven and others have made a start on this, but quite a bit more needs to be done.

Color management is supposed to be in the 2.4 release so it should be finished before the SoC starts.

2) Resource management. Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, which greatly limits the number of items a user can deal with. People love to make collections of things, so this would greatly enhance the user experience.

That sounds like a reasonable project to me.

3) System for saving presets for plug-ins. Sven and Mitch have been clearing the way for this, but there is good bit still to do to make it happen.

We definitely want this to happen right after 2.4. I am not sure if it makes sense to declare an absolut must-have as a SoC project. IMO We should rather try to come up with some tasks that would be nice to have but that we can easily live without.

4) Vector layers and tools to manipulate them -- allowing adjustable rectangle and ellipse shapes, lines with arrow, etc.

Fine with me.

5) Create a manager widget that will allow all of GIMP's windows to be contained in a single parent window, as requested hundreds of times by Windows users. (This would be optional, not forced on people who don't want it.)

I don't think we will need this when we are done with the changes to the window handling that have been started in CVS. It also doesn't fit into the long-term plan. We could however try to make window handling a SoC project but I am not sure how well suited that would be.

Sven

Hi,

Dave Neary writes:

- Scripting languages and the GIMP - work on ruby or python bindings

Another language binding would indeed be a nice project and the Python binding could also be improved. What's Yosh's opinion on the latter?

- Plug-ins: Save for web for example (too small to be a project, but could be part of one)

IMO "Save for Web" is complex enough for a project.

- Effect layers - I think this is fairly straightforward with the GIMP as it is, it's a nice chunk of a project, and would be a nice feature for users

How is this fairly straightforward with the current architecture? I would rather say that it is currently almost impossible to implement sanely.

1. Feature freeze 2.4 soon (before the end of May), for release during the Summer
2. Create SoC branches for integration of the SoC projects 3. After release of 2.4, merge successful projects to HEAD, and release 2.5.0 (GIMP-SoC) in September. Let the branch harden for a month or so, and release 2.6.0 off that.
4. Start gegl integration on a branch, if needs be, and integrate that work into HEAD straight after the release of 2.6.0.

I don't see why we should wait with GEGL integration. There are people waiting for the 2.4 release to start this work. It would be a huge mistake to postpone this. The amount of GEGL integration that is planned for the next release is small anyway and is unlikely going to delay the 2.6 release.

Sven

Hi,

Alexander Rabtchevich writes:

What about "official" Red eye plug-in, possibly with SIOX, as Sven suggested? Also some kind of healing brush can be useful.

Yes, I think that a decent Red Eye plug-in would be nice project. Same for a healing brush tool. Also something like PS's "Vanishing Point" feature would be nice to have.

Sven

On Tue, 18 Apr 2006, GSR - FR wrote:

dneary@free.fr (2006-04-18 at 1004.27 +0200):

I had some ideas:
- Scripting languages and the GIMP - work on ruby or python bindings

I'd love to see a single unified interface shared by the various Python-fu, Script-fu, Perl-fu etc and it might make a suitable project since it is a limited self contained task.

What is missing in python one? About more langs... well, it is nice, but it is also nice to have things that are completly finished instead of many half done.

- Plug-ins: Save for web for example (too small to be a project, but could be part of one)

- Reorg the save workflow so there is only the save dialog and then the "per format" dialog, which should include the current export (flatten or save current drawable or as anim, apply masks or discard, etc) and format details (compression, comments, sampling ratio...).

- Effect layers - I think this is fairly straightforward with the GIMP as it is, it's a nice chunk of a project, and would be a nice feature for users

If you mean what PS calls adjustment layers, we were talking about this and layer groups in IRC yesterday. Running filters could be a bit more tricky (what about multiple drawable input?) specially as some are way slower than composing a bunch of layers in a slight different order than current (groups) and with other extra formulas (adj) that are still per pixel.

- Vector layers (or replace GFig plug-in by Inkscape plug-in?)

Layers sounds better as it allows "in line" work.

Related would be: Non ortogonal guide system, useful for perspective works. Which could then be grouped to:

Is it really a line guide anymore if it isn't orthogonal (horizontal or vertical)? Having seen the Perspective grid in Corel Paint it seems like a much better way of providing what users want rather than overcomplicating guides.

- Healing tool: like clone tool with extra steps and special blend mode.

Request for a Healing brush:
http://bugzilla.gnome.org/show_bug.cgi?id=109801

A different thing:

- Improve the save session support. Currently dock order and other details are remembered. Remembering dettached menus and open/close of expander widgets would be nice too, so would be values for plugins.

Sincerely

Alan Horkan

Inkscape http://inkscape.org Abiword http://www.abisource.com
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/

Hi,

Alan Horkan writes:

I'd love to see a single unified interface shared by the various Python-fu, Script-fu, Perl-fu etc and it might make a suitable project since it is a limited self contained task.

Can you elaborate on this? Single unified interface sounds great but I have no idea what you mean here.

Sven

Sven Neumann wrote:

Yes, I think that a decent Red Eye plug-in would be nice project. Same for a healing brush tool.

There's already a plug-in for red eye removal in the plug-in registry: http://registry.gimp.org/plugin?id=4212

This plug-in works nicely, perhaps some work could be spent on integrating it permanently with the GIMP?

Andreas Røsdal

Hi,

Andreas Røsdal writes:

There's already a plug-in for red eye removal in the plug-in registry: http://registry.gimp.org/plugin?id=4212

This plug-in works nicely, perhaps some work could be spent on integrating it permanently with the GIMP?

Are you volunteering? I have multiple times asked for someone to evaluate existing plug-ins, pick one and bring it up to the GIMP coding and user interface standards so that it can be added to the source tree.

Sven

PS: Note that I haven't looked at the plug-in you pointed at. It might already be good enough for inclusion.

Okay, we are now on Google's list and have begun to put together a project page, which you can find at http://wiki.gimp.org/gimp/SummerOfCode . A couple of important points:

1) Ideally, a mentor for a project would be somebody who is capable of doing the project him/herself without a lot of false starts and hacking around, and only lacks the time for it. If you aren't at this level, you *might* still be a viable mentor, but only if you make this clear and get a commitment from somebody with more knowledge to give you whatever backup you will need. Just because you are interested in an idea does not mean that you are ready to mentor it.

2) If there is a project on the list that you are ready and willing to mentor, please add your initials, or some other unique identifier, to the description somewhere. Multiple volunteers for a single project are acceptable.

3) SoC students will probably be very enthusiastic and prepared to put in hundreds of hours of work. Don't be afraid to ask for things that are difficult. Conversely, be prepared to give regular guidance -- a student with nothing to do because of lack of feedback will get very frustrated very quickly.

All this being said, please add your ideas to the page, or modify the ideas that are there. Sven and Mitch should feel free to delete ideas that they see as bad projects. Ultimately we should get this down to not more than a dozen clearly expressed and well-formulated projects.

-- Bill

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

On Wed, 19 Apr 2006, Sven Neumann wrote:

Date: Wed, 19 Apr 2006 21:02:47 +0200 From: Sven Neumann
To: Alan Horkan
Cc: Not Photoshop
Subject: Re: [Gimp-developer] Re: GIMP and Google SoC

Hi,

Alan Horkan writes:

I'd love to see a single unified interface shared by the various Python-fu, Script-fu, Perl-fu etc and it might make a suitable project since it is a limited self contained task.

Can you elaborate on this? Single unified interface sounds great but I have no idea what you mean here.

Script-fu does not look like Python-fu or Perl-fu. Users should not be able to tell from the user interface that a different programming langauge was used. They all have automatically generated user intefaces* but the results look different, and some widgets such as a Radio list are supported in Python-fu but not in script-fu.

Not sure I can make it any clearer but hopefully someone else can help explain it.

Hi, with Blender3D we did GSOC last year and I was a mentor for one of the projects.
Some decisions have been made this year as to how we filter applicants.

in a nutshell- these seem obvious.

1. They must be able to compile the software (a few students ended loosing time by not having a propper dev environment) 2. They must be able to submit a patch- (for blender, we are even requiring they write a small patch and submit, as a requirement for being an applicant )
3. They have to know the language they are programming in. (durr. but we had 1 guy who hadnt used C before, he had used other languages tho and did complete the project, but this is not ideal) 4. Must be able to devote full time. no summer jobs, courses. (had some problems with this also)

for full docs see. http://mediawiki.blender.org/index.php/BlenderDev/SOC_2006_ideas

I hope gimp can get gsoc, no doubt many of the guys at google even use the gimp sometimes.

On 4/18/06, Dave Neary wrote:

I had some ideas:
- Scripting languages and the GIMP - work on ruby or python bindings - Plug-ins: Save for web for example (too small to be a project, but could be part of one)
- Effect layers - I think this is fairly straightforward with the GIMP as it is, it's a nice chunk of a project, and would be a nice feature for users
- Vector layers (or replace GFig plug-in by Inkscape plug-in?) - Tools - shapes, intelligent eraser?

Just another idea, simple and useful: on canvas text editing

Alexandre

Few tips for SOC:

* Something I am guilty of never getting to was speccing out a search based interface to filters (plugins). I believe a search based interface will be more efficient than navigating through a nested structure of a menu. * Improve SIOX to give nice anti-aliased result. The current implementation is a nice bulletpoint in a feature-list, but the result is very jaggy and hardly usable as is. Unless you work at 4 times the final resolution perhaps. * Flowed text. The text tool doesn't allow to create blocks of justified text.

cheers

Von: Jakub Steiner

* Something I am guilty of never getting to was speccing out a search based interface to filters (plugins). I believe a search based interface will be more efficient than navigating through a nested structure of a menu.

This sounds like "Ability to run plug-ins from the plug-in browser". IMO the "search" part is already there and the "run" part has to be done.

HTH, Michael

Campbell Barton wrote:

in a nutshell- these seem obvious.

Indeed, but maybe some details aren't obvious...

1. They must be able to compile the software (a few students ended loosing time by not having a propper dev environment)

They must be able to build current CVS. This is different from building a stable version or even an older 2.3 tarball, as the required versions of Glib and GTK+ have been raised and additional tools are required as well.

2. They must be able to submit a patch- (for blender, we are even requiring they write a small patch and submit, as a requirement for being an applicant )

How did you handle applying the patches? From http://mediawiki.blender.org/index.php/BlenderDev/SOC_2006_ideas, I see that Blender is requesting weekly status reports, are patch reviews/commits coupled to this?

4. Must be able to devote full time. no summer jobs, courses. (had some problems with this also)

How did you solve them? Did you ask the students to devote more time on the SoC project, or did you have to cancel some projects?

Michael

On Fri, 21 Apr 2006, Jakub Steiner wrote:

Date: Fri, 21 Apr 2006 14:24:34 +0200 From: Jakub Steiner
To: gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] GIMP and Google SoC

Few tips for SOC:

* Something I am guilty of never getting to was speccing out a search based interface to filters (plugins). I believe a search based interface will be more efficient than navigating through a nested structure of a menu.

I was using the PDB browser for this purpose. I tried to add a button which would bring up the currently selected filter but I didn't get very far with it, although I do think it should be possible to hack together soemthing.

Sincerely

Alan Horkan

Inkscape http://inkscape.org Abiword http://www.abisource.com
Open Clip Art http://OpenClipArt.org

Alan's Diary http://advogato.org/person/AlanHorkan/

Hi,

Jakub Steiner writes:

* Something I am guilty of never getting to was speccing out a search based interface to filters (plugins). I believe a search based interface will be more efficient than navigating through a nested structure of a menu.

That reminds me that with all the recent changes to the plug-in registration, the current Plug-In Browser has become less useful than it used to be. And I think that it could make sense to replace it by a menu browser. Users shouldn't really have to care about whether a function is implemented in the core or in a plug-in or script. We should probably do the following:

- Improve the PDB interface for getting plug-in information.

The current API doesn't really work well. All it offers is retrieving a list of all plug-ins. There should be an API that allows queries using regular expression similar to gimp-procedural-db-query. This will allow to improve the Plug-In Browser and long-term it will help for tasks such as one-click plug-in installation/deinstallation. Also we will want to show this information in the proposed Menu Browser (see below).

- Improve the Plug-In Browser using the new API.

This will show that the new API does what it's supposed to do. It includes adding search functionality similar to what the Procedure Browser offsers. Both plug-ins already use the GimpBrowser widget so this should be relatively easy.

A menu browser could also be implemented as a plug-in, provided that we added a PDB API to access the menu structure. But soon enough we would want to allow changes to the menus from the browser, turning it into a menu editor. At this point it probably starts to make sense to implement it in the core instead of exposing all the details of the menu system to the PDB and even allowing to edit by means of PDB calls.

Not sure if such a menu browser could double as the filter browser you asked for. You probably had something less intrusive in mind.

Could this (the plug-in browser changes and the menu editor) perhaps become a SoC project?

* Improve SIOX to give nice anti-aliased result. The current implementation is a nice bulletpoint in a feature-list, but the result is very jaggy and hardly usable as is. Unless you work at 4 times the final resolution perhaps.

Perhaps Gerald could elaborate a bit about the Detail Refinement Brush for SIOX. There is already code for this in GIMP CVS. It just isn't used yet.

* Flowed text. The text tool doesn't allow to create blocks of justified text.

Yes, there's quite a bit of improvements that could be done to the text tool. I think this could be a nice SoC project and I would like to mentor it.

Sven

Hi,

just a quick idea:

How much sense would it make to try to turn Raphael's approach to metadata editing into a SoC project? I suspect that Raphael might be able to find enough time to mentor it.

Sven

Hi,

we could try to propose this as a SoC project:

- Redesign and reimplementation of Save and Export in GIMP.

Change the semantics of Save and Save As so that images are always saved in the XCF file format. Only the native GIMP format really saves all the image information and allows to losslessly continue editing later. So only saving as XCF should clear the dirty flag of the image.

Saving to other formats than XCF is done by exporting the image. The File menu should have an Export menu item (and perhaps also Export As). This opens a dialog that asks the user what to export. The projection (what you see), the active drawable, an animation based on the layers of the image, etc. If the image consists of a single layer this step can be skipped. The dialog then gives the user the choice of a file format including options for that format. It also uses a GtkFileChooser widget to pick a save location.

The details of this Export dialog could be determined as part of the redesign or we could try to come up with a detailed proposal beforehand.

Sven

Hi,

another thing that came to my mind:

- Add a (unit) testing framework and tests to GIMP.

Details are left out for now but the idea is to get more unit tests and to make it easier to add and maintain them. But also to have more complex test scripts that perform GIMP operation using the PDB. These scripts would be run on a set of test images and the results would be compared against a set of output images. The test framework should also allow to easily test functionality of a certain plug-in. This way errors could easily be spotted and it would make changes to plug-ins a lot safer. Such tests could also be used as benchmarks to help with optimizations.

Should we try to turn this into a more detailed proposal?

Sven

On 4/21/06, Sven Neumann wrote:

Hi,

another thing that came to my mind:

- Add a (unit) testing framework and tests to GIMP.

Details are left out for now but the idea is to get more unit tests and to make it easier to add and maintain them. But also to have more complex test scripts that perform GIMP operation using the PDB. These scripts would be run on a set of test images and the results would be compared against a set of output images. The test framework should also allow to easily test functionality of a certain plug-in. This way errors could easily be spotted and it would make changes to plug-ins a lot safer. Such tests could also be used as benchmarks to help with optimizations.

Should we try to turn this into a more detailed proposal?

This sounds like an excellent idea.

Rockwalrus

On Saturday 22 April 2006 05:46, Nathan Summers wrote:

On 4/21/06, Sven Neumann wrote:

Hi,

another thing that came to my mind:

- Add a (unit) testing framework and tests to GIMP.

Details are left out for now but the idea is to get more unit tests and to make it easier to add and maintain them. But also to have more complex test scripts that perform GIMP operation using the PDB. These scripts would be run on a set of test images and the results would be compared against a set of output images. The test framework should also allow to easily test functionality of a certain plug-in. This way errors could easily be spotted and it would make changes to plug-ins a lot safer. Such tests could also be used as benchmarks to help with optimizations.

Should we try to turn this into a more detailed proposal?

This sounds like an excellent idea.

Hi!

I agree this is a good idea. However, in case you didn't notice - I started working on a test suite for GIMP:

http://svn.berlios.de/svnroot/repos/gimp-test/trunk/

$ svn log -r 1 http://svn.berlios.de/svnroot/repos/gimp-test/ ------------------------------------------------------------------------ r1 | shlomif | 2005-02-18 01:12:32 +0200 (Fri, 18 Feb 2005) | 1 line

Creating the Trunk ------------------------------------------------------------------------ $

The framework for creating such tests is there, including a way to make the random generator seeds predictable. I already wrote a few tests, and it seems to work nicely, but then was distracted. If anyone wishes to help, he could just volunteer some time to write more tests. I am willing to be a mentor for a SoC project that aims to expand this test suite.

Regards,

Shlomi Fish

--------------------------------------------------------------------- Shlomi Fish shlomif@iglu.org.il Homepage: http://www.shlomifish.org/

95% of the programmers consider 95% of the code they did not write, in the bottom 5%.

* Improve SIOX to give nice anti-aliased result. The current implementation is a nice bulletpoint in a feature-list, but the result is very jaggy and hardly usable as is. Unless you work at 4 times the final resolution perhaps.

Perhaps Gerald could elaborate a bit about the Detail Refinement Brush for SIOX. There is already code for this in GIMP CVS. It just isn't used yet.

I would be really happy if the implementation of the DRB could be done as a Google SoC project. And there is still room for speed improvements in SIOX...Me or Kristian would be there for any questions.

However, as far as I understood, there is still an issue: Is GIMP able to display non-binary alpha values? I loaded in a PNG that I created using the SIOX demonstration Applet and I saw that GIMP binarizes the alpha values....

Gerald

-- Gerald Friedland Raum 164 Tel: ++49 (0)30/838-75134 Freie Universität Berlin Takustr. 9 http://www.gerald-friedland.org Institut für Informatik 14195 Berlin fland@inf.fu-berlin.de

Gerald Friedland (fland@inf.fu-berlin.de) wrote:

However, as far as I understood, there is still an issue: Is GIMP able to display non-binary alpha values? I loaded in a PNG that I created using the SIOX demonstration Applet and I saw that GIMP binarizes the alpha values....

This should only happen for indexed images, then indeed GIMP does binarize the alpha values, at least in the display. If the PNG is stored as a RGBA-PNG then everything should be fine.

Hope this helps, Simon

William Skaggs (weskaggs@primate.ucdavis.edu) wrote:

4) Vector layers and tools to manipulate them -- allowing adjustable rectangle and ellipse shapes, lines with arrow, etc.

Actually my roadmap for vector layers would look something like this:

- create the infrastructure to have vector "styles", i.e. a vectors object has fill and stroke attributes. Create GUI to edit these styles.

- make it possible to create a connection between a vectors object and a drawable, similiar to a text layer: the drawable gets rerendered when the vectors object changes.

- probably it should be possible to attach multiple vectors to a single drawable. Each vectors object would have its own style attributes and the order in the paths dialog would determine the rendering order on the drawable.

- Try to figure out a workflow for editing this in a sane manner. IMHO the path tool is sufficient to edit the shape of the associated path, but all the other stuff might need some thinking.

Stuff like rectangle and ellipse shapes are not inherently connected to the vector layer stuff, they would simply be different stroke types. I already have implemented an proof-of-concept rectangle stroke type, that is a bit weird to edit, but works.

I offer to mentor this project.

Bye, Simon