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 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
[Gimp-developer] GEGL brush core concept idea
A concept for brush core structure from events viewpoint. * Events are recived from X * Events are evaluated for: - usefulness using tools options for threshold and dynamics need, - adjusted with curves and filled with requested dynamics (MISSING: Tool needs to report what it needs.) - coordinates are smoothed with per device smooth factor. Events are handed to paint core(if a paint tool is active). -Paint core takes events- * Paint tool on use is called to evaluate the received event. - Paint tool evaluates the event in what it means to it in its own parameters. - Paint tool returns a paint tool data packet object. Data packet contains: 1 to SEG_MAX Segments: stroke_id, Start_point(x, y), End_point(x, y), distance, resource_id, target_resource_id interpolation_points, xy_interpolation_type, 1 - MAX_PARAMETERS parameters: param_val, interpolation_type - If constant rate tool(ie airbrush or ink tool), (re)set timer for next timer event. OnTimer: call re-evaluate in Tool on last segment, Update segment in paintstore. * Paint Core handles data packet segment by segment: - for each segment: Interpolate XY, all params. (pop last from Paintstore last points if interp. type requires) For each point -- Query tool for stamp fitting params, -- push stamppacket to paintstore code. (GEGL?) -- Paint core is done -- In this context paintstore code is seen as something where events can be popped from and pushed to when needed using a stroke_id. I do not know how different that is from what GEGL does. One of the biggest benefits is that one core can handle many very different paint tools. Paint tools can become plug-ins if desired, they only need to provide to core 3 functions, evaluate-event, re-evaluate-event, render-stamp. This makes creating new paint tools extreemly simple and lets people make tools that are free in setting their dynamics to whatever they need enabling very interactive and lifelike brushes. One tool I see is offspring of current vector brush that lets one save all dynamics curves it desires mapping them to any stamp parameter. Support for current brushes can be enabled through always available default plug-ins. This paint core does not handle any interaction with the canvas, only the shape and path of the tool. For physical media simulation a canvas that supports and can render different paints is needed. The canvas interaction is something that happens in the different types of canvas. I currently lack the skills to implement such a core, but perhaps it serves a startingpoint for someone who can either refine it or even implement it just as my ideas were based on others notions. Best, Alexia. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] tagged resources such as brushes, gradients, etc
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
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
