Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc
On Thursday 17 January 2008 14:45, William Skaggs wrote: From: peter sikking [EMAIL PROTECTED] 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc
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 -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc
From: Joao S. O. Bueno [EMAIL PROTECTED] What about using...tags... for that? [etc] 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? 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc
On Thu, 17 Jan 2008 02:50:36 +0100, William Skaggs [EMAIL PROTECTED] 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 ;-) -- .*. /V\ (/ \) ( ) ^^_^^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
