Tagging of Gimp Resources project status

[Aurimas Juška-2]

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
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[David Gowers]

Hi Aurimas,

On Mon, Jul 14, 2008 at 6:33 AM, Aurimas Juška <aurimas.juska@...> 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
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Aurimas Juška-2]

Hi,

On Mon, Jul 14, 2008 at 3:45 AM, David Gowers

> 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?

It is planned to create a platform independent resource file export
and import functionality. One user exports some resources to a package
(tags associated with resources are also stored in the package). Other
user can import resources from the package together with their
assigned 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'
>

Yes, it will surely be possible.

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

I haven't thought of it yet but it seems a good idea. Also, currently
there is only AND search in tag queries. Maybe it would be good to add
even more flexibility to advanced users.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Bill Skaggs]

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
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[David Gowers]

On Tue, Jul 15, 2008 at 1:06 AM, Bill Skaggs <weskaggs@...> 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.

[cycle-gimpdata.diff]

---

Index: app/actions/actions.c
===================================================================
--- app/actions/actions.c (revision 26193)
+++ app/actions/actions.c (working copy)
@@ -511,7 +511,8 @@
 GimpObject *
 action_select_object (GimpActionSelectType  select_type,
                       GimpContainer        *container,
-                      GimpObject           *current)
+                      GimpObject           *current,
+      gboolean              wrap)
 {
   gint select_index;
   gint n_children;
@@ -561,7 +562,14 @@
       break;
     }
 
-  select_index = CLAMP (select_index, 0, n_children - 1);
+  if (wrap)
+    {
+      while (select_index < 0)
+        select_index = (n_children) - (0 - select_index);
+
+      while (select_index > (n_children - 1))
+        select_index = (n_children - select_index);
+    }
 
   return gimp_container_get_child_by_index (container, select_index);
 }
Index: app/actions/layers-commands.c
===================================================================
--- app/actions/layers-commands.c (revision 26193)
+++ app/actions/layers-commands.c (working copy)
@@ -348,7 +348,8 @@
 
   new_layer = (GimpLayer *) action_select_object ((GimpActionSelectType) value,
                                                   image->layers,
-                                                  (GimpObject *) layer);
+                                                  (GimpObject *) layer,
+  FALSE);
 
   if (new_layer && new_layer != layer)
     {
Index: app/actions/context-commands.c
===================================================================
--- app/actions/context-commands.c (revision 26193)
+++ app/actions/context-commands.c (working copy)
@@ -680,7 +680,7 @@
 
   current = gimp_context_get_by_type (context, container->children_type);
 
-  current = action_select_object (select_type, container, current);
+  current = action_select_object (select_type, container, current, TRUE);
 
   if (current)
     gimp_context_set_by_type (context, container->children_type, current);

---

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

[David Gowers]

On Tue, Jul 15, 2008 at 1:06 AM, Bill Skaggs <weskaggs@...> 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.

[cycle-gimpdata.diff]

---

Index: app/actions/actions.c
===================================================================
--- app/actions/actions.c (revision 26193)
+++ app/actions/actions.c (working copy)
@@ -511,7 +511,8 @@
 GimpObject *
 action_select_object (GimpActionSelectType  select_type,
                       GimpContainer        *container,
-                      GimpObject           *current)
+                      GimpObject           *current,
+      gboolean              wrap)
 {
   gint select_index;
   gint n_children;
@@ -561,7 +562,14 @@
       break;
     }
 
-  select_index = CLAMP (select_index, 0, n_children - 1);
+  if (wrap)
+    {
+      while (select_index < 0)
+        select_index = (n_children) - (0 - select_index);
+
+      while (select_index > (n_children - 1))
+        select_index = (n_children - select_index);
+    }
 
   return gimp_container_get_child_by_index (container, select_index);
 }
Index: app/actions/layers-commands.c
===================================================================
--- app/actions/layers-commands.c (revision 26193)
+++ app/actions/layers-commands.c (working copy)
@@ -348,7 +348,8 @@
 
   new_layer = (GimpLayer *) action_select_object ((GimpActionSelectType) value,
                                                   image->layers,
-                                                  (GimpObject *) layer);
+                                                  (GimpObject *) layer,
+  FALSE);
 
   if (new_layer && new_layer != layer)
     {
Index: app/actions/context-commands.c
===================================================================
--- app/actions/context-commands.c (revision 26193)
+++ app/actions/context-commands.c (working copy)
@@ -680,7 +680,7 @@
 
   current = gimp_context_get_by_type (context, container->children_type);
 
-  current = action_select_object (select_type, container, current);
+  current = action_select_object (select_type, container, current, TRUE);
 
   if (current)
     gimp_context_set_by_type (context, container->children_type, current);

---

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

[David Gowers]

Hello,

On Tue, Jul 15, 2008 at 10:01 AM, David Gowers <00ai99@...> wrote:

> On Tue, Jul 15, 2008 at 1:06 AM, Bill Skaggs <weskaggs@...> 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.

[cycle-gimpdata.diff]

---

Index: app/actions/actions.c
===================================================================
--- app/actions/actions.c (revision 26193)
+++ app/actions/actions.c (working copy)
@@ -511,7 +511,8 @@
 GimpObject *
 action_select_object (GimpActionSelectType  select_type,
                       GimpContainer        *container,
-                      GimpObject           *current)
+                      GimpObject           *current,
+                      gboolean              wrap)
 {
   gint select_index;
   gint n_children;
@@ -561,7 +562,14 @@
       break;
     }
 
-  select_index = CLAMP (select_index, 0, n_children - 1);
+  if (wrap)
+    {
+      while (select_index < 0)
+        select_index = (n_children) - (0 - select_index);
+
+      while (select_index > (n_children - 1))
+        select_index = (n_children - select_index);
+    }
 
   return gimp_container_get_child_by_index (container, select_index);
 }
Index: app/actions/actions.h
===================================================================
--- app/actions/actions.h (revision 26193)
+++ app/actions/actions.h (working copy)
@@ -51,7 +51,8 @@
                                        gboolean              wrap);
 GimpObject  * action_select_object    (GimpActionSelectType  select_type,
                                        GimpContainer        *container,
-                                       GimpObject           *current);
+                                       GimpObject           *current,
+                                       gboolean              wrap);
 
 
 #define return_if_no_gimp(gimp,data) \
Index: app/actions/layers-commands.c
===================================================================
--- app/actions/layers-commands.c (revision 26193)
+++ app/actions/layers-commands.c (working copy)
@@ -348,7 +348,8 @@
 
   new_layer = (GimpLayer *) action_select_object ((GimpActionSelectType) value,
                                                   image->layers,
-                                                  (GimpObject *) layer);
+                                                  (GimpObject *) layer,
+                                                  FALSE);
 
   if (new_layer && new_layer != layer)
     {
Index: app/actions/context-commands.c
===================================================================
--- app/actions/context-commands.c (revision 26193)
+++ app/actions/context-commands.c (working copy)
@@ -680,7 +680,7 @@
 
   current = gimp_context_get_by_type (context, container->children_type);
 
-  current = action_select_object (select_type, container, current);
+  current = action_select_object (select_type, container, current, TRUE);
 
   if (current)
     gimp_context_set_by_type (context, container->children_type, current);

---

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

[Aurimas Juška-2]

Hi,

Here is some information about the current status of Tagging of Gimp
Resources GSoC project.

If you're interested how Gimp resource tagging works now and what
related features could be implemented in the future, there is a small
introduction at
http://sites.google.com/site/aurijusk/gimp-resource-tagging

Technical information about tagging implementation in Gimp can be
found in soc-2008-tagging branch [1], file devel-docs/tagging.txt (tag
implementation overview) and also Gimp app reference manual.

[1] svn://svn.gnome.org/svn/gimp/branches/soc-2008-tagging
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[David Gowers]

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
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer