Hi Aurimas,

On Mon, Jul 14, 2008 at 6:33 AM, Aurimas Juška wrote:

Hi,

Tagging of Gimp Resources project is an attempt to make it easy and efficient to organize Gimp resources (brushes, patterns, gradients, palettes). Currently the project is already somewhat usable, allowing user to assign tags, filter resources on selected tags, preserve tags between session and more.

Screenshots [1] and [2] show how resource (brush, etc) docks look. As you can see, there are two tag entries: the one on top is to filter based on selected tags, on the bottom is for tag assignment. Tags can be typed with keyboard [1] (specifically for tagging a special autocompletion was implemented: autocompletes tags even in the middle of tag list, doesn't offer already selected tags, etc) and selected with some pointing device [2] (popup window stays open to allow multiple tag selection, it can be closed by clicking somewhere outside).

Tags cache is stored in tag cache file (~/.gimp-2.5/.tag-cache.xml). The file is user editable, but that is normally not needed. Should user rename or move resource file(s) (brushes, etc), tag cache would detect changes based on file contents and correctly remap tags.

Source code is available: svn://svn.gnome.org/svn/gimp/branches/soc-2008-tagging. Questions, comments and recommendations are appreciated.

[1] http://img137.imageshack.us/img137/829/autocompletioniw0.png [2] http://img175.imageshack.us/img175/7020/popupcg7.png

Nice work! :) I like especially seeing how GimpData have no particular name, just tags. (I am guessing that their name is currently added as a tag though :)

After seeing how you have set up things here, I thought of this: There is probably a need to import tags when adding a set of patterns. As in, person A packages up eight patterns into a .zip file; They've tagged these patterns with a few things that make universal sense (eg 'stone', 'stippling', or 'hi contrast'). It would help persons B,C and D (users of these patterns) to be able to import tags for those patterns from an existing tag-cache.xml file. This is particularly useful as the number of resources in the packages increases, for example my package of dithering patterns (http://gimpstuff.org/content/show.php/dithering%2Bhalftoning+patterns?content=81817) could definitely benefit from it.
I am assuming that tag-cache.xml can easily be filtered by a script to contain only information about the items that are being distributed. So I envision a package containing something like

blackgranite.pat diamondstippling.pat
electricity.pat
mypackagename-tags.xml

and when the user initially unpacks the package, they import the tags. If they later want to recover the tags (since they may have deleted some of them from their own tags.) they can import the tags again.

Do you have a plan to address importation of tags?

I'm sure you have a plan to provide tag renaming -- this would be helpful for i18n, allowing a person to easily rename the original tag to something in their preferred language. eg 'stippling' -> 'miksi?i desino'

Do you plan to implement NOT filtering? as in 'dithering -diamond' filtering for patterns tagged 'dithering' that are not tagged 'diamond'.

Thanks,
David

Here is to me the most important question. Suppose the user wants to switch back and forth among a few brushes that don't have any natural relationship. Suppose for example that the user wants to draw with a pencil brush, and then erase parts of the drawing with a round parametric brush, and repeat the cycle. Is this sort of thing going to be supported in a way that is easy for the user?

-- Bill

On Tue, Jul 15, 2008 at 1:06 AM, Bill Skaggs wrote:

Here is to me the most important question. Suppose the user wants to switch back and forth among a few brushes that don't have any natural relationship. Suppose for example that the user wants to draw with a pencil brush, and then erase parts of the drawing with a round parametric brush, and repeat the cycle. Is this sort of thing going to be supported in a way that is easy for the user?

-- Bill

Cycling between the brushes in the filtered view could do this (so, tag both with 'quickdraw' then use the action -- notice their ordering is not user-controllable in this scenario). I think 'next brush' and 'previous brush' actions that already exist should handle this.

However, they appear not to cycle currently -- ie going back from the first brush leaves you at the first brush rather than the last, and vice versa.
This should really be fixed -- cycling makes more sense for GimpData's (brush, pattern, palette) than the current, clipping, behaviour.
Looking at the code in app/actions/actions.c, it seems that all we need is to change action_select_object() to support wrapping, and then use that parameter (in context-commands.c and layers-commands.c).

A diff is attached that implements the suggested changes.

On Tue, Jul 15, 2008 at 1:06 AM, Bill Skaggs wrote:

Here is to me the most important question. Suppose the user wants to switch back and forth among a few brushes that don't have any natural relationship. Suppose for example that the user wants to draw with a pencil brush, and then erase parts of the drawing with a round parametric brush, and repeat the cycle. Is this sort of thing going to be supported in a way that is easy for the user?

-- Bill

Cycling between the brushes in the filtered view could do this (so, tag both with 'quickdraw' then use the action -- notice their ordering is not user-controllable in this scenario). I think 'next brush' and 'previous brush' actions that already exist should handle this.

However, they appear not to cycle currently -- ie going back from the first brush leaves you at the first brush rather than the last, and vice versa.
This should really be fixed -- cycling makes more sense for GimpData's (brush, pattern, palette) than the current, clipping, behaviour.
Looking at the code in app/actions/actions.c, it seems that all we need is to change action_select_object() to support wrapping, and then use that parameter (in context-commands.c and layers-commands.c).

A diff is attached that implements the suggested changes.

Hello,

On Tue, Jul 15, 2008 at 10:01 AM, David Gowers wrote:

On Tue, Jul 15, 2008 at 1:06 AM, Bill Skaggs wrote:

Here is to me the most important question. Suppose the user wants to switch back and forth among a few brushes that don't have any natural relationship. Suppose for example that the user wants to draw with a pencil brush, and then erase parts of the drawing with a round parametric brush, and repeat the cycle. Is this sort of thing going to be supported in a way that is easy for the user?

-- Bill

Cycling between the brushes in the filtered view could do this (so, tag both with 'quickdraw' then use the action -- notice their ordering is not user-controllable in this scenario). I think 'next brush' and 'previous brush' actions that already exist should handle this.

However, they appear not to cycle currently -- ie going back from the first brush leaves you at the first brush rather than the last, and vice versa.
This should really be fixed -- cycling makes more sense for GimpData's (brush, pattern, palette) than the current, clipping, behaviour.
Looking at the code in app/actions/actions.c, it seems that all we need is to change action_select_object() to support wrapping, and then use that parameter (in context-commands.c and layers-commands.c).

A diff is attached that implements the suggested changes.

.. I am puzzled by how this message got double posted.

I left a file out of the diff and some formatting was incorrect. Here is the revised diff.

Hi Aurimas, I've tried this out and read your PDF, this is what I think:

The basic idea is good and neatly implemented. It needs more consistency upon integration with SVN HEAD. For example
* 'Next Brush' / 'Previous Brush' actions don't move through the filtered view, they move through the entire set of brushes, including ones that aren't currently shown. Personally, most of the selection of resources I do occurs when no dialogs at all are visible, just the image window, so this makes tagging much more of a real benefit for me.
* brush selector button and pattern selector button in tool options is unfiltered

We would need a notion of 'current brush filter','current pattern filter', 'current gradient filter'... and it needs to apply globally, so that navigating to the next or previous item works, and filtering occurs for all brush/pattern/gradient selection popups.

PDB-wise, plug-ins need to be able to filter resources by tags, and it should be easy to get the e.g. 'current brush filter' for use in filtering.

As it is, this helps me a lot in organizing my palettes, and I hope to see it committed to SVN HEAD :)

David