GNOME Bugzilla – Bug 773003
New Brush Edit/Create instances | Proposal
Last modified: 2018-05-24 17:07:12 UTC
=== Brush Assets - Edit and Creation Flows On GIMP the brushes parametric and raster are showed together, in the same list on Brushes Dialog. This causes some issues when an user try to edit a brush: # If is parametric the brush open correctly the parametric brush editor; # If is raster the brush is opened also on parametric brush editor (evidently, isn't possible edit the raster here). Is curious note that the contextual is the same for the two kinds but it recognizes when is a parametric brush... the 'Open Brush as image...' is disabled. --- Simplifying the flow to create/edit raster brushes directly on the dialog lists If ideally, is fine, to have an unique dialog list to show parametric (.vbr) and (.gbr, .gih) brushes... is necessary to correct for any kind the way to edit them. The menu of these assets in my opinion must be modified in this way: # Divide the brush assets for category (raster and parametric). Would be interesting to have a default tag embedded and independent of user choices. # Each brush asset category enables the editing kind, for instance, raster brushes have a dedicated menu as an asset image. If is not possible to have, in the same dialog brush list, different contextual menus to parametric and raster brushes... to avoid this issue is necessary one with raster and another to parametric brushes. --- Contextual Menu and Brushes Menu | Raster and Parametric [1]Parametric Brush > \_New Parametric Brush... \_Edit this Parametric Brush... [2]Raster Brush > \_New Raster Brush > create by default an image with 256x256 px in grayscale, for instance. \_Edit Raster Brush (old Open Brush as image) --- Copy Brush Location > Show in File Manager > Delete Brush > --- Refresh brushes > If the user has a parametric brush selected on the list, is enabled [1] and is disabled [2] and vice-versa. The option Duplicate Brush and other options present in the menus only for the parametric kind are, essentially, shortcuts and I think that not so useful... these tasks aren't so repetitive in an usual GIMP session. == Fields to Author and License In the dialogs to build the .gbr, .gih and .vbr brushes on GIMP, is interesting to have two new fields: # Author Name # License == Tag Field | Default on binary archive Many brushes could be organized by designer in origin. When a brush is created the author could be organize the tags that each brush has by default. This feature is a great way to customize the author's sets and a facility to use the sets on GIMP. == Images of dialogs of brushes modified - Proposal I have written a document on gui.gimp.org: http://gui.gimp.org/index.php/Brush-assets#Brush_Assets_-_Edit_and_Creation_Flows
Hi Jose, That's a fine proposition. Here are some comments: 1/ I don't think we should divide the brush assets. Once created, from the painter's point of view (even when painter and creator are the same), one doesn't care at all *how* they were built. Parametric, raster, who cares? Only on creation side, one cares. In my opinion, brushes should be simply freely orderable. Right now it seems the order is totally static, which sucks. I'd like to drag and drop my favorite brush to the top of the list. 2/ Authorship, licensing and tag fields are a very good idea IMO. Actually there is already a tag feature, but I don't find it particularly usable (the filtering, tagging, everything feels like it could be better made). 3/ Instead of adding contextual menus with separate labels, what if when clicking "Edit this brush" on a raster brush, it opens the brush as image and also opens the Brush Editor, but showing only field which apply also on raster brush (i.e. brush name, authorship, license, tags…) as well as the shape: a raster brush would be a fourth shape "custom". Similarly creating a new brush and selecting the "custom" shape would open a new blank image.
(In reply to Jehan from comment #1) > Hi Jose, > > That's a fine proposition. Here are some comments: > > 1/ I don't think we should divide the brush assets. Once created, from the > painter's point of view (even when painter and creator are the same), one > doesn't care at all *how* they were built. Parametric, raster, who cares? > Only on creation side, one cares. > > In my opinion, brushes should be simply freely orderable. Right now it seems > the order is totally static, which sucks. I'd like to drag and drop my > favorite brush to the top of the list. Yes, my issue around to divide in two category has relation only with the possibility to exclude mistakes to try use parametric brush instances in the raster brush instances... But, I see also all together. > 2/ Authorship, licensing and tag fields are a very good idea IMO. Actually > there is already a tag feature, but I don't find it particularly usable (the > filtering, tagging, everything feels like it could be better made). > > 3/ Instead of adding contextual menus with separate labels, what if when > clicking "Edit this brush" on a raster brush, it opens the brush as image > and also opens the Brush Editor, but showing only field which apply also on > raster brush (i.e. brush name, authorship, license, tags…) as well as the > shape: a raster brush would be a fourth shape "custom". Yeah, is a good idea! This an opportunity to open in a future the discussion for a minimal visual editor also to raster brushes ;-) > Similarly creating a new brush and selecting the "custom" shape would open a > new blank image. Yes, this is flow very consistent and without meanders.
Someone in bug 772088 raised the question about multi-selection of brushes (when one has a lot of brushes and want to delete or tag a whole bunch together). I think this makes sense and could be integrated to your spec. Since selection is also used to set the current active brush, we'd have to discuss what happens when several brushes are selected. Which one is active? How do we show the difference? Finally I was wondering how the viewing should also be updated. If you have a lot of brush, you will want sometimes to show only some of them. It is already possible with tags, but I don't find the current GUI very usable. Also, just an idea, but wouldn't an artist want to create groups of brushes, not by type of brush, but for specific projects for instance? (like for this project, I use only these brushes, just like you will make color palettes for a given project) Well this can also be done with tags, so maybe I'm just duplicating the feature, but it always felt to me as though tags were more used for the type of brush. Anyway just bouncing ideas against you.
(In reply to Jehan from comment #3) > Someone in bug 772088 raised the question about multi-selection of brushes > (when one has a lot of brushes and want to delete or tag a whole bunch > together). I think this makes sense and could be integrated to your spec. > > Since selection is also used to set the current active brush, we'd have to > discuss what happens when several brushes are selected. Which one is active? > How do we show the difference? Now, when we select brushes or another image based asset on list dialogues views... this option is referred only to tag editing. > Finally I was wondering how the viewing should also be updated. If you have > a lot of brush, you will want sometimes to show only some of them. It is > already possible with tags, but I don't find the current GUI very usable. Is very useful to enable the delete option for this case. Would be useful to have multi-selection option to 'Edit Parametric Brush' and 'Edit Raster Brush'. In these cases, when we'll have multi image-assets or not (parametric brushes, e.g) (brushes, patterns) selected... the icon edit and delete will be enabled, too (to drag-drop option). > Also, just an idea, but wouldn't an artist want to create groups of brushes, > not by type of brush, but for specific projects for instance? (like for this > project, I use only these brushes, just like you will make color palettes > for a given project) > Well this can also be done with tags, so maybe I'm just duplicating the > feature, but it always felt to me as though tags were more used for the type > of brush. Anyway just bouncing ideas against you. This is a good issue, for me, in the current behavior of tags, the folder name is a 'big tag'... almost an category. In fact, is not possible edit them via tag editor instances. So, is possible to think an view dialog to view these 'categories' (tags > from folder names) with tag editing to amplify the categorization of them.
(In reply to jose americo gobbo from comment #4) > (In reply to Jehan from comment #3) > > Also, just an idea, but wouldn't an artist want to create groups of brushes, > > not by type of brush, but for specific projects for instance? (like for this > > project, I use only these brushes, just like you will make color palettes > > for a given project) > > Well this can also be done with tags, so maybe I'm just duplicating the > > feature, but it always felt to me as though tags were more used for the type > > of brush. Anyway just bouncing ideas against you. > > This is a good issue, for me, in the current behavior of tags, the folder > name is a 'big tag'... almost an category. In fact, is not possible edit > them via tag editor instances. So, is possible to think an view dialog to > view these 'categories' (tags > from folder names) with tag editing to > amplify the categorization of them. I don't see another feature to create categories or another way to classify assets by projects/usage. For me, is sufficient improve the 'tags from folder names' for these scopes (projects/usage).
Hi Jehan, any chance to discuss these ideas of the brush procedures?
In this proposal I think useful to add: 1) ID unique creation of the asset. 2) Field to ordering the assets directly on the lists (hidden on alias name in the dialog lists).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/994.