GNOME Bugzilla – Bug 322176
Add VBR brushes to default installation
Last modified: 2007-03-15 20:04:41 UTC
Gimp has the option for scalable brushes but there are none in the default installation, and therefore users are unaware of them. I created a set of VBR brushes for GIMP: They are named in such a way that they will appear in the beginning of the list. They have different names than the GBR brushes. I understand some scripts require the current GBR brushes: for now they can simply be kept along the old ones. Keyboard shortcuts are needed to allow users to rescale the brushes easily. I suggest photoshop-compatible shortcuts - they are both good shortcuts in and of themselves and will help PS users to transition. [ - decrease size ] - increase size Also, a couple more which do not exist in PS: Shift+[ - decrease more Shift+] - increase more The Brush set is attached.
Created attachment 55111 [details] VBR Brush Set
Didn't you report this already?
Yes, in bug #322028. As explained there, the brushes should be attached to the existing bug report that deals with this problem. The keyboard shortcuts are already implemented. Closing as duplicate. *** This bug has been marked as a duplicate of 322028 ***
Argh, I meant to close as duplicate of bug #157506. But thinking about it, this proposal is somewhat different from the one in bug #157506. We should try to come to a decision here. Do we want to replace brushes or do we prefer to add new ones? Also, the VBR brushes probably need to be installed into the user directory so that they are editable.
Reopening, fixing Component and setting on the 2.2 milestone as an alternative to bug #157506.
Raising priority to Urgent, because this bug report requires revisiting in light of the upcoming 2.4 release.
I suggest that we review the set of proposed brushes, add them and make sure that they are being copied to the user directory during user installation.
I've looked over these 28 brushes, not yet in exhaustive detail, and my impression is that they are pretty good -- not perfect matches for the basic gbr brushes that come with GIMP, but, with perhaps a couple of minor changes, quite similar. However, I don't agree with comment #3 concerning what to do with them. First, I don't think we should be installing stuff into the user's personal directories. It violates personal space, and it creates a problem of what to do in a re-install. Second, if we did so, the result would be that the brushes dialog shows two groups of 28 nearly-identical brushes, some of which are modifiable, others not. That's annoying and weird. I think if we are going to use these, they should go into the main GIMP brushes folder, and the user should have to duplicate them in order to modify them. If this is done, the corresponding GBR brushes should go away. If that isn't acceptable, then I think we should defer this to the next version of GIMP, when hopefully we will finally have categorized resources, with control over which ones are displayed in the selectors.
If we remove the GBR brushes, we have to make sure that the names of the new brushes match the ones they are supposed to replace or lots of scripts will break.
I have created .vbr brushes for all circle, fcircle, DStar and callig .gbr brushes. I made them as good as I could; being consequental. They are named the same as their .gbr counter parts, both the filename and the brush name.
Created attachment 73251 [details] obsolete
Created attachment 73260 [details] The .vbr brushes; named as their .gbr counterparts. The previous archive accidentally contained a backup file.
Created attachment 73261 [details] [review] The data/brushes/Makefile.am changes. Contains the appropriate changes to data/brushes/Makefile.am Also contains a indentation fix for docs/Makefile.am which I discovered when I let Anjuta import GIMP code.
Hm, now we have two sets of vbr brushes which are supposed to replace the current ones... see bug #bug #157506. Is the attachemnt for this bug derived from the other set?
Oh crap, how could I miss that someone already did this work. I thought the only reason that this patch was not finialized was because no one yet had done a good GBR -> VBR conversion. These brushes are made from scratch, I suppose it doesn't matter namely if you take this set or the other set. So the only real effort that is needed before the GBRs are replaced is for someone to verify that no scipt breaks?
I'd like to propose a less invasive change. We should IMO keep the brushes that we have, if only for backward compatibility. The changes we should do instead are: (1) Add a small set of VBR brushes to the distribution, at the very least a sharp round brush and a sharp fuzzy brush. (2) Put these files into the users brush folder on user installation so that they are editable. (3) Make one of the VBR brushes the default brush. (4) Place VBR brushes at the top of in the brushes list and grid views to make them more prominent. This should be doable by changing the sorting routine. If possible, we should also change the brush preview renderer to include the brush size in the preview. That's a different thing though and not strictly related.
Since the scripts uses the name of the brushes I think we should convert all GBR brushes to VBR brushes where possible (as done by the patch I submitted here) Having all brushes as VBR will ease implementation of a Master Radius slider, and other not-still-thought-of features, since the VBR brushes are more versatile than the GBR ones. Also, if we copy brushes to the user folder, there could be problems with future scripts making use of those brushes (think of the KISS principle). However, without a Master Radius slider, copying a few brushes to the home directory of the user is probably the best, for now, solution. To summarize, I agree with (2) (for now), (3) and (4), but not (1).
Well, we can of course delay this until 2.6 if you want to insist that all brushes need to be replaced. We can't replace the GBR brushes with VBR brushes because then you can't rely any longer that the brush won't be changed and scripts will break when they use one of the changed brushes. No idea what a Master Radius slider would be. That's the first time I hear this term being used.
I didn't mean that all VBR brushes should be copied to the home directory. (2) would only apply to very few new (probably two) brushes, as you suggested. The reason why I think we should convert the brushes to VBR, is for potential future features. For instance a Master Radius slider. A Master Radius slider would allow one to change the radius of a brush temporarily, i.e. without changing any files (it would be possible to change read only brushes temporarily as well). Think of it as the Master Volume on your speakers. You can still adjust the volume for each program (XMMS, Banshee etc) but the Master Volume is the main volume, that can be used for quick fine tuning and temporary adjustments. There might never be a Master Radius slider, but there might be another feature that would profit from the brushes being VBR, which is why I think we could do the VBR conversion now, instead of postponing it. My point is that there is no point as I see it in having the brushes in a restrictive format, when there exists an alternative.
Can we hide the duplicated GBR brushes, so that only the plugins and scripts can use/see them? Something like a system brushes folder.
No, we can't hide the duplicated brushes easily. But as far as I understand there are two proposals here. Either provide VBR brushes that replace the GBR ones, they would have the same name, be read-only and could be used from scripts just like the old brushes. The second proposal is to do a smaller change now and only add a few editable VBR brushes. We can still the replace the brushes later (2.6). Most probably the VBR format will turn out not to be sufficient anyway.
(In reply to comment #21) > No, we can't hide the duplicated brushes easily. But as far as I understand > there are two proposals here. Either provide VBR brushes that replace the GBR > ones, they would have the same name, be read-only and could be used from > scripts just like the old brushes. The second proposal is to do a smaller > change now and only add a few editable VBR brushes. We can still the replace > the brushes later (2.6). Most probably the VBR format will turn out not to be > sufficient anyway. Then you probably misinterpreted my suggestion, or more likely; I didn't express myself clearly enough. Allow me to make a third attempt :) I suggest that we: 1. Convert the current GBR brushes to the equivalent VBR brushes. NOTE: The VBR brushes would still be read-only, the only reason I think this should be done is to prepare for patches which could make use of the VBR brush format (like a Master Radius slider). 2. Add a new, home directory stored, and default selected VBR brush, as you suggested in comment #16. NOTE: We should name it so it becomes obvious that it is a home directory stored brush (I fail to come up with good names though). However, doing #1 in combination with #2 could probably lead to confusion, and it's not even sure #1 will ever become useful before a Brush code rewrite is made anyway, so I don't claim that this suggestion is the best, but at least want to make it available for consideration.
(In reply to comment #22) > > I suggest that we: > > 1. Convert the current GBR brushes to the equivalent VBR brushes. This is bug #157506. > > 2. Add a new, home directory stored, and default selected VBR brush, as > you suggested in comment #16. > > NOTE: We should name it so it becomes obvious that it is a home > directory stored brush (I fail to come up with good names > though). > I would suggest to postpone bug #157506 to gimp 2.6 and add some VBR brush as suggested in comment #16.
As we have a master brush slider now, we should probably do what Martin suggests.
Which suggestion from Martin do you mean exactly?
Since the scale slider does not affect the actual brush, I don't think we need to store any brush in the users home directory anymore. Simply replacing the GBR brushes with the VBR conversions (e.g. those provided by me) should be enough to close this specific bug.
Can I go ahead and replace the GBR brushes? From my point of view both this and bug #157506 would then be FIXED. I don't think it is necessary to provide home-directory provided VBR brushes because 1) The brush Scale slider makes size adjustments possible without the need for write access for the brushes. 2) The problems that needs to be solved would probably end up feeling dirty. 3) If a user is smart enough to be able to notice that the VBR brushes is read-only(, he is likely to note that in the Brush Editor), he will probably be smart enough to be able to figure out that he need to press the New Brush... button to create his own modifiable brush.
4) scripts do still get the unscaled original brush size (do they? or is this that did change because of the scale already?) Seems ok to me, at least.
I think we should go ahead and replace the brushes now. If that turns out to cause any problems, then we have at least some time left to fix them.
Fixed in trunk, revision 22129: 2007-03-15 Martin Nordholts <martinn@svn.gnome.org> Converted .gbr to .vbr brushes where possible. Fixes bug #322176 and bug #157506. * data/brushes/Makefile.am: Changed .gbr for .vbr-counterparts for converted brushes. * data/brushes/*circle.gbr: * data/brushes/*fcircle.gbr: * data/brushes/DStar*.gbr: * data/brushes/callig*.gbr: Removed. * data/brushes/Circle-*.vbr: * data/brushes/Circle-Fuzzy-*.vbr: * data/brushes/Diagonal-Star-*.vbr: * data/brushes/Calligraphic-Brush-*.vbr: Added.