Re: "Global Locking" for Gimp :-(
Simon Budig wrote: > > I see, that Gimp can be crashed very easily when trying to use multiple > tools at the same image/layer. Michael adressed this: from the changelog: > > [...] > > Well - unfortunately this disables "user multitasking" with working > on multiple images. Admittedly I dont do this too often, but sometimes > it is nice to paint something while waiting for a big image to > rotate. (just tested - multiple plugins do work! :-) > > Is there any chance to do this on an "per image" base without > hazzeling too much? Or - if this is too hard to implement - do you think > that this limitation is better than crashes which could be avoided > if the user knows that parallel operations on an image will fail > and result in data loss? > > I do not know, what is the better way, but I think global locking is a big > limitation... Hi Simon, Indeed, it's a very ugly workaround. Implementing real locking as proposed by Austin is however too late for 1.2 and I fear that it is the only way to get the lock per image. I tried to block display events only for the image the current tool is working on, but then I noticed that of course any display event may trigger a tool operation which is a bad idea while the tool is active. Once tools are GtkObjects it should be easy to ref the tool while it's active and simply allocate a new one for a simultaneous operation on another image. When the old tool finishes it's operation it will be unref'ed and disappear automatically if it's no longer ref'ed as active one. But of course, that's fiction :) bye, --Mitch
Re: [gimp-devel] Re: "Global Locking" for Gimp :-(
Sven Neumann ([EMAIL PROTECTED]) wrote: > > Is there any chance to do this on an "per image" base without > > hazzeling too much? > > It's not only parallel operations on an image. Gimp doesn't like you to > change the tool while it is active. So you can't rotate an image (using > the transform tools; using the rotate plugin should work) and change to > the paint-tool to paint even if you do this on another image. Tools are > global, so we have to disable tool-changes globally. Oh - forget my other mail then. Hmm - maybe the current way is the best we could get for 1.2... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Re: "Global Locking" for Gimp :-(
Austin Donnelly ([EMAIL PROTECTED]) wrote: > On Monday, 27 Mar 2000, Simon Budig wrote: > > Is there any chance to do this on an "per image" base without > > hazzeling too much? > > I proposed to add per-image locking a while ago, but apparently this > wasn't too well liked. I'm can't remember why. > > There are 2 tricky parts (as far as I can see): > > A) plug-in.c needs to take out an image lock when starting a plugin > operation, and release it on normal (or equally importantly) > abnormal plugin termination. > > B) what happens when acquiring a lock fail? Do you queue the > operation up on the lock (hard) or do you fail it (easy)? I think, proper locking is among the first things that should go in Gimp 1.3. However, it may be a little bit late for 1.2 :-( What Im thinking about is: Every user action starts in the image window. When we prevent a) clicks in the image to take effect b) selection of menu items (graying out?) if this image is "locked" we have a lot of potential crashes fixed. We could even give some sort of feedback through the cursor. Well, when a script or plugin randomly accesses the locked image then this is bad luck, but I think this should not happen too often. The way described above eventually could be handled inside the callbacks. Mitch: Do you see a chance to get it working this way? Is this reasonable? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: "Global Locking" for Gimp :-(
Hi, On Mon, Mar 27, 2000 at 09:34:35PM +0200, Simon Budig wrote: > I see, that Gimp can be crashed very easily when trying to use multiple > tools at the same image/layer. Michael adressed this: from the changelog: > [ snip ] > > Well - unfortunately this disables "user multitasking" with working > on multiple images. Admittedly I dont do this too often, but sometimes > it is nice to paint something while waiting for a big image to > rotate. (just tested - multiple plugins do work! :-) > > Is there any chance to do this on an "per image" base without > hazzeling too much? Or - if this is too hard to implement - do you think > that this limitation is better than crashes which could be avoided > if the user knows that parallel operations on an image will fail > and result in data loss? It's not only parallel operations on an image. Gimp doesn't like you to change the tool while it is active. So you can't rotate an image (using the transform tools; using the rotate plugin should work) and change to the paint-tool to paint even if you do this on another image. Tools are global, so we have to disable tool-changes globally. Salut. Sven
Re: "Global Locking" for Gimp :-(
On Monday, 27 Mar 2000, Simon Budig wrote: > Well - unfortunately this disables "user multitasking" with working > on multiple images. Admittedly I dont do this too often, but sometimes > it is nice to paint something while waiting for a big image to > rotate. (just tested - multiple plugins do work! :-) > > Is there any chance to do this on an "per image" base without > hazzeling too much? I proposed to add per-image locking a while ago, but apparently this wasn't too well liked. I'm can't remember why. There are 2 tricky parts (as far as I can see): A) plug-in.c needs to take out an image lock when starting a plugin operation, and release it on normal (or equally importantly) abnormal plugin termination. B) what happens when acquiring a lock fail? Do you queue the operation up on the lock (hard) or do you fail it (easy)? Austin
"Global Locking" for Gimp :-(
Hi all. I see, that Gimp can be crashed very easily when trying to use multiple tools at the same image/layer. Michael adressed this: from the changelog: 2000-03-25 Michael Natterer <[EMAIL PROTECTED]> * app/cursorutil.[ch]: new global variable "gimp_busy" which gets set/unset whenever busy cursors are added/removed. [...] Here starts the ugly workaround which simulates something like locking. If it works, it will close lots of bugs, if not, it's easy to remove again. So far, I didn't find strange side effects but Gimp is told to be a complex program :-) Please test this. Well - unfortunately this disables "user multitasking" with working on multiple images. Admittedly I dont do this too often, but sometimes it is nice to paint something while waiting for a big image to rotate. (just tested - multiple plugins do work! :-) Is there any chance to do this on an "per image" base without hazzeling too much? Or - if this is too hard to implement - do you think that this limitation is better than crashes which could be avoided if the user knows that parallel operations on an image will fail and result in data loss? I do not know, what is the better way, but I think global locking is a big limitation... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
