Re: [Gimp-developer] GAP Export?
Hi, On Tue, 2008-01-15 at 16:22 -0500, Andy Berdan wrote: I've been investigating some animation systems for use at work here, and I was wondering about exporting names and locations of layers in the animation. I am not sure if Wolfgang Hofer, the author of GAP follows this mailing-list. You might have more luck by mailing him directly. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP Export?
The information about layer offsets in a frame sequence is not made readily available and a plug-in would need to be written (and, IMO, it would be simpler to write a Script run in batch mode). Also, once an object has been added to a frame sequence, GIMP only knows the offsets and extents of the resulting layer; it does not record whether the object was rotated or otherwise transformed (which would result in altered offsets and extents). If you added the layers to your animation using the Move Path command, you could save the object's placement information for later recall by saving the control points used. There are some limitations to this, though: primarily that a separate file is created for each object; and if you wish to have the specifics of the object's placement for each frame saved (as opposed to keyframe control points) then you need to use the Paths tool to specify that placement (as opposed to manually specifying the control points in the Move Path dialog). Also, there is no way of saving changes made to the objects after their initial placement. This approach will produce a file with the following parameters for each control point: x y width height opacity rotation feather_radius (perspective transform factors) (rel_keyframe) If you need more information on the above approach, it might be better to move the discussion to the Users mailing list, as this wouldn't really contribute to GIMP development. Quoting Andy Berdan [EMAIL PROTECTED]: Hi all, I've been investigating some animation systems for use at work here, and I was wondering about exporting names and locations of layers in the animation. Hm. That doesn't sound too clear - allow me to illustrate with an example. Suppose the source animation is a 10-frame animation, with a hand and a ball, both moving (and animating) independently, I'd eventually want something like this: animation-frame-0: hand-frame-1 x=0,y=0 animation-frame-0: ball-frame-1 x=5,y=5 animation-frame-1: hand-frame-2 x=10,y=10 animation-frame-1: ball-frame-1 x=25,y=25 ... etc ... animation-frame-9: hand-frame-2 x=100,y=100 animation-frame-9: ball-frame-1 x=520,y=520 (ignore the syntax, the data is presented as such for clarity -- though now, I think a graphical example might have been better) Obviously, GAP itself has access to this data at some point, but it doesn't seem to be exposed or exportable in any way. The only idea I can come up with at this point involves iterating over animation files in a directory, scanning each layer for frame information, and dumping the data to a file... and I'm not 100% sure if that's do-able, though it seems that that is something script/python-fu should have access to. BTW, the intent is to use this animation data (not actual video output) in a game engine for layer-based animations, if you're wondering why I'm asking for this somewhat strange feature. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] proposal for managing resources such as brushes, gradients, etc
One of the most important usability problems with Gimp is the inability to organize resources such as brushes, gradients, patterns, and palettes. For each of these, you can designate a set of folders in Preferences, but everything inside those folders is automatically loaded at startup, and presented to the user in a flat, unstructured format. Furthermore, there is no way for an ordinary user to get rid of any of the resources that come with Gimp, even if they are essentially useless, such as the famous Green Pepper brush. Not only does this make for problems in finding the right brush etc when using the program, it impairs Gimp in terms of developing a user base. One of the things that some users really like to do, in my experience, is create collections of resources. This has happened many times for Gimp, but nobody uses the collections, for the simple reason that adding resources to Gimp generally does more harm than good: everything you add makes it linearly harder to find the thing you want when you use the program. (Note, please, that I am *not* talking here about making resources available over the web -- that is also very important, but it is not the same problem. Here I am talking only about managing resources that the user already owns.) 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. I would like to describe the approach that I have in mind, and to some degree try to explain why I think it is the right thing to do. To make the following description easier to understand, I am going to talk in terms of brushes, but you should realize that gradients, patterns, and palettes are handled by Gimp in exactly the same way (technically, all of them are types of GimpData), and a method that applies to one will almost automatically carry over to the others. 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. That's basically the story. One of the advantages (as I see it) of the approach is that it makes very little change in how Gimp is used. So long as the user stays within the workspace, everything works the same as now. The only new thing is the Chooser, used to load brushes into the workspace (or save brushes from the workspace into a separate folder). At a technical level, the workspace would be represented by the user's writable brush folder, that is, ordinarily, .gimp-2.5/brushes. This would be the only folder loaded at startup. The Brush Chooser would show a simple list of the other directories specified in Preferences (including the set of distributed brushes), and a DataFactoryView of the directory among them that is selected. 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. Comments and questions are welcome, -- 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
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 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
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
