On 05/02/2012 10:17 PM, Alexandre Prokoudine wrote:This use case could have been made "quick" and "non-disruptive" by adding a new export command without changing the behavior of the save command.On Thu, May 3, 2012 at 6:10 AM, Jonathan Kamens wrote:Could you elaborate on why it is more logical and easier and effective to use? What use cases do you perform on a regular basis which are improved by the new interface?Working on a multilayer composition and quickly non-disruptively exporting to a Dropbox folder. Which is what like 99,99999% designers do today. This use case does not explain why it makes sense for the first time you save a file you loaded from JPG, the command is "Overwrite", which has no key binding, and after that first time the "Overwrite" command disappears and is replaced by "Export" and "Overwrite" is no longer available. This use case does not explain why it makes sense for an image which was loaded from JPG, was never an XCF, and does not have multiple layers, to default to saving as XCF rather than JPG. This use case does not explain why it makes sense for an image which was loaded from JPG, was never an XCF, and is saved back to the JPG from which it was loaded, to be considered unsaved and modified when you try to quit from GIMP. Aside from all of that, what percentage of the GIMP user base is "designers" for whom this functionality makes sense? The GIMP web site lists "photo retouching" first on the list of tasks that GIMP is good for, which would seem to imply that it is also the most common task that GIMP is used for, and the new interface is vastly inferior to the old for that task. Did whoever design and implement this change document the thinking behind it and the effort that went into usability testing / surveying the user base / whatever to confirm that it would help more people than it hurt? If so, then I would love a pointer to that documentation so I can read it. I'm certainly open to being convinced that enough people will be helped by this change that I'm in the minority and should get used to it, but "because the developer who made the change thought it should work this way" is not a particularly compelling argument. jik |