ZeMarmot, main contributor of GIMP 2.10.0-RC1!

Two weeks ago, we released GIMP 2.10.0-RC1! This is our first release candidate before the stable release GIMP 2.10.0. Yes, you heard it well, the release you have been waiting for, for 6 years, is just around the corner!

What has ZeMarmot done exactly?

This was a very exciting release, and for the first time, I was even the major contributor, with 270 commits out of 784 (in-between 2.9.8 and 2.10-RC1, so counting the last 4 months). This is more than the third of all changes between GIMP 2.9.8 and 2.10.0 RC1. As for other participants in ZeMarmot project, Aryeom herself designed 2 missing icons, when she wanting to have a change of mind from animating marmots, frame after frame, and Lionel (one of the board member of the LILA association heading the project) worked on improving ruler subdivision for inches.

So yeah, at every release, ZeMarmot is more and more a major actor of GIMP. We are quite proud of it. Usually, after every release, I would list here a more detailed list on what I worked on, but there is so much in there, that this time, I won’t do the full listing. Let’s just make a quick summary of the most important works:

  • Improve debugging with a dialog gathering data and backtraces. We already discussed about it.
  • Auto-save of unsaved images just before a crash! Yep you read it well! So I know that GIMP is very stable (we had a bunch of remarks about this after we announced the feature). Yet this is software, and in software, shit happens. I am a developer of GIMP and one of the first to tell it: yes GIMP is not perfect; it is very stable, but still, it can crash. Even more: it will crash, some day, when you will expect it the least (it’s always when it strikes! ?). So now we are prepared. 😉
    To be accurate, it is not a 100% safeguard. By nature, a crash is a state where a process is very unstable. Hence we try what we can, and sometimes I’m sure the auto-save will fail. But in my tests, it succeeded most of the time. And that’s what matters when it will save your work!
  • Color-managing the color picker on macOS.
  • Screenshot with the generic Freedesktop API has been implemented. It is meant to replace all Linux desktop environment’s specific APIs eventually but needs to get reasonable features first. Therefore currently GNOME/KDE and X11 implementations still have priority.
  • New preferences settings for metadata export, and making so that all export plug-ins respect these settings (among other things, thanks to the creation of new API for plug-in developers: gimp_export_exif()gimp_export_xmp() and gimp_export_iptc()). This is a topic many may not care about, though it can also be a major feature to others since metadata can contain sensitive information and we know there are some people who prefer for their image editor to just never export metadata.
  • Various new APIs for plug-in developers, like:
    • gimp_get_pdb_status() to return the status of the last PDB call. This is needed for plug-ins which depend on other plug-ins’
      procedures. If for instance, a second-level plug-in is interrupted interactively, we don’t want to process this as an error but as a cancellation.
    • gimp_stack_trace_available(), gimp_stack_trace_print() and gimp_stack_trace_query() for debugging plug-ins as well.
    • gimp_context_get_distance_metric() and gimp_context_set_distance_metric() for distance metric used in gimp_edit_blend() (and future usage).
  • Improving gimp_edit_blend() API to use “gegl:distance-transform” operation, making it much faster.
  • Improve splash image down-scaling so that it appears at reasonable size on a wide range of screens.
  • Some vulnerabilities were reported in end of 2017, so I fixed CVE-2017-17784, CVE-2017-17786, CVE-2017-17787 and CVE-2017-17789.

In the middle of this all, I already announced the new package mypaint-brushes.
And then there are all the little micro-features, but even more all the bugs we fixed! Actually I don’t think I could have fixed that many hard-to-reproduced bugs before, as easily as these last few months thank to our new debugging system. So I am really so happy I implemented this. Even though some may think it is not that important (not an actual feature for painting or editing images or whatnot), which is something I read on some forum, I personally feel like this is one of my major contributions to this software because I know it will improve its stability and robustness even more (it already started). 😀

I told you, earlier, that bug fixing and stability was my personal goal until 2.10. As you can see, I really meant it. 🙂

Mentoring a student to code in GIMP

In other cool news, a student, Darshan Kadu, approached us with a FSF internship, and continued one of the existing port, for JPEG2000 format support (finishing the port of our implementation from Jasper to OpenJPEG, since the former is getting deprecated everywhere), and I am the internship mentor. This is not the first time I worked with university students since I gave a few courses in a university in Paris last year, and I must say I like the interaction (whether with a single intern or with a whole class).

Now I had a few exchanges about possible future projects for interns in GIMP, possibly in GSoC (for memory, GIMP project used to do a few GSoC but stopped a few years ago; I believe the last GSoC internship happened just when I came in the project myself so I never had the chance to mentor someone in GSoC). So as I saw people proposing for interns to do all sort of major implementations in the core of GIMP, I’d like to comment on this.

Personally I am mostly interested in mentoring because I like accompanying students when they discover real development world. If we can get a few cool patches in the process, this is cool. But this event should not be considered as a cheap way to get code. Any project which relies mostly on this to improve will mostly get hardly maintainable code, which took a lot of your time as a mentor but may never end up merged in your master tree.

Whatever your job is, picture yourself when you were student. Now imagine that you suddenly dropped your student self into your current position which you are in after years of hard work and learning the job though actual real-life projects, successes and failures. Do you really believe that your student self would have just revolutionized your current job in just a few months? I hope you don’t say yes, because that would be a bit sad if you don’t believe you evolved since you were students! ;p

So yeah, GSoC or any internship is very cool because we can work with some bright minds of the future of software. But these are not and should never be a magical way to get cheap, fast and good code. If anyone really believe this, something is wrong!

Release Candidate, uh? Stable release soon then?

Yep we are definitely working as hard as we can to get the stable release as soon as possible. We even just got under the 2-digit of blocker bugs the other day (though we are now back at 10 blockers)!

Actually we had to discuss a bit before naming it a RC. Indeed we believe that this is not really Release Candidate material. Well… not if we wanted to be really thorough. But in the same time, we are a bit tired of dragging the developement of GIMP 2.10 (for 6 long years now!). And making it a RC was our way of pushing a bit the development and ourselves, like a step in the right direction. Now you should really expect the stable release soon, unless we discover something really bad (knock on wood!) in the meantime.

Have fun testing GIMP 2.10 RC1 everyone! 😀

 

Reminder: my Free Software coding can be funded on:
Liberapay, Patreon or Tipeee through ZeMarmot project.

9 Replies to “ZeMarmot, main contributor of GIMP 2.10.0-RC1!”

  1. I understood “270 commits out of 784” since 6 years ago, but it’a actually since the 2.9.8 development version from mid-December.

    Good job with the debugging system, sounds great. Good luck with the release!

    > But GSoC should not be considered as a cheap way to get code.

    It can be, if the student is very good. You decide whether to mentor somebody, and if you require early involvement you have a pretty good idea what to expect.

    > Any project which relies mostly on this to improve will mostly get hardly maintainable code

    Not if you require the work to be split in small steps so that the (high-quality) code is merged gradually, or when the merge is not possible for other reasons the code is merge-quality already when the next step is started.

    1. > I understood “270 commits out of 784” since 6 years ago, but it’a actually since the 2.9.8 development version from mid-December.

      Yeah, no. 784 commits in 6 years would be quite sad. 😉
      I updated a bit the sentence to make this clearer.

      Also let’s be clear I am not the biggest contributor of “2.10”!!! This is Mitch, GIMP maintainer, and by far. He is also still much efficient than I am, and more knowledgeable on most areas, so I love to work with him.
      Mostly this title is a bit of marketing for our project since we are in constant crowdfunding and want to be able to make a living by developing Free Software and Libre Art. 🙂
      Fortunately GIMP has a few very skilled developers, and this is all the more awesome.

      > It can be, if the student is very good.

      Indeed. I’m sure some student could even be better technically than a mentor. Still I have never really loved the idea of exploiting cheap labour. Well, at least in GSoC, they have some very decent stipend, so that’s quite ok, clearly. It’s quite fair.
      Yet I don’t want to forget that these people are students and we are also here to help them.
      Anyway that’s all just cheap talk. This year again, we are not participating to GSoC. This was just a discussion (about trying again GSoC) which emerged a bit when I accepted to mentor a student for FSF. Let’s see what we decide to do next year.

    1. Unfortunately not good. It is in what we call the “playground” area, which mostly means it is hidden by default.
      To have it shown on stable builds, you have to:

      * Start GIMP from command line with –show-playground option (hidden option).
      * Go in Edit > Preferences > Playground
      * Check “Seamless Clone tool” to make it finally available in your toolbox.
      * Restart GIMP.

      Basically it has been mostly untouched for years. Last I tried, I think it was utterly slow, and possibly bugged and unstable (crash GIMP), though I am not sure I remember it all that well. I have not tried again for many months. I especially remember it to be so slow that it is not *really* usable as a canvas tool.
      If not mistaken, this is a good example of giving too ambitious projects to students. As far as I know, he was very good and he did a very good job within the internship time. Yet this has never been *finished*, i.e. it was in a very good demo state, not in a usable state (stable, fast, unbugged…).

      So yeah, don’t expect this tool for 2.10 unfortunately. ;-(

  2. Hi,
    Great to read about this. In these status updates where there is stuff like “10 remaining blockers”, put a link to the tracker bug – you never know who might click through and look at the bugs.

Comments are closed.