(oops, forgot to send this) On Fri, 2011-01-21 at 13:32 +0100, Michael Natterer wrote: [...] > Yes, but still even the most basic, non grouped command might still > be triggering a whole series of atomic micro undo operations that > would go into an undo group associated with the command. I'm not sure why that's a problem. Probably I'm missing something. The _theory_ is that anything that changes the model goes through a command that is matched against a chain of handlers, with the default handler being the app core.. the _practice_ is that the granularity of that is up to the developers to expose or not expose, so if "open-as-layers" is an atomic command, then the handlers wouldn't ever see the "add layer" and "file open" commands happen and won't be able to change "open as layers" to position the layers automatically (for example). Long term, people writing scripts would probably push for more things to be exposed. > Look at the current set of undo pushing functions in > app/core/gimpimage-undo-push.h, which cover the entire set of > available user actions and PDB calls. They are really few > compared to what variety of manipulations are possible. It could change over time though. I'd really like to see things like the ability to call anything that has a keystroke or menu item or button to do it, for example. And at that point, if every menu command went through the command/handler chain, recording actions would be a lot more feasible. Or consider "undo last brush stroke and repeat with eraser instead"... We'll see - it's easier to have dreams than to dig ditches. Best, Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
