Ark

Okay, I think I have a quite concrete idea now. Also, I figured that the whole thing will be too big to fit into the normal prefs window so I think a separate window will probably be better. And since the "Edit external commands" window already features quite a lot of what we need for the design I propose here, I think it is be better to copy it, even though it means that the parts relevant for presets management will be there first. Also, this way, there is no need for a "(current)" preset. So,...

(Note: Assuming Arch and Xorg here. Not sure about Wayland but displaycal does not work properly when doing stuff with a colorimeter via xwayland. At least it used to be that way, not sure how things are today.) If monitor profile detection needs to be tested, use dispwin -I profile.icc (package argyllcms) to set the monitor profile. If successful, xprop -len 14 -root _ICC_PROFILE (package xorg-xprop) has something meaningful to say. There is an experimental function in PIL that detects a monitor...

Motivated by the scenarios described earlier, I would like to specify how I think color management should be controlled by the user. Let me first define some hypothetical GUI elements just so we can express this concisely. (How they will be implemented exactly is not important at this point.) A profile selector (PS) lets the user select between predefined profiles like "sRGB", indirectly defined profiles like "use default" or "use embedded" profile, and explicitly selected (ICC) profiles stored in...

Thanks for your animation experiments. According to https://github.com/python-pillow/Pillow/commit/f84684931d3e3ec0c9f6e1ff263fe7e51ee24013 , if I understand it correctly, a frame has a dict-like memberinfo with maybe a key duration. Maybe that helps understanding how the animation stuff in PIL works. If you feel like improving the image loading algorithm of MComix such that PIL can be used as an additional provider for animated images. that would be great! Also, it should probably go to its own...

For the record: It says that the MR is "merged" now without any issues. No noticable change in the repo compared to before the click.

Try to fix random failure to restore window geometry

It's not merged in the (remote) master yet, is it? It is already merged. If you go to the "Git" tab in the web interface, it will tell you that master is already at [d2e9eb]. Whatever, I will click on that button just to see what will happen.

Thanks for the separate MR. For some reason, SF still says that I could merge it in the web interface despite having it already merged locally and then pushed. Is it safe to press the "Merge" button in the web interface? Or should I just ignore it and close this MR with status "merged"?