gg wrote: > I was naively expecting it to be considered and possibly discussed. Not refuted or ignored. Or attract insults. ignored? what I did in return is spell out the basic facts and usability considerations that put hard boundary conditions on this design problem. I expected you to be able to make the next step and adjust your brainstorming idea to these conditions. instead, you wanted to argue these away. either because you don’t get it or because it does not suit your argument. > So you seem to be saying this is not the place to discuss the way gimp UI is being developed. it is, but it has to be with respect towards those who can, and do, the contributions. if you want to be heard, stop the continuous flow of vitriol, especially towards anything that has a design and/or architectural approach. now, back to your mail of yesterday, the constructive one. I am going to summarise it because you are doing some catching up in there that bloats the mail: - you recognise that there is a competing situation between two different types of use - you say there is a problem with File->Open importing non-GIMP images - you have realised that xcf files are great for persisting work and are acknowledging the Project reality of graphics work. - you want to relabel: File->Open to File->Import, File->Save to File->Save project - you want a ‘new’ File->Save to to work in the old way: write to GIMP file or export to non-GIMP file, depending on the type of file associated with what is in the main window - you want a new File->Open that explicitly says that this is a non-GIMP file workflow here is my reaction to that: in short you want the old situation back, with the clear and unambiguous working-on-a-GIMP-file workflows being secondary to the one-shot png-in, png-out (same for jpeg, tiff, etc) workflows. this is clear from how you label the menus. I have two reasons to say: no way. the first one is how GIMP works: it can only edit GIMP files. sure, this is a superset of the simple file formats that we all like to take as examples: jpeg/png/tiff. it is not for other ones (ps to start with, there must be more import/export supported formats that have things GIMP cannot do). the old fudge that we got rid of in 2.8 is GIMP communicating that it is editing a non-GIMP file, when it is not. so you either import/export into GIMP format at the boundaries of the GIMP app and be clear about it. this is what we do now. or you do your plan, build in non-GIMP-file-workflows, where for each non-GIMP file type, you have to build a mode for GIMP where what is on the screen matches what is in the file, right after invoking Save. remember, this is the law. the second reason for saying no is checking the vision and what it means: <http://gui.gimp.org/index.php?title=Vision_briefing> this makes me 100% sure that the Project/Work workflow with persisted GIMP files is number one for our target user groups. one-shot working is a distant second. save + export has been designed for that, with added benefits of independently saving and exporting the same Work, and no more lost Work. the success of this design is validated by the reaction of the target user groups, which ‘get it’ instantly, although I also changed _their_ keyboard shortcuts and put ‘unsaved changes’ dialogs in their way. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gimp-developer-list
