GNOME Bugzilla – Bug 719667
Integrate patches from lisanet.de fork
Last modified: 2018-05-24 14:12:13 UTC
Hey, The release of GIMP on OSX from Simone Karin Lehmann has a list of patches. Many are obsolete, some we obviously don't want (like the save/export ones), but some would apparently make a lot of sense, according to Mitch. The patches are here: https://sourceforge.net/p/gimponosx/code/HEAD/tree/GimpPorts/ports/graphics/gimp2/files/ In the list, we could see that the carbon->cocoa patches seems outdated (we already use Cocoa platform), the save/export are unwanted, "many patches are obsoleted by our menu replacement" (dixit Mitch, not sure what is this menu replacement), "and some really really make sense", like "the color display change" (dixit Mitch again). The code seems good, but the style should be fixed. Unfortunately I have no Mac OS. Could a OSX dev go through this list, and select the interesting pieces? I have set up a wiki page so that developers can keep track of the reviewed patches: http://wiki.gimp.org/index.php/Hacking:Merging_lisanet.de_fork
I wished not everything I said on IRC made it into bugzilla ;)
The save/export patches are not immediately obvious, we'd need an explanation what exactly they do.
If the following description of the save & export changes in this fork is still accurate, then: https://mail.gnome.org/archives/gimp-developer-list/2012-November/msg00318.html
Well, reading this feature spec indeeds makes some sense to me. Basically it allows to "save" images into non-XCF format if and only if the image has just one layers (thus no layer information loss). Of course it still provides some risk, like if you save as 'jpeg', you may have quality loss. If you ran some filters, painted or anything which changed the image, do you really want to overwrite your original? In any case, I discarded these patches from the start because I was convinced you were kind of set on not touching save/export at all unless Peter proposes to. Glad to see there are still some interests in third party propositions. :-)
I am _very_ skeptic. This seems all like unpredictable magic to me. I think the recent usability improvements made save/export almost completely painless except for those who absolutely refuse to consider adjusting their workflow even the tiniest bit :)
I agree. Unless you would read the feature spec (and who read them except us?), you would just go and think "well sometimes saving works fine (= I can save by overwritting), sometimes it doesn't! I don't understand! GIMP is broken!".
Created attachment 263450 [details] [review] Patch to use 'About GIMP' in help menu, German translation see http://wiki.gimp.org/index.php/Hacking:Merging_lisanet.de_fork#To_be_Reviewed for further details.
Comment on attachment 263450 [details] [review] Patch to use 'About GIMP' in help menu, German translation This needs to be done different, according to platform standards. "_About" is right on GNOME.
Ok. My solution took the short way, because I found the effort too much for just a single, not so important menu item. But to be consequent you're right. On overview of relevant guidelines can be found in this Wikipedia article: http://en.wikipedia.org/wiki/Human_interface_guidelines
Well, so couldn't you just add a #ifdef for the OSX and Windows platforms then, and keep the current text on Linux and other platforms (where we assume GNOME guidelines are the right ones to follow, in absence of more specific ones)? That's a very small change on your proposed patch. :-) The link of Peter Sikking blog you added in the wiki page basically says this: « The lesson from all this is that there is no other choice then to grit your teeth, comply with the law (UI guidelines), traditions and mores of each desktop platform and focus on doing the right thing for users within the context of each platform. »
Created attachment 263498 [details] [review] handle migration on OSX of config folder of GIMP 2.8.2. Attached a patch handling the migration of OSX config from GIMP 2.8.2. It will search in the right order, first the new emplacement, then in ~/Library and finally in the home, since this is the order that GIMP followed on the OSX platform. This way, no version is left out, and there is never a need for manual update. I rewrote fully the patch and basically did not use the code from the fork though, first because it had a different logics (apparently they were patching the config dir already in GIMP 2.6), but in particular because it was doing some terrible things (like moving the older config folders!) and was not using OSX standard code.
Comment on attachment 263498 [details] [review] handle migration on OSX of config folder of GIMP 2.8.2. I think this one is fine to push to both 2-8 and master.
Generally, I think we should use --author=skl for these patches unless they are massively changed, in order to preserve credit.
I agree about authorship and I was planning to do so. But the 2 patches I fixed until now were so heavily modified that they have no much in common with the original proposition. This one for instance has not a single common line of code. Also even logics is very different because it seems Simone had changed the configuration folder in 2.6 already (and she never cared about not breaking code for other platforms since she compiled only for OSX). Actually I even think she will want to patch over our patch again now to handle her former patched GIMP 2.6 config folder. Her patchs were apparently really not meant to be contributed upstream. So I think I will just leave a note in the commit description. commit 7ef45be8902a4b7403d1d1736ca4f7c95b6449a8 Author: Jehan <jehan@girinstud.io> Date: Thu Dec 5 00:20:32 2013 +1300 app: handle migration on OSX of GIMP 2.8.2's config folder. GIMP 2.8.2's config was "~/Library/Gimp/x.y", before it got moved to "~/Library/Application Support/x.y" and after being saved in the home like other UNIXes. The migration code will now check all 3 places in the right order on OSX. Thanks to Simone Karin Lehmann for the original proposition.
Of course. I just wanted to mention it because I sometimes forget myself.
By the way, I changed the wiki page display (a table, as requested) and commented a whole bunch of the patches http://wiki.gimp.org/index.php/Hacking:Merging_lisanet.de_fork#List_of_Patches So now there are most of the patches that you can decide on without checking the code. I just wrote down what they do, but most of them, I don't know if that is a good change or not (like changing some shortcuts, adding new actions, etc.). So it needs someone else's input to decide if we want these.
No news for more than 2 years. Do we care or not? I would look closer at these if I had a MacOSX machine to check if any of these patches made sense. But since I don't, I am relying on people who work with OSX. So I remind I listed the patches with some comments and the state of merge/discard last I checked: http://wiki.gimp.org/index.php/Hacking:Merging_lisanet.de_fork#List_of_Patches Actual patches can be read there: https://sourceforge.net/p/gimponosx/code/HEAD/tree/GimpPorts/ports/graphics/gimp2/files/ There don't seem to have been much changes since then (some in 2014, that's all). Now I could check what are the changes and update the list — if needed — in the wiki page, but not if it just rots for 2 more years. So do we care at the changes of this fork, or should we just close the ticket? :-/
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/514.