William Skaggs writes:

1) You have a "workspace", holding the brushes that you are currently

[ ... ]

2) You have a set of extra folders, specified in Preferences. The brushes in these folders don't automatically belong to the workspace. To get at them, you invoke a Brush Chooser, which pops

[ ... ]

3) You can also use the Chooser to save a brush from the workspace into the currently selected folder, assuming you have write permission there.

Nice! As you say, that would really encourage the creation of new brushes, patterns and gradients because it would be so much easier to use them.

You didn't mention fonts, but your idea would work equally well for managing an unweildy list of fonts. If there was a way to add hierarchies into the workspace, we could even solve the much- discussed problem of font categorization (these are my script fonts, these are my cartoon fonts, ...)

...Akkana

Hi,

On Wed, 2008-01-16 at 17:03 +0000, William Skaggs wrote:

This problem has been discussed several times in the past, and proposals have been made about how to address it. I have been thinking about it recently, and have come up with a somewhat different, and I believe simpler approach, which I have begun to study experimentally.

Right. We have discussed this in the past and we have come up with a simple and IMO very good solution that has several advantages over the approach that you are suggesting now. The solution is to allow tags to be assigned to data files. This allows the same data file to show up in several categories and it makes it easy to search for certain files. This is also the solution that is approved by the UI team. Please, by all means, let's not introduce something as obsolete as the system that you are suggesting now.

Sven

On Wednesday 16 January 2008 17:42, William Skaggs wrote:

This mixes together two separate issues.  Tags are, as I have already agreed, an excellent way of doing a search mechanism.  They don't get rid of the need to have a workspace, though.  Suppose I want to switch back and forth between five very different brushes.  Must I remember and select a set of tags each time I switch?  That would be very unpleasant.  No, whether or not there is a tag-based search system, there still needs to be a way for the user to maintain a workspace holding a limited set of arbitrarily chosen brushes.

What about using...tags... for that?

The idea of such a workspace would be that it would display brushes containing a certain tag. In teh above use case, I'd just apply a "one-of-five-very-different-brushes" tag to all the brushes. For this to make sense it _must_ be very easy and fast to edit a resource's tags. But that could be refined later on the development.

Actually, maybe it would make sense containers that could show several types of gimp data in a single dialog. So, if I am working with "trees", I'd have palettes, gradients, and brushes which show up in a single window. More than one such dialog should be allowed to be open at once, so that a user could simply drag and drop things around (and internally, tags are added/removed transparently).

So ... the workflow for the case of use above would be something like: create an empty "multicontainer", go to another "multicontainer" displaying only brushes (the equivalent of today's brushes dialog), type in a tag to the first brush, drag it into the empty new container - repeat for brushes 2-5. Start painting. When it is over, destroy the current container, or just save it under an arbitray tag name for later re-use.

js
->

On Thu, 17 Jan 2008 02:50:36 +0100, William Skaggs wrote:

And, to repeat, even if there is tags support, there must be, at least from the user's point of view, something like a workspace -- a set of brushes that are immediately available. The proposal I made -- simply separating the workspace from the other places that hold brushes, and giving the user a way to copy things back and forth -- solves the largest part of the usability problem, and is not incompatible with using tag-based search -- or a tag-based workspace -- if support for tags is ever written, which I am doubtful is going to happen in the near future. -- Bill

Hi Bill,

I like the idea. This adresses one of the major slow-down factors in using Gimp seriously.

Like many things in Gimp , the tools are there and are good, it's just a lot of clicking to get them.

Since you seem to have gone a long way to implementing something workable that could be dovetailed into any eventual "tags" feature, it would be good to see support or comments from Peter's team to enable this to move forwards.

This would definately be an asset to Gimp.

regards, gg

(I guess I should leave the tabs in the title so as not to break the threading in gimp-dev archive, not sure who added that ;-)

Hi,

On Wed, 2008-01-16 at 20:42 +0000, William Skaggs wrote:

This mixes together two separate issues.

No, it doesn't. Absolutely not.

Tags are, as I have already agreed, an excellent way of doing a search mechanism. They don't get rid of the need to have a workspace, though. Suppose I want to switch back and forth between five very different brushes. Must I remember and select a set of tags each time I switch? That would be very unpleasant.

You don't need a set of tags, you need exactly one tag. That is not more information than you need to remember and select with your approach. Still tags are a lot more elegant, simpler to implement and it eliminates the need for storing duplicate files and for doing file system operations.

Sven

Hi,

On Thu, 2008-01-17 at 01:50 +0000, William Skaggs wrote:

These are interesting ideas, but they are fantasies at this point. The whole tags thing is a fantasy at this point. There is no infrastructure in Gimp to support it, so everything would have to be written from scratch. That's months of work for somebody with strong Gimp skills, even if a complete specification existed, which is not the case. Who is going to do it?

There is a lot of infrastructure for this already. If someone wants to start working on this, just let me know and I will take my time to explain what needs to be done. I might even get to it myself.

Even though the current development cycle is already quite far along, we could still get the infrastructure for tags implemented along with on-demand loading of data files. That would allow us to do the changes to the user interface as soon as 2.6 is released.

And, to repeat, even if there is tags support, there must be, at least from the user's point of view, something like a workspace -- a set of brushes that are immediately available.

Sure. That is the set of brushes that match the currently selected tag. That would be the name of the project you are currently working on, or a category that describes the kind of brushes that are currently needed.

Sven

I'm sorry to jump in on this so late. I was working on a new GIMP Plug-In Registry. It had been put on pause by me because of certain life-altering events.

At one point I had put forward the idea of a backend XML-RPC or SOAP connectivity service that would allow GIMP to access the repository data sources and use it for direct installation of the resources within the Plug-In Registry. I envisioned something like a Plug-In Explorer interface in GIMP that would facilitate search and automated installation.

If this is still a viable idea, let me know. I would love to jump back in and finish a new GIMP Plug-In Registry and also do this. I think this would give GIMP a very powerful leg up in adoption by the masses.

_______________________ Best Regards,

Devin Watson

Sven Neumann wrote:

Hi,

On Thu, 2008-01-17 at 01:50 +0000, William Skaggs wrote:

These are interesting ideas, but they are fantasies at this point. The whole tags thing is a fantasy at this point. There is no infrastructure in Gimp to support it, so everything would have to be written from scratch. That's months of work for somebody with strong Gimp skills, even if a complete specification existed, which is not the case. Who is going to do it?

There is a lot of infrastructure for this already. If someone wants to start working on this, just let me know and I will take my time to explain what needs to be done. I might even get to it myself.

Even though the current development cycle is already quite far along, we could still get the infrastructure for tags implemented along with on-demand loading of data files. That would allow us to do the changes to the user interface as soon as 2.6 is released.

And, to repeat, even if there is tags support, there must be, at least from the user's point of view, something like a workspace -- a set of brushes that are immediately available.

Sure. That is the set of brushes that match the currently selected tag. That would be the name of the project you are currently working on, or a category that describes the kind of brushes that are currently needed.

Sven

Hi all,

chiming in here (getting back to speed).

There are some traits that make Bill's idea obsolete. First one is the hierarchical organisation of resources. A tagging system allows multiple ways to find a resource again (instead of a unique one) by attaching many different properties to it (a single brush can be: small, ragged, subtle, project XYZ, project ABC, old skool). And this can only encourage reuse of a resource.

see: topic 6. organise brushes, palettes, gradients in categories.

Also, having to 'tank' the resources in and out of the "workspace" is a waste of time, especially if you do 5 or more different graphics jobs in a single day. Architecturally it feels a thousand times better to have 'zero-conf': all the resources (say brushes) are 'just there', and click a few tags (that match your needs) to narrow that down to the dozen or so to start working.

Also the mentioning of both the file system and the preferences (aka. the graveyard of any good idea) makes that a couple of alarm bells go off here. There is no need for that.

William Skaggs wrote:

Here is the idea:

1) You have a "workspace", holding the brushes that you are currently interested in using. The brushes shown in Gimp's brush picker are those that belong to the workspace. The user has complete control over the contents of the workspace -- anything in it can be edited or deleted. The workspace is saved from session to session, and automatically loaded at startup.

2) You have a set of extra folders, specified in Preferences. The brushes in these folders don't automatically belong to the workspace. To get at them, you invoke a Brush Chooser, which pops up showing a list of brush folders, and a view, which can be either a list or a grid. Clicking on a folder causes the contents to be displayed in the view. Double-clicking on a brush in the view causes it to be loaded into the workspace. Once a brush has been loaded into the workspace, it stays there until you delete it.

3) You can also use the Chooser to save a brush from the workspace into the currently selected folder, assuming you have write permission there.

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Thu, Jan 17, 2008 at 08:37:34AM +0100, Sven Neumann wrote:

And, to repeat, even if there is tags support, there must be, at least from the user's point of view, something like a workspace -- a set of brushes that are immediately available.

Sure. That is the set of brushes that match the currently selected tag. That would be the name of the project you are currently working on, or a category that describes the kind of brushes that are currently needed.

As a user, I have been following this thread with interest. The workspace idea certainly made a great deal of sense to me. The whole 'tags' idea is fine too, but if I understand what is being said there would only be one tag per brush. So say I have a set of brushes I have tagged as 'funky', another one as 'staid', another as 'workhorse'. But maybe the project I am currently working on wants one from each category. So, using the tags, I pick the 'funky' one I want, then the 'staid' one, maybe two 'workhorses', etc. and move (link, copy) them into the workspace, where they are instantly available during the duration of the project. Done with the project, delete the workspace (or just some of its brushes, depending), start on the next one. I don't know anything about gimp programming, but I can't imagine this would involve extra fs-access as was mentioned as a negative; wouldn't the workspace just consist of pointers to the actual brushes?

Scott Swanson

On Thu, Jan 17, 2008 at 05:39:29PM +0100, peter sikking wrote:

There are some traits that make Bill's idea obsolete. First one is the hierarchical organisation of resources. A tagging system allows multiple ways to find a resource again (instead of a unique one) by attaching many different properties to it (a single brush can be: small, ragged, subtle, project XYZ, project ABC, old skool). And this can only encourage reuse of a resource.

Okay, if there are multiple tags enabled, that is great! Just call one of them 'workspace' if you want. Just so long as there is an easy way to set/unset a tag, both by browsing the whole set, or by just browsing within a tag. And a nice way of selecting the current tag, possibly with unions (all of the project ABC tags plus all of the old skool tags that aren't already included in ABC, plus the subtle tags that are in XYZ minus the subtle tags in ABC...) - then if the selection could be given a new 'project DEF' tag. I drool.

Scott Swanson

Scott wrote:

The whole
'tags' idea is fine too, but if I understand what is being said there would only be one tag per brush.

nah, that is the same as sticking them in folders. the power of tags is that you can associate as many concepts with a resource as you like. and find it back via as many ways.

--ps

founder + principal interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

On Jan 17, 2008 7:45 PM, William Skaggs wrote:

2) If they are stored in a separate database, keyed by file names, then there is a great danger of losing the linkage between tags and object. If, for example, the user renames the directory holding some brushes, all of the tags for those brushes will be lost. The only way to prevent this sort of thing from happening is to make sure that all operations on resource files are mediated by Gimp (or some new utility program) that will make sure to keep the tags in sync with the data files. If for some reason a user's tags database gets corrupted, it will be a major disaster.

I don't see any disaster. Here is one possible solution: store some sort of checksum (let's say, MD5) together with filename in the database.
Let's say user renames file. If new filename is found with the same checksum, simply change the filename in database and that's it - you've got completely correct database once again. This could be a little more tricky at runtime (scan in background?), but not a disaster, really.

On Thursday 17 January 2008 14:45, William Skaggs wrote:

From: peter sikking peter@mmiworks.net

chiming in here (getting back to speed). [...]

Peter! Great to hear from you again!

I absolutely agree about the virtues of a tagging system, but I fear that the difficulties are not being appreciated well enough. Here, for example, is just one of the problems:

Problem: should tags be stored as part of a data file, or in a separate tags-database?

separate tags "database" - which might be a xml file, I think.

1) If they are stored as part of the data file, then this calls for a new file format for every sort of gimp resource object, and changing tags calls for file system operations.

ok - this won't happen.

2) If they are stored in a separate database, keyed by file names, then there is a great danger of losing the linkage between tags and object. If, for example, the user renames the directory holding some brushes, all of the tags for those brushes will be lost. The only way to prevent this sort of thing from happening is to make sure that all operations on resource files are mediated by Gimp (or some new utility program) that will make sure to keep the tags in sync with the data files. If for some reason a user's tags database gets corrupted, it will be a major disaster.

I think we just need to worry about it being a "minor" disaster. I can think of "recover scripts" that could be written to restore some tags, in case of directory renaming, for example.

There are many other issues of the same sort, which I don't believe have been thought through.

I don´ t think so. It looks plain straightforward for me. I have worked with many web systems that reference filesystem paths for images, for example, and never had a maintanance problem due to that.

Besides, yes, gimp would need some kind of scanning through resource folders, and possibly group all resopurces tehre under an "all" flag. That is needed so that one can download resources and add then to GIMP through the filesystem.

The bottom line is that introducing tag-based resource organization is like setting up a virtual, non-hierarchical file system. The ordinary file system may be weak in comparison, but it is extremely robust, and users know how to manipulate it. A new tag-based file system can't possibly be robust until it has had an extensive testing period, and therefore exposes a user to the worst of all disasters: a corrupted file system.

The solution I favor is to build a tag-based system *on top of* a filesystem-based system. That way:

1) The tag-based system can be built gradually, instead of being imposed all at once on a flat set of files.

A "flat set of files" become a "flat set under one tag" in teh worst case scenario.

2) The user can manipulate files using ordinary filesystem operations without fear of wrecking gimp.

Yes, that need to happen therefore the folders where resources are expected to be, as they are today should remain, IMHO.

3) A naive user who doesn't understand tags will still be able to use Gimp without having to learn about tags at the very beginning.

This one is for Peter. In short: yes, there should be resources visible in a default GIMP install, first use. Maybe we could name a "Basic" tag for these start-up resources. A drop down for the most used tags could be fine as well.

4) A corrupted tags database will still be very bad, but won't make Gimp completely unusable.

Indeed. As I said, the scanning should be made at gimp-load, and any resources found should be mapped to a "default" tag. Using something as simple as a hash of the entire file data could preserve all tags even when resources where moved across directories (rescanning hashest might need an explicit action)

regards, js
->

-- Bill

Ok, here are my 2¢...

On Thursday 17 January 2008, Joao S. O. Bueno wrote:

Besides, yes, gimp would need some kind of scanning through resource folders, and possibly group all resopurces tehre under an "all" flag. That is needed so that one can download resources and add then to GIMP through the filesystem.

Or just have an "no tag" option in the settings about which resources to show:

--------------------------------- | Show the following resources: |
---------------------------------
| [X] Basic |^|
| [ ] Peppers (all colors) | |
| [ ] Scribbles | |
| [ ] {no tag} |v|
---------------------------------
| [ None ] [ All ] [ Invert ] |
| |
| [ Abort ] [ Save ] [ Reset ] |
---------------------------------

Looking forward to seeing these ideas implemented one day :-) Daniel

Hi,

On Thu, 2008-01-17 at 20:52 +0200, Aurimas Juška wrote:

I don't see any disaster. Here is one possible solution: store some sort of checksum (let's say, MD5) together with filename in the database.

MD5 checksums are a nice idea. I think I will incorporate that for the implementation of tagged resources.

My current favorite approach is to put the tags into files in the ~/.gimp-2.x directory, one file per resource type. So there would be a brushrc, gradientrc, patternrc and so on. These files will contain metadata from the actual resource files. At some point they will have enough metadata to actually skip loading the resource file until it is actually used. That way we can avoid the need to load all resource files at startup.

As a first step the implementation will concentrate on tags. So for now all that goes into the file per resource is

- filename, either absolute or relative to ${gimp_dir} - MD5 sum for recovery
- list of tags

If a resource file with tags is lost (i.e. it doesn't exist under the filename any longer), the filename will be removed but the MD5 sum and tags will be kept. When the user adds new resource files, their MD5 sums are compared to the checksums of the entries without filename and tags are recovered from there. This is not perfect, but it should work quite well. The only drawback is that if you remove files, their tags will be kept around forever. But I guess we can live with that. The lost entries can be kept at the bottom of the tags file so they can be easily discarded manually. At some point we might even add a user interface for this.

Does this make sense or did I forget something important?

Sven

On Jan 18, 2008 8:55 AM, Sven Neumann wrote:

My current favorite approach is to put the tags into files in the ~/.gimp-2.x directory, one file per resource type. So there would be a brushrc, gradientrc, patternrc and so on. These files will contain metadata from the actual resource files.

One think I'm missing here is a way to share brushes with tags. The user scenarios I'm thinking about is: - Download package (ZIP-File) with a lot of brushes - Install them (btw. Finding the right folder and copying them into it looks like a problem for some users. At least it's an FAQ in the German gimpforum.de.)
- Now I'd like to have this brushes tagged in Gimp and start working with this brushes and I don't want to tag them myself.

Regards, Tobias

On Jan 18, 2008 9:33 PM, Tobias Jakobs wrote:

On Jan 18, 2008 8:55 AM, Sven Neumann wrote:

My current favorite approach is to put the tags into files in the ~/.gimp-2.x directory, one file per resource type. So there would be a brushrc, gradientrc, patternrc and so on. These files will contain metadata from the actual resource files.

One think I'm missing here is a way to share brushes with tags. The user scenarios I'm thinking about is: - Download package (ZIP-File) with a lot of brushes - Install them (btw. Finding the right folder and copying them into it looks like a problem for some users. At least it's an FAQ in the German gimpforum.de.)
- Now I'd like to have this brushes tagged in Gimp and start working with this brushes and I don't want to tag them myself.

Regards, Tobias

An archive as follows:

brushrc/aqua brushrc/charcoal
brushes/aqua
brushes/charcoal

,if extracted in your .gimp-2.4/ directory, should do the right thing. Provided that brushrc filename references are either relative or have no path component -- another implementation detail to work out.

On Jan 18, 2008 5:03 AM, Tobias Jakobs wrote:

On Jan 18, 2008 8:55 AM, Sven Neumann wrote:

My current favorite approach is to put the tags into files in the ~/.gimp-2.x directory, one file per resource type. So there would be a brushrc, gradientrc, patternrc and so on. These files will contain metadata from the actual resource files.

One think I'm missing here is a way to share brushes with tags. The user scenarios I'm thinking about is: - Download package (ZIP-File) with a lot of brushes - Install them (btw. Finding the right folder and copying them into it looks like a problem for some users. At least it's an FAQ in the German gimpforum.de.)
- Now I'd like to have this brushes tagged in Gimp and start working with this brushes and I don't want to tag them myself.

What about a function to "export" brushes that dumps selected brushes to a new dir with a local version of brushrc, and a matching "import" that reads them in - file, MD5, and tags?

Chris

Hi,
cr33dog@gmail.com (2008-01-18 at 0844.05 -0600):

What about a function to "export" brushes that dumps selected brushes to a new dir with a local version of brushrc, and a matching "import" that reads them in - file, MD5, and tags?

Or a tag system based in companion files (flowers.gih gets a flowers.gih.tags file) and then the common resource file is assembled as need in similar fashion than .fonts.cache-1 (with any extra info it can need, not just tags). No export tools need, no hidden info.

Provided tags files are simple enough (say one tag per line, which can support languages or special types like "tag assigned by user" vs "by creator" via simple syntax like "type[lang]=tag"), they could even be merged with simple tools (concate the file, filter out duplicates) or processed by script (create zip with all resources tagged "flower").

GSR

On Jan 18, 2008 9:55 AM, Sven Neumann wrote:

My current favorite approach is to put the tags into files in the ~/.gimp-2.x directory, one file per resource type. So there would be a brushrc, gradientrc, patternrc and so on. These files will contain metadata from the actual resource files.

What data structure could be used to represent this data in application? As I understand, it will be necessary not only to traverse data, but also to update it at runtime (not files, but internal data structures, of course). Wouldn't it be nice to use Sqllite for this instead?

The only drawback is that if you remove files, their tags will be kept around forever.

They could be discarded after some period, say 90 days. Tags won't make sense forever (because you'll forget why you added them), so there is no point to keep them forever.

Hi,

On Fri, 2008-01-18 at 20:11 +0200, Aurimas Juška wrote:

What data structure could be used to represent this data in application? As I understand, it will be necessary not only to traverse data, but also to update it at runtime (not files, but internal data structures, of course). Wouldn't it be nice to use Sqllite for this instead?

IMO a database would be overkill. This can easily be implemented on top of GimpData and GimpContainer. I already added the GimpTagged interface to GimpData yesterday. If it turns out that there's a performance problem, GLib has the data structures we need to solve them.

Sven

Hi,

On Fri, 2008-01-18 at 12:03 +0100, Tobias Jakobs wrote:

On Jan 18, 2008 8:55 AM, Sven Neumann wrote:

My current favorite approach is to put the tags into files in the ~/.gimp-2.x directory, one file per resource type. So there would be a brushrc, gradientrc, patternrc and so on. These files will contain metadata from the actual resource files.

One think I'm missing here is a way to share brushes with tags. The user scenarios I'm thinking about is: - Download package (ZIP-File) with a lot of brushes - Install them (btw. Finding the right folder and copying them into it looks like a problem for some users. At least it's an FAQ in the German gimpforum.de.)
- Now I'd like to have this brushes tagged in Gimp and start working with this brushes and I don't want to tag them myself.

You are right that installing resources is a problem for most users. At some point we should deal with this by adding functionality to import resources files into GIMP. Ideally it should be as simple as dropping the archive file or a folder on the Brushes list. GIMP should then ask the user if the files should be copied into the main brushes folder or if the folder location should be added to the brush search path. At the same time GIMP could ask for tags to assign to the new brushes. Ideally it would also look for a tags file in the folder and offer the tags found therein as the default.

Sven

Is it possible that one physical file could represent more than one resource? Let's say, some file format of other application which contains multiple brushes. Or some file format which contains multiple types of resources (brushes, patterns, etc).

If such case should be handled, we could look at such file as some special kind of directory:
/home/aaa/bbbb_favorites.col#brush1

This way it should be possible to handle various collection formats from other application.

About sharing resources: There was a suggestion, that when user want's to share resources, they could be exported to some kind of archive. If collection handling would be supported, it would be possible for user to access archive directly and for administrator to put some archives to read-only network folder and user could load those resources without the need of extracting and copying to local folder.