Martin Nordholts wrote:
[cut]

Does anyone have any suggestions on adjustments and additions to the default set of GIMP resources?

I have a few suggestions as a creative/artistic user which uses GIMP mainly with a pen tablet (as probably any other people who is serious into raster graphic art). I'm not sure if they fit the product vision, but I'm trying anyway:

- As you say, add larger variants of standard brushes. Artists typically work on rather large canvases (I personally use 300 dpi A4, which equates roughly to 3500x2500 pixels). The standard maximum brush size of 19 pixels at these resolutions can be quite small.

- Add some variations of rake brushes (not standard in Gimp right now) and more different types and sizes of bristle brushes.

- Add more realistic patterns from commonly used artistic media (for example different types of paper, etc), to simulate easily its texture while drawing.

On Mon, Jul 20, 2009 at 4:06 AM, Martin Nordholts wrote:

Hi,

With the integration of tagging support in GIMP we have a mechanism that allows us to organize resources (brushes, patterns, palettes, and gradients). This enables us to add a bigger set of default resources.

I would re-suggest integrating GHNS or have a similar way of easy sharing of resources from The GIMP or all CREATE projects. Once that is done, the most popular brushes can be added to the default set. What say ?? Just my 2 cents.

On Mon, Jul 20, 2009 at 2:36 AM, Martin Nordholts wrote:

 * Add larger variants of the circle and fuzzy circle    brushes, say 50, 100, 250 and 500 px

The prerequisite for this is GIMP not playing a dying turtle that climbs up to Kilimanjaro top while drawing with a 200+ px brush :)

Alexandre

On Mon, Jul 20, 2009 at 1:36 AM, Martin Nordholts wrote:

Hi,
I think we at least should:

* Add larger variants of the circle and fuzzy circle brushes, say 50, 100, 250 and 500 px

Please no, there's too many round brushes already and bigger ones would look exactly the same and add confusion. There should not be 2 brushes that look to be the same shape in the default set. Since 2.8 will have decent scaling on all brushes, we could get rid of the N variants of round vector brushes(and that's where backward compatibility really bites). They represent an obsolete modus operandi, where scaling wasn't possible. What gimp needs is more examples of various vector brushes, like stars and tilted bars and alike that can be used perfectly with dynamics and some actually useful bitmap brushes for painting like activities.

* Try to get rid of the Pepper, Sparks and Vine brushes

in a backwards compatible way

They represent quite nice examples of bitmap brushes and I don't mind at all that they stick around, after all theres only 3 of them compared to 10+ round brushes. Combined with dynamics they make perfect example/demo brushes. See above for the real annoyance.

I propose we put all the legacy brushes we dont want to keep into a backwards compatibility extras pack and release it along with 2.8 (windows installer could let it be selected as an optional component and Linux distros can have an extra pack for them). Scripts that use hard coded brushes are not that common. In fact, I haven't seen a single one in general use or passing through FX Foundry.

Does anyone have any suggestions on adjustments and additions to the default set of GIMP resources?

Default set of resources should include some tool presets, like some common aspect ratio fixed presets(2:3, 3:4) for crop tool and dynamics enabled presets for the paint tools using default resources set.

--Alexia

On Mon, Jul 20, 2009 at 1:10 PM, Alexia Death wrote:

Default set of resources should include some tool presets, like some common aspect ratio fixed presets(2:3, 3:4) for crop tool and dynamics enabled presets for the paint tools using default resources set.

So we are back to the topic of GIMP Paint Studio integration? :)

Btw, is it possible to make tools presets localizable?

Alexandre

On Mon, Jul 20, 2009 at 12:15 PM, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:

On Mon, Jul 20, 2009 at 1:10 PM, Alexia Death wrote:

Default set of resources should include some tool presets, like some

common

aspect ratio fixed presets(2:3, 3:4) for crop tool and dynamics enabled presets for the paint tools using default resources set.

So we are back to the topic of GIMP Paint Studio integration? :)

I woudnt go that far, and I woudn't limit it to paint tools. I think all tools should have at least a few presets for common usecases.

I have not played extensively with a release supporting tagging so forgive this possible trivial questions.

Is the tagging data stored in the resource file itself as metadata or in some corresponding file or files?

Is it possible to pre-tag the items in a set of resources (say a brush set) that can easily be distributed with the resources?

Are the tags managed- for example, if there is no resource with a tag because it was deleted does the tag get removed?

Thanks in advance. I realize this may not be appropriate for a devel list but figured those who implemented the feature would have the best understanding st this time.

-Rob A>

On 7/19/09, Martin Nordholts wrote:

Hi,

With the integration of tagging support in GIMP we have a mechanism that allows us to organize resources (brushes, patterns, palettes, and gradients). This enables us to add a bigger set of default resources.

Not being an artist myself makes me rather useless for this task. To get things rolling I thought I'd start a discussion on what a better set of default resources would be.

A few things are clear:

* The new default resources must fit the product vision [1] * The resources must be very general in nature * We can't have a huge set of resources since we need to keep the size of the tarball within reasonable limits * We not only need resources, we also need to assign tags to them

I think we at least should:

* Add larger variants of the circle and fuzzy circle brushes, say 50, 100, 250 and 500 px * Try to get rid of the Pepper, Sparks and Vine brushes in a backwards compatible way

Does anyone have any suggestions on adjustments and additions to the default set of GIMP resources?

/ Martin

[1] http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision _______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Martin Nordholts wrote:

Does anyone have any suggestions on adjustments and additions to the default set of GIMP resources?

I would propose having a hard-edged, foreground color to background color gradient. Such a gradient can be useful for creating circles, boxes, blinds, bullseyes, and spirals. While it is fairly easy to create, this process is a little bit intimidating for new users and having the gradient available by default would make it easier to include its utility in tutorials.

The following file is such a gradient named, "Hardedge FG to BG":

http://flashingtwelve.brickfilms.com/GIMP/Gradients/hardedge.ggr

On Mon, Jul 20, 2009 at 2:36 AM, Martin Nordholts wrote:

Hi,

With the integration of tagging support in GIMP we have a mechanism that allows us to organize resources (brushes, patterns, palettes, and gradients). This enables us to add a bigger set of default resources.

What I'd love to see instead/alongside is sane defaults. While Pencil is a brush based tool, users do not actually expect it to behave like a brush. But right now Pencil and Brush use same brush by default: Circle Fuzzy (19), 0,90 scaled, pressure mapped to opacity. Instead Pencil should be a Circle (03) brush, because it's a Pencil :)

I've heard that complaint from users too many times to let it slip again.

Alexandre

I'd really love to see GIMP Paint Studio presets as default too. That would make possible to get rid of some default brushes that really don't cut.
About the large size brushes, I also agree. I think that several small round brushes should be removed (since brush scaling covers that need). We have nine small variants of round brushes, in a scale range that can be covered probably with a couple of them + scaling.

I think we should have:

- Larger round brushes. - GIMP Paint Studio brushes and presets - five to ten texture/grunge bruses, in two sizes: large and small.

I'd get rid of that outline squares, crosses and some of the special effects brushes.

Gez.

What I really miss is to be able to remove brushes that I don't need and sort/group the ones I use a lot. Maybe it would be better that most - if not all - of the brushes where copied to the users profile as a default instead of being static. This also would invite the user to modify her/his own set and experiment with the examples.
Otherwise I think the default is ok... it pretty much shows what is possible to do with the brushes or at least inspires.

Maybe it could be an idea to have selectable sets of brushes?

(Actually I would really love to have preset-brushes "dockable dialog" with swashes like PhotoShop. The presets are way to hidden... I know, I should post this on ui-brainstorm.)

On Mon, Jul 20, 2009 at 12:19 PM, Emil Assarsson wrote:

What I really miss is to be able to remove brushes that I don't need and sort/group the ones I use a lot.

There is he GURM python plugin which works quite well for this:

http://registry.gimp.org/node/13473

-Rob A>

Hi,
enselic@gmail.com (2009-07-20 at 0036.20 +0200): [...]

gradients). This enables us to add a bigger set of default resources.

Here you say "bigger".

[...]

A few things are clear:

* The new default resources must fit the product vision [1]

Does that leave things like Gimp Paint Studio out of the map?

* The resources must be very general in nature

Highly related to the point before, are proper airbrush or fake hair "tips" (pretty common in photoretouching) general enough? That is what always sounded strange in the product vision and the decissions based in it, they feel out of contact sometimes, as users have shown they do things in a bit more artistic way and less "run filter and cross fingers".

* We can't have a huge set of resources since we need to keep the size of the tarball within reasonable limits

Now you say "smaller" or "same"? Sorry, I am confused about what is the target.

[...]

I think we at least should:

* Add larger variants of the circle and fuzzy circle brushes, say 50, 100, 250 and 500 px

Remove scale widget and instead add true pixel control of all the brushes, so no more multiple sizes of the same thing needed because people can access all the sizes they want in fast and simple way (and if they want to keep some versions, they can clone brushes).

Instead, add different shapes and settings that are not controlled via size (sharp vs fuzzy could get one or more in between step, for example) or diverse pixmap brushes (grunge and realistic tips for paintbrush, spray can, airbrush, pencil, etc).

That would a better use, and would make clear the size setting is for something, instead of crowding the dialogs with many repeated circles.

* Try to get rid of the Pepper, Sparks and Vine brushes in a backwards compatible way

And as demo of animated or colour brushes we have... nothing? I think we should add some others pixmap and animated instead of removing them, for example grunge or rust types are good candidates. Ship some good presets demoing all the power, and even not-so-curious users will start to experiment.

I had drafted the initial version yesterday, but I see others agree in general terms, less "boring circles" and more "provide examples of what can be done and how they are better used".

GSR

Hi,

On Mon, 2009-07-20 at 00:36 +0200, Martin Nordholts wrote:

* Try to get rid of the Pepper, Sparks and Vine brushes in a backwards compatible way

You can just remove those if we agree that they are not useful. I doubt that any script out there actually uses them. This is different for the main geometric brushes. They are actually used and it would be nice if we could add code that avoids breaking scripts if we decide to remove them.

+1 from me for the removal of all brushes that only serve as an example but have no other value for the user.

Sven

Hi,

On Mon, 2009-07-20 at 17:28 +0400, Alexandre Prokoudine wrote:

What I'd love to see instead/alongside is sane defaults. While Pencil is a brush based tool, users do not actually expect it to behave like a brush. But right now Pencil and Brush use same brush by default: Circle Fuzzy (19), 0,90 scaled, pressure mapped to opacity. Instead Pencil should be a Circle (03) brush, because it's a Pencil :)

Easy enough, just unset the 'global-brush' property. I am not sure though if that would make a good default for the average user.

Sven

On Monday 20 July 2009, Sven Neumann wrote:

Hi,

On Mon, 2009-07-20 at 00:36 +0200, Martin Nordholts wrote:

* Try to get rid of the Pepper, Sparks and Vine brushes in a backwards compatible way

You can just remove those if we agree that they are not useful. I doubt that any script out there actually uses them. This is different for the main geometric brushes. They are actually used and it would be nice if we could add code that avoids breaking scripts if we decide to remove them.

+1 from me for the removal of all brushes that only serve as an example but have no other value for the user.

I d'be against the removal of the "vintage" pixmaped brushes.

However, what I think would be a good solution for preserving compatibility would also take these out of the way of users, while keping then available for scripts or anyone who looks for them.

Basically: we have to figure out a way of GIMP not displayin all available resources if no tag filtering is active. By figuring out a way, I mean an interface way.

Then, woud be a matter of tagging the unwanted-by-default backwards compatible brushes with an specifc tag (like "classic"), that would not be shown.

If changes in the current behavior of displaying everything when there are no tag filters are not desirable, the way to achieve this would be simply to tag the resoruces we want showing with "default", and this tag could come pre- selected on the UI.

js
->

Sven

Hi,

On Tue, 2009-07-21 at 18:33 -0300, Joao S. O. Bueno wrote:

I d'be against the removal of the "vintage" pixmaped brushes.

Why? Tell us a good reason then why we should keep them.

Sven

One reason to keep some image hose brushes in the default set is just to demonstrate that gimp supports them! I participate in a web forum for amateur cartography, and one of the most common requests is how to use tubes with photoshop. Most are extremely impressed that this capability exists in Gimp.

-Rob A>

On 7/21/09, Sven Neumann wrote:

Hi,

On Tue, 2009-07-21 at 18:33 -0300, Joao S. O. Bueno wrote:

I d'be against the removal of the "vintage" pixmaped brushes.

Why? Tell us a good reason then why we should keep them.

Sven

_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Tuesday 21 July 2009, Sven Neumann wrote:

Why? Tell us a good reason then why we should keep them.

On Tuesday 21 July 2009, Rob Antonishen wrote:

One reason to keep some image hose brushes in the default set is just to demonstrate that gimp supports them! I participate in a web forum for amateur cartography, and one of the most common requests is how to use tubes with photoshop. Most are extremely impressed that this capability exists in Gimp.

Thanks Rob --
that is goog reason enough.

Sven: Besides, with the current set, without these, GIMP woul be a "100% b&w" boring looking program - A litle bit of color in the brushes would be needed for this reason alone, IMHO.

It is true that when lecturing on GIMP I usually to say that the best use for the Pepper brush is to help us locate the Pixel brush, right next to it :-) (but then, I'd actually favor a whole set of "fruit & vegetable" brushes to ship by default with GIMP)

Alexia also holds that they should stay in terms even more clear than Rob did: they help one experimentt with the brush dynamics, color combination modes and otehr painting settings in ways that generated brushes or monochrome + alpha brushes can't help.

Now, my tagging proposal would just keep then available for people and scritps alike, while making then 100% non-obtrusive, - I don' t understand why you haven't commented on that.

js ->

On Wednesday 22 July 2009 00:37:43 Sven Neumann wrote:

Hi,

On Tue, 2009-07-21 at 18:33 -0300, Joao S. O. Bueno wrote:

I d'be against the removal of the "vintage" pixmaped brushes.

Why? Tell us a good reason then why we should keep them.

Ive done a few quite nice wallpapers with just dynamics and wine and spark brushes, so these two with dynamics on board definitely have value. Pepper brush in my eyes has value as something that clearly exhibits the effect of dynamics and as such is useful for demo purposes, so one vote from me against removing them. Like I said, they are not whats wrong wit gimps resources today. the problem is brushes that are identical in shape and only vary in size.

Indeed, they are good examples. For me, the thing is : why these examples ? To give examples doesn't mean not to justify them.

A justification could be the need of the users, if after a study it appears that the color Brush the most relevant to provide by default is a Pepper, I would understand. Unfortunately, I don't think so. I could also totally understand if someone justifies it by saying "it's for historical reason, the Pepper is a symbol for Gimp".

Moreover I think I'm not mistaken if I say that a large set of casual users keep using Gimp with the default brush set and don't add custom ones. My opinion would be that the more useful brushes they have, the more they will feel creative. This is why I think Gimp should be shipped with a large set of useful brushes.

Steren

On Wed, Jul 22, 2009 at 12:53 AM, Rob Antonishen wrote:

One reason to keep some image hose brushes in the default set is just to demonstrate that gimp supports them! I participate in a web forum for amateur cartography, and one of the most common requests is how to use tubes with photoshop. Most are extremely impressed that this capability exists in Gimp.

-Rob A>

On 7/21/09, Sven Neumann wrote:

Hi,

On Tue, 2009-07-21 at 18:33 -0300, Joao S. O. Bueno wrote:

I d'be against the removal of the "vintage" pixmaped brushes.

Why? Tell us a good reason then why we should keep them.

Sven

On Wed, Jul 22, 2009 at 12:26 PM, Martin Nordholts wrote:

On 07/20/2009 10:29 AM, Alexandre Prokoudine wrote:

On Mon, Jul 20, 2009 at 2:36 AM, Martin Nordholts wrote:

* Add larger variants of the circle and fuzzy circle brushes, say 50, 100, 250 and 500 px

The prerequisite for this is GIMP not playing a dying turtle that climbs up to Kilimanjaro top while drawing with a 200+ px brush :)

On my computer, painting with a 500px brush on an A4 has acceptable performance. I don't think performance problems should keep us from adding better resources. It would of course be nice if someone looked into what exactly what is slow and if it would be easy to improve performance.

Ive actually looked at the process with a profiler and simply applying the brush on canvas is what eats resources. With gegl projection/paint core and only rendering at relevant zoom level it perhaps can be improved, but not really as is... My objection to having a 500px brus in the resources is however, that it is a workaround ofr a GUI ineficency and I do not like it at all. IMHO there should not be two brushes of the same shape, instead, the tool UI should allow for selecting the size from a preset set of scale results that could be very well 50, 100, 250 and 500 px for all brushes.

--Alexia

PS: Sorry Martin for spam.

Martin Nordholts wrote:

I get your drift, but is it really reasonable to force a user to scale a say 250px brush to 3px if that is what he desires? It might be, but I don't think it is with our current scaling mechanism. What do you think

Regarding this, as an user (and not a programmer), I've always wondered why in the case of vector brushes a "scaling" setting is used instead of fiddling directly (and easily) with their size.

On Wed, 22 Jul 2009 12:03:31 +0200 Martin Nordholts wrote:

I get your drift, but is it really reasonable to force a user to scale a say 250px brush to 3px if that is what he desires? It might be, but I don't think it is with our current scaling mechanism. What do you think bout offering a range of brushes that together covers a big radius spectrum? Since scaling currently can be done in the range 10%-1000%, how about these radiuses for the Circle and Fuzzy Circle ones:

10px, 50px, 250px

As a user who is constantly scaling up the largest fuzzy circle brush, I'd love to see a different interface... but not in the form of more burshes. How about, as Alexia suggested, a single brush and a size box, which could be a combo box offering the "standard" sizes, plus the option to enter a custom size. Expressing this size in pixels would make them a little less abstract than they currently are, which would make it easier to work with.

On Tue, Jul 21, 2009 at 12:16 AM, Sven Neumann wrote:

Easy enough, just unset the 'global-brush' property. I am not sure though if that would make a good default for the average user.

So far I only heard from users "thanks, but why is it not by default?" :)

Alexandre

On Wed, Jul 22, 2009 at 14:12, Alexandre Prokoudine wrote:

On Tue, Jul 21, 2009 at 12:16 AM, Sven Neumann wrote:

Easy enough, just unset the 'global-brush' property. I am not sure though if that would make a good default for the average user.

So far I only heard from users "thanks, but why is it not by default?" :)

I guess you wouldn't hear from people who like it the way the default is set, would you? :)

Greetings, Fredrik.

2009/7/22 Fredrik Alströmer wrote:

On Wed, Jul 22, 2009 at 14:12, Alexandre Prokoudine wrote:

On Tue, Jul 21, 2009 at 12:16 AM, Sven Neumann wrote:

Easy enough, just unset the 'global-brush' property. I am not sure though if that would make a good default for the average user.

So far I only heard from users "thanks, but why is it not by default?" :)

I guess you wouldn't hear from people who like it the way the default is set, would you? :)

I don't expect to hear from people who never use Pencil tool, if that's what you mean :) I don't really know what else to say. Clear separation of default settings for different tools is such an obvious thing...

Alexandre

2009/7/22 Fredrik Alströmer

On Wed, Jul 22, 2009 at 14:12, Alexandre Prokoudine wrote:

On Tue, Jul 21, 2009 at 12:16 AM, Sven Neumann wrote:

Easy enough, just unset the 'global-brush' property. I am not sure though if that would make a good default for the average user.

So far I only heard from users "thanks, but why is it not by default?" :)

I guess you wouldn't hear from people who like it the way the default is set, would you? :)

Well you can hear from me: I like the global-brush setting; if it is accidentally turned off I find it very annoying, having to reselect brush between tools... usually I *do* want to keep just the same brush between tools. When I think about it, I wonder whether such users ever get to using GIMP with any level of frequency or intensity, as IMO with the global-brush option off, there is an unavoidable mental 'thunk' to accommodate for the possible change of brush as you change tool; global-brush == off seems in this way to inherently slow the user's workflow (regardless of what workflow they use -- having to think 'oh, what is the brush of this tool' == slowdown.)

A related issue is the difficulty of reliable brush selection. ideally I would hit a shortcut (say CTRL+B) and then type part of a brush name and hit enter to select it. The current brush selection methods either require direct pointing, are inaccurate, or only allow relative selection (ie. next brush, prev brush)

(note: you can do absolute brush selection by this method IIRC: make sure your brushes dialog is set to List,
then when you want to select a brush by name, hit [the shortcut for the brushes dialog], then CTRL+F and type the name fragment. This has two downsides - a) it's too much keyboard work for a common operation, b) it changes the focus, which means I have to mouse back to the image window or ALT-TAB before I can continue as before (say, adjusting the drawing opacity before I start painting))

Also, Alexandre says:

Clear separation of default settings for different tools is such an obvious thing...

I agree with that. Unfortunately, having sensible, different defaults for different tools is in direct conflict with having an efficient, un-surprising workflow (and everyday workflow takes priority IMO.. A person remains a newbie for only so long, but the general consistency of workflow is something they will need to deal with as long as they use GIMP -- including any bureaucratic lumps such as (global-brush == off))

David

2009/7/22 David Gowers wrote:

tools. When I think about it, I wonder whether such users ever get to using GIMP with any level of frequency or intensity, as IMO with the global-brush option off

Don't wonder -- they do. And I do too :)

(Speaking of which, the fact that tools presets don't save/restore scale value isn't helpful either.)

Clear separation of default settings for different tools is such an obvious thing...

I agree with that. Unfortunately, having sensible, different defaults for different tools is in direct conflict with having an efficient, un-surprising workflow

Contrary to that I would yell every time I switched from Paintbrush to Eraser if I didn't have global brush disabled. It's way too convenient to use e.g. smaller eraser *automatically* than changing scale back and forth. As you say, workflow is what matters :) But it looks like this discussion is going nowhere, so EOT for me :)

Alexandre

Martin Nordholts wrote on Wed, Jul 22, 2009 at 03:05:38PM +0200:

On 07/20/2009 12:36 AM, Martin Nordholts wrote:

Does anyone have any suggestions on adjustments and additions to the default set of GIMP resources?

Thanks for the great feedback everyone. Summing it up, these are the current desired adjustments to the default set of resources.

Sorry for being late.

For photo touchup, what I'd like to see is fuzzy brushes with different intensity "curves" going to the outside.

I think it would be good to have 1] what we have now, 2] a curve that bumps intensity on the outside sooner (will have a more prominent full opacity in the middle) and 3] the inverse of 2].

So far I've been too lazy to make them but if there are other people missing them I'd be happy to make a set (please send private mail).

Speaking of brushes - brush rotation which currently requires a plugin (which is a little painful to use as it isn't interactive) is high on my wishlist.

Since I'm wishlist-spamming anyway, what I'd also like is fuzzy brushes with adjustable center (full intensity not in the middle). And stretchable in one dimension. I guess what I need is a quick capability to iwarp brushes. BTW, iwarp rocks.

Martin

Hi,
shirakawa.akira@gmail.com (2009-07-22 at 1218.30 +0200):

Martin Nordholts wrote:

I get your drift, but is it really reasonable to force a user to scale a say 250px brush to 3px if that is what he desires? It might be, but I don't think it is with our current scaling mechanism. What do you think

Regarding this, as an user (and not a programmer), I've always wondered why in the case of vector brushes a "scaling" setting is used instead of fiddling directly (and easily) with their size.

I avoid scale whenever I can, so for vector brushes I just use the brush editor. And I would wish any other brush would be "editable". In other words, support "pixmap" as "shape" for the editor, or some other solution instead of the current mix of methods.

GSR

Hi,

On Wed, 2009-07-22 at 23:54 +0200, GSR - FR wrote:

I avoid scale whenever I can, so for vector brushes I just use the brush editor.

Scaling a vector brush from the tool options is equivalent, at least from an implementation point of view, to changing its size in the brush editor.

Sven

Hi,

On Tue, 2009-07-21 at 18:53 -0400, Rob Antonishen wrote:

One reason to keep some image hose brushes in the default set is just to demonstrate that gimp supports them! I participate in a web forum for amateur cartography, and one of the most common requests is how to use tubes with photoshop. Most are extremely impressed that this capability exists in Gimp.

Sure, but then we should ship a useful image hose brush. There are actually a few useful ones in the standard distribution and they can stay. Pepper however is not an image hose. It's not interesting as an example, it doesn't show off any outstanding capabilities, it's quite likely never going to be used.

Sven

Hi,

On Wed, 2009-07-22 at 12:10 +0200, Martin Nordholts wrote:

On 07/20/2009 06:19 PM, Emil Assarsson wrote:

What I really miss is to be able to remove brushes that I don't need and sort/group the ones I use a lot. Maybe it would be better that most - if not all - of the brushes where copied to the users profile as a default instead of being static.

I agree with that we should copy the standard brushes to the user profile when the profile is created, just as we do with the default tags. Users/distros/installers wanting to use the read-only brushes for some reason could manually add "/usr/share/gimp/2.0/brushes" the brush path.

Unless someone disagrees here I might actually hack on this soon.

We discussed this before and came to the conclusion that it's a bad idea. What should be done instead of polluting the user directory with such copies is to create a copy transparently whenever the user edits a system resource. And there should be the possibility to easily hide system resources. The new tags system should help with this. Being able to hide resources by adding a 'hidden' tag was one of the reasons for adding tags in the first place.

Sven

Hi,
sven@gimp.org (2009-07-23 at 0031.55 +0200):

On Wed, 2009-07-22 at 23:54 +0200, GSR - FR wrote:

I avoid scale whenever I can, so for vector brushes I just use the brush editor.

Scaling a vector brush from the tool options is equivalent, at least from an implementation point of view, to changing its size in the brush editor.

That is a technical detail, as technical as Gimp having done brush scaling for some time before it even got scale widget ("side effect" of tablets and pressure mapping, it had to scale brushes, whatever way it was done then or now).

The points are the separate GUI, the mental maths required or the "try and error" workflow until you find the right size for brush changes, which are the issues the user has to cope with; versus a(n unified) pixel size control (currently non unified as it only works for vector ones, leaving pixmaps in the tiresome usage mode).

GSR

Hi,

On Thu, 2009-07-23 at 00:51 +0200, Martin Nordholts wrote:

We could either introduce a complex system to allow the user to delete system resources, or we could make it simple for ourselves and the user and just initialize the user dir with a set of default resources. I don't understand why we have to solve this in a complex way.

Go and read the archives then.

One reason is that we would also have to add a way to get the deleted system resource back. So we can as well use the tags system that was added for exactly this purpose and mark the system resource as hidden.

Another reason is that it is not reasonable to duplicate the system resources in the folders of all users.

Another reason is that it becomes a nightmare when the user updates to the next GIMP version which may ship with a different set of resource files.

Sven

Hi,

On Thu, 2009-07-23 at 00:48 +0200, GSR - FR wrote:

The points are the separate GUI, the mental maths required or the "try and error" workflow until you find the right size for brush changes, which are the issues the user has to cope with; versus a(n unified) pixel size control (currently non unified as it only works for vector ones, leaving pixmaps in the tiresome usage mode).

Well, you completely failed to explain this in your post. So the issue with the scaling from the tool-options is pixel size control? Wouldn't it be much better if we improved this then? We could for example show some numbers on the brush outline while the user adjusts the brush size. The brush editor is such an awkward thing taking up much needed screen estate. It should be our goal to get rid of it.

Sven

On Wed, Jul 22, 2009 at 10:47 PM, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:

2009/7/22 David Gowers wrote:

tools. When I think about it, I wonder whether such users ever get to

using

GIMP with any level of frequency or intensity, as IMO with the

global-brush

option off

Don't wonder -- they do. And I do too :)

(Speaking of which, the fact that tools presets don't save/restore scale value isn't helpful either.)

AFAICS that isn't a generally true fact. Works for me -- I just checked by choosing 1.06, saving that as a preset, setting it to 0.01 and loading the preset (which correctly reset scale to 1.0).
What version are you using (I'm using a recent git version, I'd guess that if there was a bug, any 2.7 version would have it fixed.) I guess also it is possible that one of your preset files is corrupt and causing problems.

Clear separation of default settings for different tools is such an

obvious

thing...

I agree with that. Unfortunately, having sensible, different defaults for different tools is in direct conflict with having an efficient, un-surprising workflow

Contrary to that I would yell every time I switched from Paintbrush to Eraser if I didn't have global brush disabled. It's way too convenient to use e.g. smaller eraser *automatically*

Hmm, I tend to forget that there are people who use mice for general GIMP work. I can see how this could actually save time then, if you only ever use Eraser with one or two different fixed brushes instead of switching a lot.

1) i agree with Alexia , get rid of all duplicates as  the "circle soft" and "circle hard" brush.   If may be scaled only 1 is needed

2) most flexible brushes are that created with the brush editor that can be not only resized but tilted, rotated,made harder or softer on the fly, even with keystrokes

But shapes are so limited : will be no possible add some simple shapes as spiral and ring ?

 to clarify "ring":  as circle or square or polygonal  BUT only the contour is stamped, and the thickness of the contour may be modified .(..with maximum thickness a "square  ring brush" is identical to a classic "square brush" ,with minimum is 1px outline of the contour)

3 about  animated brush, stars, grass,stones and dirty brushes may be a good example,   their possible use should be intuitive

4 brush tools would need better preset i make a example with the clone tool

As default for clone tool i see a HARD circle brush at 100% opacity, but the clone tool seldom works well used at full opacity with hard brushes... something as a SOFT round brush with a bit less  opacity would be a"better" default : "better" in most case and, even more relevant, for the first contact with the tool.

On Thu, 2009-07-23 at 03:53 +0000, Alchemie foto\grafiche wrote:

1) i agree with Alexia , get rid of all duplicates as the "circle soft" and "circle hard" brush. If may be scaled only 1 is needed

Yes. For script compatibility, either ship them, or have the brush-choosing code automatically interpolate, if a script asks for "footprint-36" and we have only "footprint" or maybe "footprint-200".

2) most flexible brushes are that created with the brush editor that can be not only resized but tilted, rotated,made harder or softer on the fly, even with keystrokes

Maybe there's a need for a structured brush name format? "footprint/titled 15-size 96.2/colours bg fg/spacing 150%/"

But shapes are so limited : will be no possible add some simple shapes as spiral and ring ?

Yes, with SVG brushes (I hope).

3 about animated brush, stars, grass,stones and dirty brushes may be a good example, their possible use should be intuitive

Careful! "intuitive" is a word people use to mean, "based on my experience, I could predict how to use it" but people have very varied backgrounds. We should leave "intuitive" for the Earl Peter Sikking, Duke of the Vision.

As default for clone tool i see a HARD circle brush at 100% opacity,

That's the default brush for everything I think.

PhotoShop displays a brush chooser with a slider for scale, iirc, and you can even put it on the toolbar, as you can with paintshop pro and krita.

Liam

On Thu, Jul 23, 2009 at 4:48 AM, David Gowers wrote:

(Speaking of which, the fact that tools presets don't save/restore scale value isn't helpful either.)

AFAICS that isn't a generally true fact. Works for me -- I just checked by choosing 1.06, saving that as a preset, setting it to 0.01 and loading the preset (which correctly reset scale to 1.0).
What version are you using (I'm using a recent git version, I'd guess that if there was a bug, any 2.7 version would have it fixed.)

Indeed this seems to be fixed in most recent git build. The version I'm using at home is git from April or so.

Contrary to that I would yell every time I switched from Paintbrush to Eraser if I didn't have global brush disabled. It's way too convenient to use e.g. smaller eraser *automatically*

Hmm, I tend to forget that there are people who use mice for general GIMP work. I can see how this could actually save time then, if you only ever use Eraser with one or two different fixed brushes instead of switching a lot.

I use both mouse and stylus, whatever works better for a particular case.

Alexandre

Hi,

On Thu, 2009-07-23 at 01:16 +0200, Martin Nordholts wrote:

Another reason is that it is not reasonable to duplicate the system resources in the folders of all users.

How exactly is this unreasonable in 2009? Compared to the amount of images we can expect a user to have based on our product vision, copies of default resources is negligible.

I don't see how anything that was unreasonable some years ago becomes reasonable in 2009.

Another reason is that it becomes a nightmare when the user updates to the next GIMP version which may ship with a different set of resource files.

It's not trivial to deal with this, but it's not exactly hard either, whatever heuristics we come up with. Special casing treatment of so called system resources all over the place is a much bigger nightmare that dealing with a one-time migration.

Then please explain how you would deal with this. It is completely simple and deterministic to deal with if we just allow the user to hide system brushes, but incredibly hard if we have to deal with copies from earlier installations. How would you fix a broken brush after it has been copied to the user dir? How would you deal with improved/changed tags? How do you deal with an overhaul of the system brushes?

Sven

> As default for clone tool i see a HARD circle brush at

100% opacity,

.................................

That's the default brush for everything I think.

Exact ! Are exactly the same !!
this demonstrate beyond doubts that current defaults are wrong.

Should be obvious that the pen tool , the brush tool and the clone and healing tools are different tools with a different use ...and so they require 3 quite different defaults

NOTE , Default is very important for the first impression of a tool or filter If default is bad chosen the first user sensation will be of a crappy or cryptic tool on the contrary better chosen default may give a good impression of a even buggy tool

I may well understand that developer have no time for "the search for the best defaults" but maybe is here that users may help developers

...about animated brush, stars, grass,stones and dirty brushes may be a >good example, their possible use should be intuitive

.......

Careful! "intuitive" is a word people use to mean, "based on my experience, I could predict how to use it" but people have very varied backgrounds. We should leave "intuitive" for the Earl Peter Sikking, Duke of the Vision.

That is correct,in general
In the particular cases is just needed to use a animated "star" brush on a dark BG to guess its possible use...populate the sky of stars , similar but not identical

Same for "grass or stones" animated brushes

I see a different problem:

Is too difficult browsing brushes notice that there are 4 quite different types of of brushes mixed :

1 normal (Greyscale gbr that use FG and BG colors) 2 colored (RGB gbr with their own colours) 3 "nozzles" (or tubes, gih as you prefer call them) 4 Procedural

Obviously without guessing that the chosen brush is a "nozzle" may be hard use it at best, same for procedural brushes

Is missed a clear visible hints to distinguish ... for this tagging should help if not solve

-

Is too difficult browsing brushes notice that there are 4 quite different types of of brushes mixed

The brushes are clearly marked: notice the red and blue triangles in the bottom-right corners brush thumbnails? Red triangles indicate image tubes or "animated" brushes. Blue triangles are procedural--made via the brush editor. The ones that lack triangles are single pixmaps. Also the pluses indicate a larger or animated thumbnail is available by clicking and holding on a thumbnail. As for coloured brushes, all of the ones I've seen are coloured in the thumbnail, so they should be obvious.

Hi,

On Thu, 2009-07-23 at 22:07 +0200, Martin Nordholts wrote:

So, we can only add resources and tags that have never shipped with a previous version of GIMP to the migrated user dir. Finding this set of resources and tags is just a matter of maintaining data sets with resources and tags shipped with each version of GIMP and some hacking/scripting.

That would be error-prone, unreliable, a nightmare to maintain and extremely ugly from a software design point of view. How can you even consider this?

I admit this is not trivial, but it is my opinion superior to using tags the way you describe and treat system resources in a special way.

You yourself ask for treating system resources specially since you just admitted that we need to maintain data sets only for the purpose of migrating to future versions. It would be much cleaner if we just marked a system resource as deleted instead of copying it in the first place and then deleting it. Whether this is actually done using tags or in a different way is another question. But since we have tags now, it seems like the best solution to use this system. After all that is what it was designed for.

Sven

Is too difficult  browsing brushes notice that

there are 4 quite different types of  of brushes mixed

The brushes are clearly marked: notice the red and blue triangles in
the bottom-right corners brush
thumbnails?   Red triangles indicate image tubes or "animated" brushes.  Blue triangles are
procedural--made via the brush editor.  The ones that lack triangles
are single pixmaps.  Also the pluses indicate a larger or animated
thumbnail is available by clicking and holding on a thumbnail.
As for coloured brushes, all of the ones I've seen are coloured in the
thumbnail, so they should be obvious.

i know but only initiates notice , most new users not (Except for the colored brushes, their difference is more visible and obvious)

A default option to see brushes listed for type will solve (see such option will make clearer that are different types )

Hi,

On Fri, 2009-07-24 at 10:33 +0200, Martin Nordholts wrote:

Whatever approach we take will require some dedicated code for managing system/default resources. My conclusion is that being forced to deal with this at migration time is less messy and keeps problems more local than spreading special treatment of system resources and tags throughout the rest of the system.

What is the migration time? You would have to deal with this on each and every start of GIMP. System resources may have changed, due to a minor or micro GIMP update or because the system maintainer added or removed resource files. This cannot be handled easily if we follow your approach and the result is a total mess.

Let's look at where we would need to have special treatment of tags and resources if we take your approach. Below, I will use the term "system resource" and "read-only resource" interchangeably since the problem we are trying to solve is not strictly limited to system resources, but the awkwardness of read-only resources in general.

* We would have to treat deletion of normal resource and read-only resources differently

Why? We can hide normal resources as well. Perhaps it even makes sense to allow the user to decide whether to delete or only mark as hidden. I'll leave it up to the UI team to decide that.

* We would have to treat editing of normal resources and read-only resources differently

Sure, but that is rather simple. Just make a copy and auto-hide the read-only resource.

* When editing a read-only resource we would have to mark the read-only resource as deleted to give the user the impression that it was the read-only resource he edited

See above. You are using your arguments multiple times.

* In the above case, we would have to transfer tags from the read-only resource to the copied resource * When presenting the tag cloud we would have to make sure the tag we use to represent deletion is not shown as we can only show tags assigned by the user or the resource package designer

Yes. How is it difficult to not list tags that are associated to objects that have the tag gimp:hidden associated with them. Doesn't the current code even already allow that? We did definitely talk about this when the tag system was designed.

* When exporting tags, we would have to make sure not to export deleted resources and/or the tag that represents deletion, i.e. it is not just a matter of dumping a subset of tags.xml

Easy enough to skip resources that have the gimp:hidden tag.

If we use my approach, we would have none of the above special casing, and we would also get rid of these issues:

* A user would have all his resources in one place, his user dir, instead of spread across the system * We can get rid of code that already now treats read-only resources as special (i.e. presents a brush as read-only in the brush editor)
* Long-term, we might even get rid of some low-level programmer adapted Preferences namely the Folders page and sub pages

To me, your approach is at least 10 times more messy and I don't understand why you would want to introduce all this special treatments and hacks in GIMP. I'm sure the above list of issues is not even complete as there surely are issues I have not thought about.

Simply because it is absolutely unacceptable to copy system resources to the user directory for no good reason. I am not going to maintain a software that does this. I would not any longer be proud of the GNU Image Manipulation Program if it started to do such things (again).

Also, you keep saying that the original intent for tags was to allow deletion of system resources. This might be true, but are you really meaning that the tagging system that eventually evolved is suitable for this? It does not seem like it since you now admit yourself that using tags to mark system resources as deleted might not be the best idea.

I think it is the best idea. Someone might have a better idea and that's what I admit that it might not be the best. But it definitely is the best idea that is being discussed right now.

Sven

On Fri, Jul 24, 2009 at 2:31 PM, Martin Nordholts wrote:

On 07/24/2009 01:10 PM, Martin Nordholts wrote:

As convinced you are that your approach is better than mine, I'm equally convinced my approach is better then yours.

I would like to add that if the ongoing brush dynamics and tool options redesign discussions end with a solution where editing of actual brush files is not necessary, then this whole discussion is obsolete. But as long as that file writability matters for resources, then what we have now is broken and needs to be fixed somehow.

Actually, this is the key point of this discussion and IMHO the RIGHT WAY(TM) to solve this. Editing resources during use should not require write access. Saving the changes should. Use tweaking should be a different level action than actual editing. Its extremely annoying if use level tweaking messes up your resource. If there's quiet auto saving, that should go away. Edit action should be available for writable ones and Duplicate & edit(possibly a quiet one) for non-writable ones and should be different from tweaks you can save in tool presets.

Both solutions on the table suck now. Copying system resources to the user would create two copies, on a single user system. in a system with A LOT of users, like a large family, say 5 users, would multiply the resources 5 times and say the head of the family likes to install resources system wide so the family can just use them... Or a better case. Small business has a set of "corporate" resources they want to be available to all the users of the terminal server. Those resources can be quite big. Copying them is a bad idea.

Using tags to hide system brushes does not simply solve the problem of editing not writable resources.Hiding an edited system resource is pointless. However, using a Hide operation for any brush allowing user to organize his/her brushes and only offering delete for writable ones does solve the organization problem. If mass hide is possible, the issue of getting them out of the way is solved.

I think the time would be better spent making the resource tweaking independent from the writabillity of the resource than on either of those proposals(Tag to hide resources will be needed anyway if we want to auto-hide obsolete resources, so getting that done would be needed anyway).

--Alexia

hi,

from a long-term perspective, i expect resources to be shared easily 'on the cloud', with each resource item identified by a GUID.

Then, the read-only system files are just a local cache of some of the available resources on the internet. Also from this perspective, it becomes strange to hide resources - it's rather that a subset of seamingly infinite resources gets pulled into the user's workspace.

The mechanism to proliferate updated resources would be the same as searching for new resources -- initiated by the user. A hint could be shown that a certain new brush is _intended_ to replace an old one, but the replacement should not be done automagically. After all, these are actually two different resource items.

Martin Nordholts schrieb:

I would like to add that if the ongoing brush dynamics and tool options redesign discussions end with a solution where editing of actual brush files is not necessary, then this whole discussion is obsolete. But as long as that file writability matters for resources, then what we have now is broken and needs to be fixed somehow.

if tweaked resources are to be shared, too, then it doesn't make a difference other than that potentially two files have to be shared in case adjustments are separated from the brush data.

hope i'm not too far off ;)

peter

hi,

On Fri, Jul 24, 2009 at 2:59 PM, Alexia Death wrote:

Actually, this is the key point of this discussion and IMHO the RIGHT WAY(TM) to solve this. Editing resources during use should not require write access. Saving the changes should. Use tweaking should be a different level action than actual editing. Its extremely annoying if use level tweaking messes up your resource.  If there's quiet auto saving, that should go away. Edit action should be available for writable ones and Duplicate & edit(possibly a quiet one) for non-writable ones and should be different from tweaks you can save in tool presets.

Let me extend your idea a bit. Every time selecting a resource, a copy of it could be created (in memory, not on physical file). User could edit resource in any way she likes without affecting originally selected resources. GIMP could actually maintain a current-session-brush, current-session-pattern, etc.: when finishing session save currently selected resources (one for each resource type). When starting session only one resource for each type would need to be loaded in synchronously. All other resources could be loaded in background (improve startup time).

Aurimas Juška wrote:

Let me extend your idea a bit. Every time selecting a resource, a copy of it could be created (in memory, not on physical file). User could edit resource in any way she likes without affecting originally selected resources. GIMP could actually maintain a current-session-brush, current-session-pattern, etc.: when finishing session save currently selected resources (one for each resource type). When starting session only one resource for each type would need to be loaded in synchronously. All other resources could be loaded in background (improve startup time).

Getting back to the start of this discussion --

I am in talks with the new mantainer of a very popular brazillian GIMP comunity portal this week (Guilherme coordinating www.ogimp.com.br with ~20.000 unique visitors a day)-- he has resources of his own which could be made available eitehr in GIMP or in gimp-data-extras . Moreovr a "call for help" on these online comunities could result in a large number of contributions from Brazillian artists (most with poor English comunication skills)

So it ocurred to me: maybe we could make a "call for contributions" for new resources, and some open voting mechanism. The top rated artwork would make it into GIMP as patterns and brushes, and some more could be made available in gimp-data-extras .

The last call for contributions of this kind we had, taht I rememebr, was for the gimp 2.2's splash screen, and had a good number of nice submitions.

Guilerme, me, and other brazillian Free Graphics software contributors could help to assemble the needed structure for voting + contributing in a few weeks - we could set some prdefined tags to help orient the contributions (like natural brushes, clip-art, and so on) and populate the gimp-data-extras package with them.

(Of course I am talking about itnernational contributions, not only .br ones - some 'call for clip-art' well placed announcements could make it)

So, any objections to something like this?

If anyone think this might have drawbacks an alternative would be to make a low-profile 'trial' and put the results in a branch for review.

js ->

On Sunday 19 July 2009, Martin Nordholts wrote:

Hi,

With the integration of tagging support in GIMP we have a mechanism that allows us to organize resources (brushes, patterns, palettes, and gradients). This enables us to add a bigger set of default resources.

Not being an artist myself makes me rather useless for this task. To get things rolling I thought I'd start a discussion on what a better set of default resources would be.

A few things are clear:

* The new default resources must fit the product vision [1] * The resources must be very general in nature * We can't have a huge set of resources since we need to keep the size of the tarball within reasonable limits * We not only need resources, we also need to assign tags to them

I think we at least should:

* Add larger variants of the circle and fuzzy circle brushes, say 50, 100, 250 and 500 px * Try to get rid of the Pepper, Sparks and Vine brushes in a backwards compatible way

Does anyone have any suggestions on adjustments and additions to the default set of GIMP resources?

/ Martin

[1] http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision

On Sun, Jul 19, 2009 at 6:36 PM, Martin Nordholts wrote:

 * Add larger variants of the circle and fuzzy circle    brushes, say 50, 100, 250 and 500 px

I really wish the brush system was improved to make this unneccessary. We should be able to smoothly scale vector-ish brushes (a circle is a pretty simple primitive) and avoid wasting so much space on duplicated brushes like this. Circle and Fuzzy Circle should be two brushes.

Sparr wrote:

Circle and Fuzzy Circle should be two brushes.

I've been following this conversation with a bit of interest, but I've noticed that a lot of discussion has echoed this sentiment. Why should there be two circle brushes? Couldn't there be a single circular brush with "fuzziness" as an attribute of that brush that you could adjust with a percentage slider?

-Jason

On Tue, Jul 28, 2009 at 5:11 PM, Jason van Gumster < jason@handturkeystudios.com> wrote:

Sparr wrote:

Circle and Fuzzy Circle should be two brushes.

I've been following this conversation with a bit of interest, but I've noticed that a lot of discussion has echoed this sentiment. Why should there be two circle brushes? Couldn't there be a single circular brush with "fuzziness" as an attribute of that brush that you could adjust with a percentage slider?

..
You can already do that for any circle brush. The attribute is called 'Hardness'
We would not seriously consider such a level of reduction because it's bad for usability -- it's much more painful for the user to adjust a slider each time they want to paint with different hardness, than to just switch between two brushes.

I personally think there should be a few different brushes in a basic set.

* 'fill' brush (large, hard edge) -- because often painting is more convenient than select+fill
* 'sharp' brush (moderate size -- say 25px (== radius 12), hardness 1.0) (general purpose)
* 'fuzzy' brush (for blending)

If we moved towards Akira's idea of moving brush-related tool options into brushes themselves, I would also suggest * a single pixel, Hard Edge (as in, pencil-style sharp rendering) brush for pixel.precise adjustments.

On Tue, 2009-07-28 at 20:21 +0930, David Gowers wrote:

[...]

You can already do that for any circle brush. The attribute is called 'Hardness'
We would not seriously consider such a level of reduction because it's bad for usability -- it's much more painful for the user to adjust a slider each time they want to paint with different hardness, than to just switch between two brushes.

The answer there is saved settings for brushes, and possibly a "my brushes" pallette window of brushes I've saved, with quick keystrokes to go between them.

Liam

David Gowers wrote:

You can already do that for any circle brush. The attribute is called 'Hardness'

Thanks for pointing this out. I'd overlooked that.

We would not seriously consider such a level of reduction because it's bad for usability -- it's much more painful for the user to adjust a slider each time they want to paint with different hardness, than to just switch between two brushes.

I don't see why that necessarily must be the case. This is where you can have savable brush presets. Furthermore, why can't there be a more interactive means of adjusting hardness (and brush size for that matter)? GIMP already had the capability to use keyboard shortcuts to interactively adjust brush size. Why couldn't shortcuts to added to quickly adjust hardness?

-Jason

On Thu, 2009-07-23 at 10:18 +0930, David Gowers wrote:

Hmm, I tend to forget that there are people who use mice for general GIMP work. I can see how this could actually save time then, if you only ever use Eraser with one or two different fixed brushes instead of switching a lot.

for what it's worth, I only ever (pretty much) use a single global brush, shared with as many tools as possible... I don't have a graphics tablet... I bind 2 and 3 to shrink/grow the (vector) brush, and @ and # (shift-2 and shift-3 on my keyboard) to have them grow and shrink more, and $ and % to have them get softer and harder.

For most of what I do, I only need the one brush (sometimes I change its shape though). Probably if I had a graphics tablet I'd feel different.

When I've wanted to do more "natural" art, the brushes in gimp were all much too tiny to be of any use really -- 50 to 300 pixels in diameter is a useful range for bitmap brushes I think, for making new art that can be printed, e.g. A4/US Letter at 300dpi.

Liam

Hi,

On Fri, 2009-07-24 at 13:10 +0200, Martin Nordholts wrote:

What is the migration time? You would have to deal with this on each and every start of GIMP. System resources may have changed, due to a minor or micro GIMP update or because the system maintainer added or removed resource files. This cannot be handled easily if we follow your approach and the result is a total mess.

We don't need to handle this. We don't need to adapt GIMP to a typical multi-user environment found at universities for example because those are not our target audience. Handling this at user dir migration to a new version is fine.

Of course we need to keep such multi-user environments in mind, even if they are not our main target. And apart from that, you get the same situation if the user herself installs an extra data package for GIMP system-wide by means of the packet management system of her Linux distro.

* We would have to treat editing of normal resources and read-only resources differently

Sure, but that is rather simple. Just make a copy and auto-hide the read-only resource.

* When editing a read-only resource we would have to mark the read-only resource as deleted to give the user the impression that it was the read-only resource he edited

See above. You are using your arguments multiple times.

These are not arguments, they are example of where we need to add special cases. The more of these, the bigger the mess. That the special cases all stem from the same design approach is not relevant.

Right, these are special cases and their number is important. Which is why I pointed out that you are using the same example multiple times only to increase the number of special cases. That is not a fair comparison, I am afraid.

GIMP has done it the way you proposed in the past and copied system resources to the user directory. This was ugly and caused lots of grief. Eventually we got rid of this mess and now you are proposing to undo this work and to reintroduce this ugliness? That's very disappointing.

Sven

Just checking to see if this is a gimp bug or whether I should look somewhere else.

I'm using 2.6.6 on Ubuntu Ibex Linux dell 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC 2009 i686 GNU/Linux

I switched from having the wacom device set up in xorg.conf to having a configuration in /etc/hal/fdi/policy/custom_wacom.fdi (attached).

I did this so I'd get plug and play, i.e. not have to restart X when I plugged in my tablet. That has worked fine. There's just two different problems.

1) If I plug it in after the gimp is already started it isn't recognized as a tablet, i.e. doesn't appear as an extended input device that can be configured and works only as a mouse. 2) If I plug it in before starting the gimp, it's recognized and works well, but if I unplug it before exiting the gimp, gimp will crash in a little bit.

Inkscape has exactly the same behavior including the crash.

Patrick

On Wed, Aug 5, 2009 at 12:26 AM, Patrick Horgan wrote:

1) If I plug it in after the gimp is already started it isn't recognized as a tablet, i.e. doesn't appear as an extended input device that can be configured and works only as a mouse. 2) If I plug it in before starting the gimp, it's recognized and works well, but if I unplug it before exiting the gimp, gimp will crash in a little bit.

Inkscape has exactly the same behavior including the crash.

This is a known issue, and exists because there is no agreed interface for X to tell applications about appearing and disapearing devices(there is DBUS, but im not sure if X sends the type notifications needed for this use) and no mechanism in the toolkits(in this case, GTK) to handle it, because its rather new for X to have appearing and disapearing input devices. Gimp sees what devices are available on startup and wont be aware of the devices added later. When you remove a device however, gimp(or rather GTK IIRC) will try to get data from a noinexisting device and crash. I quickly looked at the issue when I encountered it myself and it was quite above ma capabilities to fix, but I dont remember the details any more.

[Keeping quote below for reference]

The is another class of X11 errors that GIMP should survive:

when you have a view on another display, these days you can open an entirely new display, on a different computer. Works great as such, I use it regularly.

However, if you shut down that display (or the computer that it is running on, or the network or the ssh forwarder) while the view is in use, then GIMP crashes.

In both cases, the disappearing display and the disappearing device, what GIMP would need is a resource stack that is supposed to be unrolled on certain X11 errors. At the top of that cleanup stack should be a GIMP that is still running but has forgotten about the device or display that caused the error.

Martin

Alexia Death wrote on Wed, Aug 05, 2009 at 09:03:50AM +0300:

On Wed, Aug 5, 2009 at 12:26 AM, Patrick Horgan wrote:

1) If I plug it in after the gimp is already started it isn't recognized as a tablet, i.e. doesn't appear as an extended input device that can be configured and works only as a mouse. 2) If I plug it in before starting the gimp, it's recognized and works well, but if I unplug it before exiting the gimp, gimp will crash in a little bit.

Inkscape has exactly the same behavior including the crash.

This is a known issue, and exists because there is no agreed interface for X to tell applications about appearing and disapearing devices(there is DBUS, but im not sure if X sends the type notifications needed for this use) and no mechanism in the toolkits(in this case, GTK) to handle it, because its rather new for X to have appearing and disapearing input devices. Gimp sees what devices are available on startup and wont be aware of the devices added later. When you remove a device however, gimp(or rather GTK IIRC) will try to get data from a noinexisting device and crash. I quickly looked at the issue when I encountered it myself and it was quite above ma capabilities to fix, but I dont remember the details any more.

Hi,

On Wed, 2009-08-05 at 08:45 -0400, Martin Cracauer wrote:

[Keeping quote below for reference]

The is another class of X11 errors that GIMP should survive:

when you have a view on another display, these days you can open an entirely new display, on a different computer. Works great as such, I use it regularly.

However, if you shut down that display (or the computer that it is running on, or the network or the ssh forwarder) while the view is in use, then GIMP crashes.

In both cases, the disappearing display and the disappearing device, what GIMP would need is a resource stack that is supposed to be unrolled on certain X11 errors. At the top of that cleanup stack should be a GIMP that is still running but has forgotten about the device or display that caused the error.

No, that is not how this should be addressed. GIMP doesn't even know that it's running on X11. This needs to be handled in GTK+. As far as I know, support for hotplug of input devices is still lacking from GTK+. Support for a disappearing display is available though. So if GIMP is crashing there, then you should file a bug report and attach a stack trace of that crash. We might have to connect to GdkDisplay:close and deal with this on the GIMP side.

Sven

wino wrote on Wed, Aug 05, 2009 at 05:12:58PM +0200:

Martin Cracauer wrote:

[Keeping quote below for reference]

The is another class of X11 errors that GIMP should survive:

That was my first reaction on seeing the Wacom issue.

It sounds to me like a memory object related to the resource has been distroyed and gimp is accessing a now invalid pointer.

No, it's not a segfault.

It is errors from system calls (as in return -1, set errno) when reading the pipes connecting GIMP through the X11 server to these devices and displays.

If this crashes gimp it is a messy bug that reveals insufficient error handling. This sort of exception should be trapped and dealt with without gimp falling on it's arse.

But it's messy. X11 error handling is often left at the default error handlers (which exit the application). Explicitly dealing with them will require you to sort out what exactly the error condition was connected to, whether there was a device that caused this and whether it is optional. Then, if it was a device or display that is allowed to go away, you need to clean up the application (GIMP) to remove entries that tell GIMP to communicate with these devices (such as the display draw routine drawing on all displays it knows about) to make them forget about the optional device that reported an error.

When you are finished with that you will also have to deal with the fact that errors might come from other conditions than these devices going away. Presumably you'd want to attempt a recovery of some sort in some cases. Just throwing errnous devices out is better that exit(), though.

To make the mess complete, X11 error handling inside a GTK+ application isn't exactly the same thing either.

Martin

/gg

when you have a view on another display, these days you can open an entirely new display, on a different computer. Works great as such, I use it regularly.

However, if you shut down that display (or the computer that it is running on, or the network or the ssh forwarder) while the view is in use, then GIMP crashes.

In both cases, the disappearing display and the disappearing device, what GIMP would need is a resource stack that is supposed to be unrolled on certain X11 errors. At the top of that cleanup stack should be a GIMP that is still running but has forgotten about the device or display that caused the error.

Martin

Alexia Death wrote on Wed, Aug 05, 2009 at 09:03:50AM +0300:

On Wed, Aug 5, 2009 at 12:26 AM, Patrick Horgan wrote:

1) If I plug it in after the gimp is already started it isn't recognized as a tablet, i.e. doesn't appear as an extended input device that can be configured and works only as a mouse. 2) If I plug it in before starting the gimp, it's recognized and works well, but if I unplug it before exiting the gimp, gimp will crash in a little bit.

Inkscape has exactly the same behavior including the crash.

This is a known issue, and exists because there is no agreed interface for
X to tell applications about appearing and disapearing devices(there is DBUS, but im not sure if X sends the type notifications needed for this use)
and no mechanism in the toolkits(in this case, GTK) to handle it, because its rather new for X to have appearing and disapearing input devices. Gimp sees what devices are available on startup and wont be aware of the devices
added later. When you remove a device however, gimp(or rather GTK IIRC) will
try to get data from a noinexisting device and crash. I quickly looked at the issue when I encountered it myself and it was quite above ma capabilities to fix, but I dont remember the details any more.

Sven Neumann wrote:

Hi,

On Wed, 2009-08-05 at 08:45 -0400, Martin Cracauer wrote:

[Keeping quote below for reference]

The is another class of X11 errors that GIMP should survive:

when you have a view on another display, these days you can open an entirely new display, on a different computer. Works great as such, I use it regularly.

However, if you shut down that display (or the computer that it is running on, or the network or the ssh forwarder) while the view is in use, then GIMP crashes.

In both cases, the disappearing display and the disappearing device, what GIMP would need is a resource stack that is supposed to be unrolled on certain X11 errors. At the top of that cleanup stack should be a GIMP that is still running but has forgotten about the device or display that caused the error.

No, that is not how this should be addressed. GIMP doesn't even know that it's running on X11. This needs to be handled in GTK+. As far as I know, support for hotplug of input devices is still lacking from GTK+. Support for a disappearing display is available though. So if GIMP is crashing there, then you should file a bug report and attach a stack trace of that crash. We might have to connect to GdkDisplay:close and deal with this on the GIMP side.

Sven

Whatever the detail, doesn't this indicate insufficient error trapping? Both in gimp and the underlying GTK+ .

If gimp is using a pointer to a resource that has been deleted the exception should be trapped and handled cleanly. It should not crash gimp. If neither is trapping the condition both are at fault.

/gg

Martin Cracauer wrote:

wino wrote on Wed, Aug 05, 2009 at 05:12:58PM +0200:

Martin Cracauer wrote:

[Keeping quote below for reference]

The is another class of X11 errors that GIMP should survive:

That was my first reaction on seeing the Wacom issue.

It sounds to me like a memory object related to the resource has been distroyed and gimp is accessing a now invalid pointer.

No, it's not a segfault.

It is errors from system calls (as in return -1, set errno) when reading the pipes connecting GIMP through the X11 server to these devices and displays.

If this crashes gimp it is a messy bug that reveals insufficient error handling. This sort of exception should be trapped and dealt with without gimp falling on it's arse.

But it's messy. X11 error handling is often left at the default error handlers (which exit the application). Explicitly dealing with them will require you to sort out what exactly the error condition was connected to, whether there was a device that caused this and whether it is optional. Then, if it was a device or display that is allowed to go away, you need to clean up the application (GIMP) to remove entries that tell GIMP to communicate with these devices (such as the display draw routine drawing on all displays it knows about) to make them forget about the optional device that reported an error.

When you are finished with that you will also have to deal with the fact that errors might come from other conditions than these devices going away. Presumably you'd want to attempt a recovery of some sort in some cases. Just throwing errnous devices out is better that exit(), though.

To make the mess complete, X11 error handling inside a GTK+ application isn't exactly the same thing either.

Martin

oops, cross post with Martins reply to my earlier message that missed the ML due to wrong sender.

Thanks for the detailed account , Martin.

So whatever the thorough way to completely recover from such an error (which sounds like hard work), should not something be done to prevent gimp just dumping out and losing any current work changes?

/gg

Hi,

On Wed, 2009-08-05 at 19:39 +0200, gg wrote:

Whatever the detail, doesn't this indicate insufficient error trapping? Both in gimp and the underlying GTK+ .

Sure, we could use gdk_error_trap_push() and pop() around every GTK+ call, but that would blow up our code unreasonably. GDK itself does such error trapping in a few spots. Feel free to look at the described crashes and check if the GTK+/GDK code can be improved to handle them.

If gimp is using a pointer to a resource that has been deleted the exception should be trapped and handled cleanly. It should not crash gimp. If neither is trapping the condition both are at fault.

It is considered not feasible to implement such 'exception handling' in C. Even with a language that supports it, you can't reasonably handle all unexpected exceptions in a large project.

Sven