As long as people are putting their hands up, I never save in xcf and would prefer a workflow that was open, edit, save in same format.
However, rather than try to change the core code to appease those with a similar thought, I would like to know if it is possible to change this behaviour with a plugin. This way both sides are happy. Is it possible to write a plugin that re-maps core shortcuts and changes default menu layouts etc? On 1 March 2016 at 11:00, C R <caj...@gmail.com> wrote: > Sounds good to me. I'm more than capable of choosing the correct file > extension(s) and settings for myself. I think it's beneficial to have those > settings already intelligently defaulted to when saving. I believe it will > save some clicking in most workflows. Also good that it can be turned on > and off in settings. I'd keep the warning about not having saved an .xcf > file of the current doc when closing if there is indeed data to be lost. > That will have the same effect as the current [Sorry, you can't Save to a > jpeg, please use export instead] warning screen. When I type a file > extension, GIMP knows what I want to happen. It should do it dutifully, > then warn me at a later time that I should save my project construction > file before closing it. > > +1 from me. > > -C > > On Tue, Mar 1, 2016 at 2:52 PM, Simone Karin Lehmann <sim...@lisanet.de> > wrote: > >> >> > Am 01.03.2016 um 15:05 schrieb C R <caj...@gmail.com>: >> > >> > If Save intelligently determines the file format that is most likely to >> be >> > used to save, Export should not be necessary. Just "Save" and "Save As" >> > would suffice. >> > >> That's nearly exactly what I did with my patched version on >> http://gimp.lisanet.de >> I even made this a configurable option in the Preferences dialog. >> So, if one is interested, have a look at my patches. >> >> > We could use the "multi layer" & "layer outside layer boundaries" >> >> I'm currently testing only for 'multiple layers' but it's quite easy to >> add other tests. >> >> > convention to suggest that the user save to xcf, as normal to preserve >> what >> > they are seeing in the editor. The workflow would just involve flattening >> > the image (which also gets rid of alpha) first before saving to make the >> > Save default to the imported file format as a save suggestion. This has >> the >> > advantage of being intuitive and changeable merely by typing the required >> > file extension. For my various workflows, 99 times out of 100, it would >> not >> > be necessary to change anything. >> >> That was the reason why I did it. And I got a lot of positive feedback >> from users of my package. >> >> > >> > I'd be lying if I said the current export convention didn't trip me up >> > occasionally. It's been 6 years since I switched completely from >> Photoshop, >> > so in my case, it's not really blamable on convention anylonger. :) >> > >> > My 2p. >> > >> > -C >> > >> > >> > >> >> On 1 Mar 2016 8:43 am, "Tobias Ellinghaus" <h...@gmx.de> wrote: >> >> >> >> Am Montag, 29. Februar 2016, 23:57:10 schrieb C R: >> >>>> That would be terrible. Users not understanding the concept would >> >> suddenly >> >>>> be >> >>>> facing images where they can just save to JPEG while others can't, but >> >> PNG >> >>>> is >> >>>> still enabled (because they somehow added an alpha channel), and even >> >>>> other >> >>>> images support XCF only (maybe because the layer is bigger than the >> >>>> image). >> >> >> >> (I used "just" in the sense of "without any further actions" and not >> >> "only".) >> >> >> >>> No, that's not what I'm suggesting. If you import a jpeg for example, >> do >> >>> your editing, and end up with an alpha channel somehow, the save could >> >>> still default to the .jpg (the jpeg save dialogue could display a >> warning >> >>> that transparency will be lost). That does not prevent the user from >> >>> requesting a .png (by specifying that extension). It also does not >> >> prevent >> >>> the user saving as an xcf either for that matter. >> >>> >> >>> When closing the file, if the file is not saved as an xcf, and there is >> >>> extra data to be lost, well, the warning about it is there anyway. >> >> >> >> But that would mean to just go back to the status quo ante, i.e., revert >> >> the >> >> save/export dichotomy and bring back saving to arbitrary formats. >> >> >> >> [...] >> >> >> >>> My 2p. >> >>> -C >> >> >> >> Tobias >> >> >> >> [...] >> >> _______________________________________________ >> >> gimp-developer-list mailing list >> >> List address: gimp-developer-list@gnome.org >> >> List membership: >> >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list >> >> List archives: https://mail.gnome.org/archives/gimp-developer-list >> > _______________________________________________ >> > gimp-developer-list mailing list >> > List address: gimp-developer-list@gnome.org >> > List membership: >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list >> > List archives: https://mail.gnome.org/archives/gimp-developer-list >> _______________________________________________ >> gimp-developer-list mailing list >> List address: gimp-developer-list@gnome.org >> List membership: >> https://mail.gnome.org/mailman/listinfo/gimp-developer-list >> List archives: https://mail.gnome.org/archives/gimp-developer-list >> > _______________________________________________ > gimp-developer-list mailing list > List address: gimp-developer-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
