Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc
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: http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp- user-requests.html 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 ___ 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 such as brushes, gradients, etc
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 ___ 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 such as brushes , gradients, etc
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 ___ 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 such as brushes, gradients, etc
On Jan 17, 2008 7:45 PM, William Skaggs [EMAIL PROTECTED] 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. ___ 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 such as brushes, gradients, etc
At the level of programming, the only relatively difficult thing is to create the GimpDataChooser widget. Even this is simple in principle, although complicated in practice because it involves a lot of rather complex Gimp code. I have been experimenting with writing a Chooser, and I believe I have gotten through the hardest part, although there is quite a bit of refinement needed. Why bind it into gimp? This tool could be totally independent of GIMP runtime wise. All that would be need on gimp side is support for using gimp-remote to trigger reloading of resources. All other management could happen outside GIMP. Functions needed to read and write gimp conf should be easily portable from gimp code. --Alexia ___ 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 such as brushes, gradients, etc
Hi, On Wed, 2008-01-16 at 17:03 +, 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 ___ 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 such as brushes, gradients, etc
From: Sven Neumann [EMAIL PROTECTED] 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. 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. -- 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 such as brushes, gradients, etc
Hi, On Wed, 2008-01-16 at 20:42 +, 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 ___ 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 such as brushes , gradients, etc
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 +, 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ 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 such as brushes , gradients, etc
Hi, On Thu, 2008-01-17 at 01:50 +, 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
