Parasites and Tattoos: some questions
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
Parasites and Tattoos: some questions | saulgoode@brickfilms.com | 24 Aug 00:17 |
Parasites and Tattoos: some questions | David Gowers | 24 Aug 07:10 |
Parasites and Tattoos: some questions | Sven Neumann | 24 Aug 08:20 |
Parasites and Tattoos: some questions | saulgoode@brickfilms.com | 24 Aug 20:26 |
Parasites and Tattoos: some questions
Parasites:
Is there a philosophical reason that parasite changes are not UNDOable? If not, could someone provide a nudge on how "non-tile" information is saved to the UNDO history (for example, layer name changes)?
Also, the "*-parasite-find" PDB functions return a list containing a single list: for example,
(("gimp-comment" 1 #18"4372656174656420776974682047494d5000"))
There does not appear to be a way to create multiple parasites with the same name -- the "*-parasite-attach" function changes the value of the existing parasite. Is there a reason for the parasite to be enclosed doubly within a list?
Tattoos:
If an object has a specific tattoo assigned to it then, when the object is destroyed, is the tattoo value made available for re-use? For example, I have three layers and record their tattoos. I then merge those layers which generates a new layer (with a new tattoo). Can I rely on the tattoos of the original layers not being assigned to a new object (during that image editing session)? (If so, I would like to assign the original tattoo to the merged layer.)
Or, is there a way to test a value to see if it is already attached to an object?
Parasites and Tattoos: some questions
There is a flag for making a parasite undoable (GIMP_PARASITE_UNDOABLE?) Are you saying that this flag doesn't work? It does for me in PyGimp -- I use it most of the time.
On 8/24/06, saulgoode@brickfilms.com wrote:
Parasites:
Is there a philosophical reason that parasite changes are not UNDOable? If not, could someone provide a nudge on how "non-tile" information is saved to the UNDO history (for example, layer name changes)?
Also, the "*-parasite-find" PDB functions return a list containing a single list: for example,
(("gimp-comment" 1 #18"4372656174656420776974682047494d5000"))
This looks like a Script-fu bug. PyGimp doesn't do this, it just returns the parasite itself.
Tattoos:
If an object has a specific tattoo assigned to it then, when the object is destroyed, is the tattoo value made available for re-use? For example, I have three layers and record their tattoos. I then merge those layers which generates a new layer (with a new tattoo). Can I rely on the tattoos of the original layers not being assigned to a new object (during that image editing session)? (If so, I would like to assign the original tattoo to the merged layer.)
I did some tests on this awhile ago, and IIRC they don't get reused until a very long time (about 2^31 iterations of creating new layers/vectors/channels). Much the same as IDs in that respect.
Parasites and Tattoos: some questions
Hi,
On Wed, 2006-08-23 at 15:17 -0700, saulgoode@brickfilms.com wrote:
Also, the "*-parasite-find" PDB functions return a list containing a single list: for example,
(("gimp-comment" 1 #18"4372656174656420776974682047494d5000"))
There does not appear to be a way to create multiple parasites with the same name -- the "*-parasite-attach" function changes the value of the existing parasite. Is there a reason for the parasite to be enclosed doubly within a list?
That's not quite right. It returns a list if called by Script-Fu because all PDB functions return a list when called through Script-Fu.
Tattoos:
If an object has a specific tattoo assigned to it then, when the object is destroyed, is the tattoo value made available for re-use? For example, I have three layers and record their tattoos. I then merge those layers which generates a new layer (with a new tattoo). Can I rely on the tattoos of the original layers not being assigned to a new object (during that image editing session)?
Being a unique identifer is the idea of tattoos.
Sven
Parasites and Tattoos: some questions
Quoting David Gowers:
There is a flag for making a parasite undoable (GIMP_PARASITE_UNDOABLE?) Are you saying that this flag doesn't work? It does for me in PyGimp -- I use it most of the time.
I don't think that flag's name is exposed in Script-fu but it does appear to work fine when flag is hardcoded as "2" and it does precisely that which I needed, thanks.
There does not appear to be a way to create multiple parasites with the same name -- the "*-parasite-attach" function changes the value of the existing parasite. Is there a reason for the parasite to be enclosed doubly within a list?
This looks like a Script-fu bug. PyGimp doesn't do this, it just returns the parasite itself.
After further consideration, I do not think it is a bug; the original author was probably providing for the future case of being able to pass glob patterns and receiving a list of matching results (where each item in the list is a list itself).
I did some tests on this awhile ago, and IIRC they [tattoos] don't get reused until a very long time (about 2^31 iterations of creating new layers/vectors/channels). Much the same as IDs in that respect.
I was hoping that would be the case; again, precisely that which I desired.
Thank you for your responses.