On Mon, Oct 6, 2008 at 10:05 AM, Sven Neumann wrote:

So, what are your plans for 2.8?

For me there are 2 bugs I want to tackle for 2.8 in bugzilla.

First http://bugzilla.gnome.org/show_bug.cgi?id=471344 - The interpolation issue causing "polygonal" strokes when moving fast and second http://bugzilla.gnome.org/show_bug.cgi?id=323923 - Allowing brush rotation and related dynamics.

Wether I manage to do that in time and with sufficent quality is a different matter.

P.S Sorry, Sven, for spamming your mailbox,

--Alexia

On Mon, Oct 6, 2008 at 12:05 AM, Sven Neumann wrote:

So, what are your plans for 2.8?

I think I'm going to focus mainly on integrating Skalle's on-canvas text code, which
should be ready for merging into trunk immediately after the branching, if you and
Mitch approve. I'd like to express the hope that you and Mitch will focus, right at
the start, on getting non-XOR drawing to work. That shouldn't be extremely hard, and there's a ton of important UI stuff that depends on it. I'm willing to work
on this myself if you think it would be useful.

-- Bill

Sven Neumann wrote:

So, what are your plans for 2.8?

Hi

Currently I am interested in polishing the user interface, namely

* Fixing GtkNotebook somehow so that we can save horizontal space for dialogs by getting rid of their title and have the Dialog menu as a rightclick on the tab

* Making the toolbox (and the rest of the interface?) color neutral [1], probably through a color neutral theme

* Getting rid of the GimpDockSeparator's in docks and only show a counterpart to them when a user is in the process of docking a Dialog. This is IMO a prerequisite for:

* Supporting one-window layouts by allowing to dock the toolbox and dialogs to image windows/the empty image window [1]

[1] in line with Peter's UI roadmap: https://lists.xcf.berkeley.edu/lists/gimp-developer/2007-November/019068.html

Now, by experience I know that interest and focus can vary in a development cycle, but I think it would be really nice to fix the above for 2.8.

BR,
Martin

On Monday 06 October 2008 22:32:43 Sven Neumann wrote:

This is IMO a prerequisite for:

* Supporting one-window layouts by allowing to dock the toolbox and dialogs to image windows/the empty image window [1]

IMO the most important prerequisite for this is the introduction of tabs into the image window. I would very much like to see the possibility of having multiple images open in a tabbed image window.

Indeed. That would be one UI change that would make the gimp UI a lot more convenient now that Utility Window hints are working. Being able to dock docks to image window would simply be cherries on the cake.

-- Alexia

Sven Neumann wrote:

* Making the toolbox (and the rest of the interface?) color neutral [1], probably through a color neutral theme

That is the job for an artist, not a developer. You should try to get Jimmac into the boat.

It would of course be nice if the whole icon set was adapted by an artist to look good when color neutral, but I don't really see anyone doing that very soon. There are two approaches that I think will possible to get into 2.8 and they both somewhat involve programming:

1. Run the existing theme image elements through ImageMagick and make them all greyscale, then compose the color neutral theme from that.

2. Support color neutrality for all themes, i.e. programatically make icons color neutral and perhaps only color them when they are being hovered by the mouse cursor.

If either of those will look good enough for being promoted to an official stable release is another thing, but perhaps the initial effort will attract graphical artists to help out.

* Getting rid of the GimpDockSeparator's in docks and only show a counterpart to them when a user is in the process of docking a Dialog.

I don't understand this. What's wrong about the seperators?

The separators occupy horizontal space even when they are not used. They (or rather, their counterparts) only needs to be shown on a GtkWidget::drag-begin and they can be hidden on the corresponding GtkWidget::drag-end. My current thinking is to add a

gimp_dock_show_dockability_overlay()

that would show/hide the separators in self-contained popup windows over each dock, probably taken care of by a manager of some kind. I believe the best approach would be to have one overlay window for each dock, and paint/highlight dockable areas on an otherwise completely transparent window, but I'm not sure GTK+ supports that for all platforms/window managers well enough.

This is IMO a prerequisite for:

* Supporting one-window layouts by allowing to dock the toolbox and dialogs to image windows/the empty image window [1]

IMO the most important prerequisite for this is the introduction of tabs into the image window. I would very much like to see the possibility of having multiple images open in a tabbed image window.

A tab interface would certainly make a single-window layout even nicer, but just being able to dock things at all to image windows would IMO be useful enough, and I don't like the idea of having GimpDockSeparators always visible in the image windows. So I still believe that getting rid of the GimpDockSeparators is more important than a tab-interface.

- Martin

Sven wrote:

So, what are your plans for 2.8?

we agreed at lgm on roadmapping:

- geometry tool integration - layer groups

and another one I can't remember >^}

Kamilla?

--ps

founder + principal interaction architect man + machine interface works

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

peter@mmiworks.net wrote:

Sven wrote:

So, what are your plans for 2.8?

we agreed at lgm on roadmapping:

- geometry tool integration - layer groups

and another one I can't remember >^}

I really like the brush dynamics feature in this. Something I'd like to see in 2.8/2.10 or whatever if possible is a more advanced brush dynamics system, perhaps even moving it to its own dialog.

1. Include jitter in brush dynamics as an output. 2. For each input/pair pair, have an value slider. With just one value slider for the entire input if I hook random up to color as well as size I can't have it affect the size a little and the color a lot, but with one per pair I could have random/color a small value and random/size a larger value.
3. For outputs that don't have an 'initial' setting (size/color/opacity do but for example jitter doesn't) have a slider for the specified output allowing setting an initial value. So if random/jitter(initial) is set to 0.2 and random/jitter is set to 0.4 then jitter would be somewhere in 0.2-0.6

Additional inputs if not already there:

1. angle between two point samplings during a stroke 2. speed between two point samples during a stroke

Additional outputs

1. Brush hue

I know in the past there were some talks about some pretty interesting ideas.

Brian Vanderburg II

On Mon, Oct 06, 2008 at 09:05:26AM +0200, Sven Neumann wrote:

Moin,

I just announced on gnome-i18n that we will be doing the 2.6.1 release in a few days, probably on Wednesday. There are a couple of bug-fixes in trunk that are worthwhile to release. After the release, I will immidiately create a gimp-2-6 branch for further maintainance. At that point trunk will become GIMP 2.7 and we can start to add new stuff.

So now would be a good time to define some goals for GIMP 2.8. A few items are definitely on our list already:

- merge the successful GSoC projects - attempt a port of the projection code (and perhaps more) to GEGL - change tools to draw using the Cairo library

All of these three items will require further changes before another stable release can be made. So that is quite a lot to do already, but we could probably add a few more items to this list if there are developers willing to work on them. So, what are your plans for 2.8?

Sven

IMHO (my 0.00002 cents): for the future 2.8.0.

Perhaps using .rcX versions before going public as OpenOffice or other big teams do could save from the exit of a buggy first version...

On Mon, Oct 6, 2008 at 11:59 PM, Martin Nordholts wrote:

* Making the toolbox (and the rest of the interface?) color neutral [1], probably through a color neutral theme

That is the job for an artist, not a developer. You should try to get Jimmac into the boat.

It would of course be nice if the whole icon set was adapted by an artist to look good when color neutral, but I don't really see anyone doing that very soon.

http://jimmac.musichall.cz/log/?p=30

Alexandre

On Mon, 2008-10-06 at 09:05 +0200, Sven Neumann wrote:

So that is quite a lot to do already, but we could probably add a few more items to this list if there are developers willing to work on them. So, what are your plans for 2.8?

An application is of course lots more than a binary...

I'd like to see a release with brushes, textures, tutorials, new tips, plugins, scripts... and maybe a separate Resource Pack with more. OpenFontLibrary.org is starting to happen for fonts.

This isn't something that needs a whole lot of developer time; it needs time from translators (for tutorials, documentation changes, visible brush names/tags, etc) and from someone to orchestrate it all.

At the very least, a Guided Tour showing what's new, and highlighting features unique to GIMP or that are relatively new (e.g. since 2.4, maybe even 2.2) to help people get used to them.

Unfortunately I'm about to get a lot busier at work, I fear. I'll have a better idea in a month or so how much busier, and if I can, I'll volunteer to organise some hot resource lovin' :)

Liam

I am running GIMP-2.6 on Slackware 12.1 and encountered a problem with the default shortcut key assignments for "Decrease Value 2 more" and "Increase Value 2 more". The preferences dialog says that those to functions are assigned to "shift + [" and "shift + ]" respectively but with my setup these defaults did not work. However, after I reassigned the functions to "{" and "}", things behaved as I would have expected.

This problem was brought to my attention by a Windows XP user who experienced the same problematic default behavior.

If it would not cause grief for users on other systems, I would propose changing the default assignments for these two functions (in app/actions/tools-actions.c) from "bracketleft" to "braceleft"; and from "bracketright" to "braceright".

On 7 Oct 2008, at 10:05, I wrote:

So, what are your plans for 2.8?

we agreed at lgm on roadmapping:

- geometry tool integration - layer groups

and another one I can't remember >^}

I think I just did: improve floating selection handling.

--ps

founder + principal interaction architect man + machine interface works

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