Crowdfunding for extension management in GIMP (and other improvements)

One of my long-brooded project for GIMP was an extension management system. I had it for years (older message from me I found about this was back in 2013, just a year after I started contributing).
I finally started working on it a few weeks ago!

I actually have a looot of projects regarding extending GIMP: better plug-in API, bidirectional communication with GIMP core, even GUI hacking through plug-ins, why not! But the first issue was: installing plug-ins and resources suck right now!
Let me explain the plan of things to come further below, but first a bit of a reminder:

You can crowdfund ZeMarmot/GIMP!

Everything done so far and to be done only happen thanks to ZeMarmot project. This project is paying for GIMP development, since this is all done for us to improve our production pipeline.

Right now, we don’t even have enough monthly funding to pay a single person at minimum wage. Yet we managed to survive at 2 for years. We had times of slight depressions and burnouts. Actually we kind of always have these lately.

We hope to at least crowdfund enough to pay 2 salaries at minimum wages! That would require about 4 times our current monthly funding. This is why for once I decided to detail more of my development plans in advance (rather than in the end when it is done, as I remind we are major GIMP developers) and I start by the crowdfunding call rather than the technicals, because we really need you!

If you like how GIMP has improved lately, and want it to continue this way, can you help us? If yes, our project is being funded on the 2 following platforms:

» Patreon crowdfunding (USD) «

» Tipeee crowdfunding (EUR) «

What is an extension?

What I call an extension is anything which can be installed in GIMP. In my current development code, an extension can already pack:

  • plug-ins
  • brushes (core and MyPaint ones)
  • dynamics
  • patterns
  • gradients
  • palettes
  • tool presets

In the future, it could also be:

  • scripts
  • templates
  • themes
  • icons
  • … and whatever else data I may forget!

What is management?

What I call “management” is basically being able to:

  • Search for new extensions (made available in remote repositories);
  • install new extensions;
  • uninstall extensions;
  • disable extensions (make them inactive without full removal);
  • update extensions: when the extension creator makes a new version available, GIMP should tell you and give you the possibility to update in  a single click.

You probably all have an idea how it would work. For instance your web browser (i.e. Firefox, Chrome, etc.) probably has extensions as well and you may have searched/installed some. Well basically I want the same thing in GIMP.
Until now, “installing” an extension in GIMP implied making a web search, finding some compressed archive (sometimes on shaddy websites) with weird instructions asking you to put and unzip files into some hidden folder on your disk. Sometimes it was working, sometimes not and usually many barely understood what one were asked to do. Well it sucked.

Extension creator point of view

If you create resources for GIMP, be them brushes, splash images or plug-ins, here is what you’ll get: we are going to set up a website where you can upload your extensions. We don’t know yet if we will recycle the old registry.gimp.org domain (now down) or set up a new one (extensions.gimp.org?). We’ll see.
The code for the website will be on gitlab.gnome.org, though right now the repository is empty (working on GIMP core side first) as I just requested for its creation a few days ago.

Technically an extension is mostly about just adding metadata to your data: an extension name, a description, even screenshots if relevant. Your website URL is also welcome, as well as your bug tracker URL, so that we can redirect people to you when your extension has problems (making your development more efficient). In my current implementation, I chose the AppStream format for the metadata, which is well known by Free Software developers, quite featureful and easy to write (we still have some details to figure out for Windows and probably non-Linux support in general, but I am confident this will go well). Metadata is the main component to be able to search and manage extensions correctly!

We are extending it a bit with a few tags so that you can describe what kind of data your extension provides. For instance, here is the skeleton for metadata of an extension which ships a set of brushes:

<?xml version="1.0" encoding="UTF-8"?>
<component type="addon">
 <id>info.libreart.brushset</id>
 <extends>org.gimp.GIMP</extends>
 <name>My cool brush set</name>
 <summary>A collection of brushes for GIMP</summary>
 <url type="homepage">https://libreart.info</url>
 <metadata_license>CC0-1.0</metadata_license>
 <project_license>GPL-3.0+</project_license>
 <releases>
  <release version="0.1" date="2018-06-07" />
 </releases>
 <requires>
  <id version="2.10" compare="ge">org.gimp.GIMP</id>
 </requires>
 <metadata>
  <value key="GIMP::brush-path">brushes</value>
 </metadata>
</component>

That’s it. You put the brushes inside a brushes/ subdirectory (this is what is described in the “GIMP::brush-path” key) and you are done.

GIMP point of view

One of the cool thing which could happen on GIMP side is that we may transform some of our core data and plug-ins into core extensions as well. This would have 2 direct consequences:

  1. It will be possible to easily disable features or data you don’t care about. I read some people even went as far as deleting files to make their GIMP menus clearer by removing features one never use. Well now it should be unneeded.
  2. Updates could happen out-of-releases: a release of GIMP is a lot of work and preparation. You noticed how now we do them faster now? Well this won’t stop. Nevertheless if we can also update a core extension in the extension repository, this would make our job easier, we could do less core GIMP releases, yet you would get even faster updates for all the small features out there.

What about security?

Well that’s the big question! Let’s be clear: currently security of plug-ins in GIMP sucks.

So the first thing is that our upload website should make basic file type checks and compare them with the metadata listing. If your metadata announces you ship brushes, and we find executables in there, we would block it.

Also all executables (i.e. plug-ins or scripts) would be held for manual review. That also means we’ll need to find people in the community to do the review. I predict that it will require some time for things to set up smoothly and the road may be bumpy at first.

Finally we won’t accept built-files immediately. If code is being compiled, we would need to compile it ourselves on our servers. This is obviously a whole new layer of complexity (even more because GIMP can run on Linux, Windows, macOS, BSDs…). So at first, we will probably not allow C and C++ extensions on our repository. But WAIT! I know that some very famous and well-maintained extensions exist and are compiled. We all think of G’Mic of course! We may make exceptions for trustworthy plug-in creators (with a well-known track record), to allow them to upload their compiled plug-ins as extensions. But these will be really exceptional.

Obviously this will be a difficult path. We all know how security is a big deal, and GIMP is not so good here. At some point, we should even run every extension in a sandbox for instance. Well some say: the trip is long, but the way is clear.

Current code

As said, I am already working on it. Current code can already load extensions, read the metadata, enable and disable the extensions. These are the bases. I still have a lot to do on the bases (for instance the plug-ins need some special-casing for enabling/disabling).

Then I will need to work on getting the extension list from repositories, and work on the web side (Patrick David should help me there, since you can recall he also made our new website and Pixls.us, the trendy community site for photographers using FLOSS).

I cannot say when this will end and I do other things in the same time (lately I have worked on improving GIMP code for HiDPI, and of course I need to work more on our animation plug-in; and much much more!). But I hope a releasable state should be done by end of the year. 🙂

Thanks all!
And don’t forget we are really in need for more funding on Tipeee or Patreon (see also ZeMarmot generic donation page) to help us going forward!

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.

Automatic bug report and stack traces for GIMP

While I was working on yet-another-crash without a backtrace, I realized that we could just generate automatic backtraces upon crashes and tell people about it. This is how I ended up writing a debug tool for GIMP, popping-up a dialog with a nice text encouraging to report bugs. You’ll notice that the main text is non-technical. The goal is not to display non-understandable error messages which nobody will understand. All the technical part is in the below section and is just to be copied by a single button click and reported to us verbatim. 🙂

This technical part contains: GIMP version (and commit information if available), compiler, main dependency version, and finally the errors and backtraces of these errors.

Note: this doesn’t “report” the bug on your behalf. Anyone still has to make the conscious action and go on our bug tracker. But we make things easier and just a few buttons and a copy-paste away.

Someone asked me if I could make a blog post about it, so here it is.

How does this work?

Used to be based on glib…

We already had some backtracing capability in GIMP, mostly using glib API g_on_error_stack_trace(). The main problems of this API:

  • that this function outputs to stdout (which means that you needed to run GIMP from terminal to get the trace, and until now this was only used with specific command line options or on unstable builds);
  • sometimes it was not working for weird reasons;
  • it works only in Unix-like operating systems (in particular not in Windows);
  • it is based on gdb only (as I soon discovered)

So I ended up looking what this function was doing. As I said, the basics is that it simply uses gdb if it is installed on the machine. I am still unsure why, but it was doing so using the interactive mode, therefore entering commands through the standard input with a pipe. Why is it weird? Because gdb has a batch mode especially done for such non-interactive calls. I suspect actually that some of the times g_on_error_stack_trace() failed to work correctly was maybe because it was stuck (but I am not sure, I have not tried to dig much more, so maybe I say shit). But the worse issue was that it was simply printing to stdout. So if I wanted to get the output inside a string in order to use it in the graphical interface (we should not expect people to run GIMP from a terminal!), I had to do more piping of the output. Well at some point, that was just ridiculous to stack processes one after another after another after…

… then based directly on GDB…

This is how I started to reimplement the feature. I simply run gdb in batch mode, and I keep the result in a string for later display in a dialog. This was actually very straightforward. See commit bb88a2d52f.

This also allowed me to get a slightly better stacktrace since I could customize the command. So I request “backtrace full“, getting us local variable contents.

… and LLDB…

Then I remembered that some bug reporter on macOS was using lldb, the debugger from the LLVM project. Since LLVM is default on macOS, I assumed that LLDB is much more common there than gdb too. So I added support for it. This was quite easy too, I just had to search for command equivalency. See commit 4ca31b0571.

… and finally the GNU libc!

Finally I was told of the backtrace() and backtrace_symbols() API. This seems to be a GNU-only API (man says these are GNU extensions). Anyway this should make these always present on common Linux distributions, which is very good news. It means that we will always get “something” on Linux (also the result is much quicker than calling gdb or lldb). Unfortunately the output of  backtrace() is not that exhaustive: basically you get function names, and in particular neither file name nor line number even if you built with debug info, nor variable and parameters contents. So it’s a bit less useful. Yet it’s better than nothing! See commit 4fd1c6c97c.

So in the end, my tool tries gdb, then if absent, lldb, and finally fallbacks to backtrace() if available. This should hopefully gives us traces of crashes and errors in most cases!

The difficulties

Issue 1: do not rely on memory allocation after a crash

There were still a few issues. One of them is that you may notice that I use this dialog for 2 kind of errors: fatal errors (crashes) and non-fatal errors (WARNING, CRITICAL, etc.). l use the same code, but while testing, I realized that I often could not create the dialog from the main process when GIMP crashed. In Linux at least, once the program crashed, I was able to catch the terminating signal enough to do last minute actions, but it seems allocating more memory was not amongst the possible actions (that was my assumption based on tests, I may be wrong, don’t take this for manual talk). Well I guess that makes sense to forbid more memory management, especially if the crash is related to memory bugs. This means that even just creating a new dialog is not possible (requiring allocation of a new GTK+ widget).

This is why when crashing, I run the dialog as a separate process, whereas I run it from within the main process for non-fatal bugs.

Issue 2: backtrace() needs to be run by the main process

When running as a separate process, should the back trace be generated by this other process or from the main process? At first it made sense to have it generated through the new process, but then this has 2 inconveniences:

  1. I am duplicating the back-trace generation code (since I sometimes need to run it from within GIMP, sometimes from outside) and code duplication is never good (even maintenance-wise, you end up with different version. This sucks). You can make common core code as exception, but it’s just not ideal (it makes the build rules complicated).
  2. From the outside process, I can attach to the main process with gdb or lldb but I cannot use backtrace()anymore. That would mean that a lot of people would not get the auto-generated traces (not everyone installs a debugger!).

This is why I decided that the backtrace is always generated by the main process and in case of a crash, it is passed along through a file, instead of a parameter. I could have piped it which would have been just as easy, but Dr. Mingw (see below the Win32 section) was already using a file. So I chose to do the same to be as consistent across platforms as possible (also a file has some advantages: in the extreme case where the dialog breaks too, we may ask a bug reporter to look if a file has still been generated with the info).

Also since — as I said in issue 1 — memory allocations are more likely to fail during crash handling, you need to use backtrace_symbols_fd() instead of backtrace_symbols().
The _fd() variant is guaranteed to run without memory allocation (this is written in the man). And now we have traces on most systems, still with GNUlibc fallback!

Issue 3: error avalanches

Another issue is that, in case of non-fatal errors, you may often have a few of them one after another. Sometimes they may be generated as dominos (you get the second as a consequence of the first error), sometimes it’s because of long-running operations which would just reproduce the same errors many times.

Worse case scenario: a long-time contributor, Massimo, directed me to a bug which would output dozens of thousands of errors in a few seconds. Actually that depends on the size of a selection, and in some of my tests, I had hundreds of thousands of errors!
Obviously you don’t want to create a dialog each time (this example was not even a bug which crashes GIMP, but creating hundreds of thousands of dialogs may do the killing job!). So you have to just update the current dialog with additional errors. But even doing so is very time consuming. Updating a dialog hundreds of thousands of times in a few seconds is at least likely to freeze the whole GUI for a dozen of minutes (I know, I tried!).

So I decided to limit the backtracing, but even the error handling. In a single dialog, I add up to 3 backtraces and 10 errors at most. Any more errors would just be redirected to stderr.

Issue 4: debugging preferences

Moreover do we want the dialog to appear for every kind of errors? In particular, we have WARNING, CRITICAL then all fatal errors. CRITICAL are usually really bad, so we definitely want debug info here. But what about WARNING? I mean, they  are bad too, and they are signs of a bug somewhere. But these are more minor bugs, sometimes also bugs on external data which we warn about (and have no control on). Also we often output warnings when we encounter bugs in other software (for instance, one of the recent bugs where my dialog worked was on a bug in KDE’s API for color picking, and there is not much we can do about it in GIMP but report upstream). So I added finer-grained settings, because you certainly don’t want to make creating with GIMP painful if it pop-ups errors every few hours!

Actually it is even possible to disable all debugging through GIMP preferences, even during crashes, if someone is really not interested at all in reporting bugs, hence contributing to GIMP improvement.

Note: on Windows, the debugging preferences page doesn’t exist at all because the backend we use is not customizable anyway. See dedicated section below.

Issue 5: multi-threading

As explained, we don’t only handle crashes, but also runtime errors. Since GEGL is so close to the GIMP project, it made sense to handle its errors as well (actually long-term, it would make sense to handle errors from any dependency, but let’s do it step by step). So I also catch GEGL’s WARNINGs and CRITICALs. But then I realized that since GEGL uses a lot of multi-threading, getting a backtrace from the main thread when the error happened in another was completely useless.

This combined to the fact GTK+ code must be run in the main thread, therefore to create or update my debugging dialog, I need to pass the information from the thread where the bug occurred to the main GTK+ thread. This can be done with gdk_threads_add_idle_full(). This call obviously adds a delay so you’d end up getting traces from the wrong code, and after an unknown delay. This is double useless.

As a consequence, to handle multi-threaded debugging, I needed to make sure that the stack trace was generated from the thread the error happened, without any delay, and only then it could be sent to the main thread with an idle function.

Issue 6: the tweaking

Then you have all these little details to make the experience not too terrible (at least I am not saying we should make it a good experience, a bug is never a good experience! ;P).

For instance handling a crash, I add a button “Restart”, allowing — as the name implies — to at least restart GIMP immediately.

When non-fatal bugs are reported, we should advise people to save their images and restart GIMP (of course, for crashes, they won’t have the possibility to save themselves, so don’t make them sadder by reminding them).

Also I have to be extra careful to not generate new WARNING or CRITICAL from within this code because then you could create cyclic calls. You don’t want to end up crashing the software because of the debugger which initially fired up only for a minor bug.

Well you get the idea! These are the kind of tweaking you just discover as you implement such a system and you have to take care of them as you go on.

Future work

Something we have been discussing would be to save the opened images in backup files upon crashing. Of course with some kind of crashes, it may not be possible, but that is worth trying at least!

I’ve actually started working on it (with commit d916fedf92  from yesterday). As expected, it’s working most of the time, but while testing various crash conditions, I had some cases where last-second backup failed. I have not dived into the code yet to understand why and what, and if there is a solution to these.

GIMP is quite stable now (at least on GNU/Linux), and quite rarely crashes (well I say this but we had some instability these last few days because of core changes in selection and channels so the auto-debug dialog was very useful). But for this one time when it happens, handling it the most gracefully possible implies saving the current state of work. Then obviously next step will be to propose recovery on next GIMP start.

More on this later as I will continue working on it…

What about Windows?

Now the last remaining issue is Win32! Having GDB or LLDB there might be possible (I have not checked) but probably not the best path. It turns out a contributor, Mukund Sivaraman, did already add support for backtrace generation on Windows upon a crash, back in 2015. This is using the ExcHndl library from the Dr. Mingw project. Basically this is extremely easy to use since there are only 2 functions in the API: one to init the library, one to choose a file where the backtrace will be outputted.

void ExcHndlInit(void);
bool ExcHndlSetLogFileNameA(const char *szLogFileName);

So yes, since 2015, backtraces were simply outputted into a file somewhere, and people just never knew where and how to find it. What I did was simply to piggy-back on this feature, grab the backtrace from the generated file, and display it in our GUI. And that’s it!

Since I needed my own code to run after Dr. Mingw, I had a look how this tool actually made its job. In its code, I saw it was using  SetUnhandledExceptionFilter()to run its action just before the crash. What I did was adding another exception handler with the same function, but registering my handler first beforeinit() Dr. Mingw. This way Dr. Mingw call my handler immediately after its own because it keeps track of any handler previously set and call it after itself.
See commits ae3cd00fbd and 4e5a5dbb87.

Now this has a few limitations: the backtrace generated by Dr. Mingw is not that complete compared to a good gdb backtrace. Also sometimes, I had some crashes which this tool would not catch. I am no Win32 expert and did not spend much time on it, so I don’t know why.
Finally this works only on crashes, in particular I cannot generate backtraces on a whim as I can do on other platforms, which allows to generate backtraces even on WARNINGs or CRITICALs messages for easier debugging, even without a crash.

Well in the end, Win32 always ends up less featured and most annoying to debug. I guess there is nothing to be done since I remind we are still looking for Win32 developers on GIMP. We have had very few contributions of Windows developers for all the years I’ve been around, quite sadly! If you are interested to contribute on this cool piece of software, be very welcome!

We got our first reports with automatic traces!

Even though the tool is still only present in the development version, some people build GIMP from master, and we already got a few bug reports with traces included directly! This is very cool.
Actually even Aryeom got such dialogs, which resulted in some bug fixes already (and more to come)! 🙂

So yeah when I fixed my first bugs thanks to these automatically generated back traces, that made me happy because I felt this new tool will make life a lot simpler and I knew my time was well spent. 😉

You’d think a developer of GIMP would not be happy to get a back trace. And yeah, I’d prefer that GIMP was perfectly bug-free. But there is no such things, and as long as we get bugs, we may as well get well-illustrated reports to easily fix them. This is why I am happy! We are constantly on our way to a much more stable GIMP.

Yeah!

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

Ibus-Hangul and Compose key: the incredible journey of a simple patch

Today I decided to tell how I reported a bug (then ended up fixing it) on a non-GIMP related project. Well I do regularly this kind of stuff, and this could have just been one more of these silent commits to a random project as I did many times in my life. But since I decided recently to post more articles, well… I may as well tell a story as one-time contributor (as opposed to “regular contributor”) for once!

Also I think the whole process of reporting a bug on projects you don’t know at all — worse! A whole stack of software you don’t know much! — is quite interesting for people wondering how they should report bugs happening to them.

Finally another reason is to advertise a bit my work, since I remind I am trying to get my Free Software coding crowdfunded through ZeMarmot project.  I am hopeful these kinds of side-stories highlight how our project is useful for Free Software as a whole, not just GIMP. Because yes, that seems unrelated, but in the same time, if I can be funded to hack Free Software full-time, it means more such unrelated bugs can be fixed! So you can consider that this kind of patch is also funded when you crowdfund ZeMarmot. 😉

The context

My main input is the ibus-hangul (Korean) input engine,  and the main languages I write are English (ibus-hangul is basically the same as “English (US)” layout when in LATIN mode, which is my default mode) and French! Sometimes when needed, I can easily switch to writing Korean while keeping the same layout.

To write French, I simply mapped a Compose key on the CapsLock key (which I don’t need). Why not switching to a layout with French characters? Well mostly because I don’t like the default French layout and am used to the US one (I have used it for a few years now), and I am also used to using Compose (I can write quickly enough all French characters with Compose, most people would not know the difference in term of typing speed).
Moreover I don’t mind changing layouts but this can be a bit confusing at times, especially if you need to change your layouts every few minutes. It’s better to just keep the same if possible.

Finally this is also the input which Aryeom uses (her main language being Korean) and she writes both in Korean and in French on daily use.

The route from bug to patch…

Or: how to report a bug … when you know very little about a software stack of dozens of software (really device input goes through so many layers that it’s making me crazy!)

Step 0: the bug!

We were using successfully our setup up until Fedora 25: Korean’s ibus-hangul IME with a Compose key. This Compose key settings was done through GNOME Tweaks Tool.

 

Then some fateful day, we updated to Fedora 26. And paf! The Compose key stopped working. Oh fateful day!

We hoped that it would be fixed by Fedora 27 (since we updated late to Fedora 26, Fedora 27 release was just a month away), but it didn’t.

Step 1: I click this button and it doesn’t work => GUI problem?

Back then though, I didn’t link the bug to ibus or ibus-hangul yet.

I first tried to track this issue in GNOME Tweaks tool (hoping that might have just been just a GUI bug; by the way, now the bug is fixed and the issue was not in Tweaks, but it seems I cannot close the report in gitlab and nobody is answering! If someone from the project reads me: just close the report, please) since that’s where I was setting the feature.

Of course, my secret hope was to just see other developers take care of it and not having to dive into unknown code. Don’t get me wrong, I’d love to fix every bug I encounter myself, but I also have a limited life span! ;P
Also I am lazy. I hear that’s a good trait by the way, nothing to be ashamed of. So really hoping someone else does the job at your place is my best expectation.

Step 2: going deeper into layers

But then after waiting for more than a month with a broken compose key, I couldn’t stand anymore to write my French texts without accents. So I investigated a bit more by myself and whistled in the wind (as you can see, I still haven’t had a single answer in 3 months on this first bug report. Bit sad 😞), looking for which dconf key Tweaks Tool was changing, and seeing that it worked at least here: the dconf key was properly updated so Tweaks was likely not at fault.

So was GNOME the culprit not doing proper action with this dconf value? To decide this, after I understood that this was just a X11 options (the bug also happened on Wayland though), I tried various combinations of trying to set “compose:caps” directly with setxkbmap, or even updating XKBOPTIONS directly inside X11 config files (something I hoped I would never have to do ever again, and for years it seemed like it would hold) and restarting X.

It didn’t work. So I became more certain the problem may be deeper and something was broken in X and Wayland. I asked someone who knows better than I on this whole graphics desktop stack (Thanks Carlos for always helping me out! I know I can be annoying sometimes! 😛).  He advised me to open a bug report at libxkbcommon, which was used both for X11 and Wayland. So I did.

Step 3: …and deeper…

Continuing my own investigations, I realized that the problem was not happening on every input method, but even stranger, the input order changed the behavior! 😥

This is when I was told the order indeed matters and that’s expected, which I find a bit weird since it makes for very particularly unique bugs. But anyway I was not here to argue about these kind of design decision. So I followed libxkbcommon‘s developer’s recommendation and opened another report at xkeyboard-config instead.

Step 4: and back up!

Then I left time pass again for about a month, but once again failed to get an answer, therefore tried to investigate more myself, once again. I reread and thought back about my previous investigations and realized that the broken inputs were all Ibus ones (it turns out I only use Ibus inputs nowadays, mainly the Korean or sometimes the Japanese one). For people wondering what is Ibus, this is the input framework for writing languages complicated enough for which just a layout change would not work (for instance Japanese, Korean, Chinese, etc.). This is when I first started to be on the right path.

But is the issue in Ibus or specifically Ibus-Hangul?
To answer this question, I thought to be clever (I wasn’t necessarily!) by checking Fedora repository contents. There I realized that Ibus-Hangul package didn’t change its version (1.5.0) from Fedora 25 to 27. Since my issue appeared in Fedora 26, I went with the assumption that the broken part was most likely Ibus (which indeed upgraded from Ibus 1.5.14 to 1.5.16). So I opened a bug report for ibus.

This time, I had a very quick response (thanks Takao!), then a few exchanges not only telling me that the issue was indeed triggered by a change in Ibus, yet that was not really a bug in Ibus (well it’s a bit sad that Ibus does not guarantee compatibility, but I can also understand why). Ibus-Hangul had to be updated to follow Ibus changes. Better, the developer of Ibus gave me the necessary hints to update Ibus-Hangul.

Step 5: the patch

And then a few hours later, I was able to clone, read, understand and finally simply patch myself Ibus-Hangul. I immediately installed it for myself and for Aryeom, then I went and did a pull-request on upstream project (⚠ important: never forget to contribute your patches upstream! I know, it means a bit more work; sometimes making clean code which will be accepted upstream may even take longer than making the quick-and-dirty fix for just yourself. Yet that’s how the whole software ecosystem will improve! Imagine how bugged Free Software would be if others were not contributing their patches!).

Hopefully my pull request will be accepted soon even though ibus-hangul activity seems a bit slow (yet existing! There were commits 2 months ago). But anyone in our case reading this, you can already build and install with my patch if you need.

This is also a good example to work from if ever you use another Ibus input method with the same problem. That should be quite easy to update all Ibus engines hopefully.

Step 6: it’s never finished!

The issue is mostly fixed, at least on Ibus side apparently. There is still some remnant of issue, which is that my remapped CapsLock was now working both as a CapsLock and a Compose key which is obviously not the expected result! So if I want to write ‘œ’, it would output ‘Œ’ and locks capitalization. That’s not good…

Getting again a bit of help from Takao Fujiware from Ibus project (really thank you a lot!), it seems that the bug is in GNOME this time, since I can work around it by running directly a command line command:

setxkbmap -layout us -option compose:caps

Also I realize that the issue happens even with non-Ibus inputs this time. So somehow it would seem that GNOME may not set properly the option? Let’s wait and see for answers on this report. At least this time, I have a workaround (I even have 2 different workarounds, but let’s not complicate things!)! 🙂

Conclusion

On our beloved GNU/Linux operating systems, the text input situation is mostly ok, though sometimes I must admit I wonder how many people use slightly more exotic input settings since I regularly encounter funny bugs. Well I have lived in Japan for 2 years and in Korea for 1 year, so I also know that Free Software communities are unfortunately less common over there. And among these communities, people also needing a Compose key must be even rarer.

As you may know, I love languages, so I really hope that things will improve regarding any language support. 🙂

As for the whole route from a bug to a patch, it is interesting to see how it took 5 bug reports to finally get to the right project, and a little more than 3 months for a patch written in a few minutes once I knew what this was about. Somehow this is part of the “unseen”, slow, lengthy and boring work done by every contributors out there (even more one-time contributors since they start without the whole package). And no matter how good you may think you are, you are always a newbie somewhere. I personally even consider to be a constant beginner on most topics, even the ones I know best. This makes things easier because I don’t set impossible expectations on myself but also others.

Thanks for reading my story!

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

GIMP 2.9.6 & ZeMarmot

Note: this is a copy of a post initially posted on Patreon and Tipeee.

Splash of GIMP 2.9.6 by Aryeom
Splash of GIMP 2.9.6 by Aryeom

Last month, we released the third development version of GIMP, version 2.9.6, as preparation of the next stable version, GIMP 2.10.

Same as for previous versions, ZeMarmot project was one of the major contributors with 274 commits (out of 1885 total for this release) by Jehan, 4 by Aryeom (some icons, a new paint dynamics “Pressure Size” very useful for flat coloring, and the splash image for this development version), and even for the first time, 3 commits by Lionel, a board member of LILA association. Hence about 15% of GIMP 2.9.6 was brought to you by ZeMarmot! 🙂

To get some more insight, you can have a look at the official announcement. And if you want to get the full and accurate list of Jehan’s contributions in particular, it is available on the source repository.

Brought to you in 2.9.6 by ZeMarmot

  • made libgimp as thread-safe, which basically means simplify plug-in developer work to have plug-ins using  several cores (now all desktop computers are multi-core);
  • display angles when drawing lines;
  • code review for WebP image support, as well as some improvements and fixes (and even a patch upstream on libwebp library);
  • capability to switch exclusive visibility of layers inside layer groups only with shift-click (feature requested and tested/used by Aryeom for a few months before adding it to GIMP);
  • contributing to the Darktable and RawTherapee  developers efforts for our new “raw” plug-in allowing importing  RAW files through these third-party software and into GIMP (GIMP project advocates for cooperation with other Free Software);
  • contribution to allow GIMP to follow GEGL multi-thread limit (once again to have a better usage of modern computer processors but now in GIMP core in particular);
  • various improvements of PDF support, in particular multi-page PDF export from layers (this is the part where Lionel from LILA made his first steps as a developer with Jehan’s help!);
  • code review and fixes for improved support of PCX images import and export;
  • capacity of plug-ins to be installed in their own subdirectory,  which should in the long run allow to get rid of the “DLL hell”, in  particular on Windows system, a very common issue where some plug-ins  embed libraries breaking other plug-ins;
  • change various defaults values to get to up-to-date standards (bigger default font size, fullHD as the new default image dimension, 300 PPI default resolution instead of 72…);
  • intelligent adaptation of physical dimension precision based on printing resolution to allow better precision in various parts of the  software (measure tool, status bar, etc.);
  • capacity to choose the icon size, allowing to adapt GIMP on smaller or bigger screen and in particular high density screens, etc.;
  • auto-detection of native resolution of your screen to choose  better default icon size (this default choice can still be changed, cf.  previous point; but at least you should get better defaults);
  • vector icons by default for the various size support;
  • welcome new code contributors by adding a vim coding style file and integrating contributed emacs and kate coding style files;
  • Flatpak package for GIMP;
  • and much more! Bug fixes and minor features by the dozens!

Flatpak for creators on Linux?

For the creators who use GIMP on a GNU/Linux operating system, you may have heard of Flatpak,  the generic application package system. Since we also exclusively use  Linux, it felt important that GIMP be available in a timely manner (with  distribution package systems, it is not unheard of to have to wait  months after actual release to get some new version!). We take the opportunity of the release of 2.9.6 to test a first public Flatpak package. Since  we don’t have a stable server, we made it available to our Patreon  and Tipeee contributors only for the time being, then will try and make it available for everyone very  soon!

For information, Windows already has a GIMP  2.9.6 installer available; and a MacOS package should hopefully soon get  uploaded (it will depends on this package maintainer who has some family priorities right now). These are not maintained by us. » See the download page! « 🙂

Thanks and “en route to GIMP 2.10”!

I hope you appreciate our contributions to GIMP! Know that these are all thanks to our contributors, be them Patreon or Tipeee, in previous crowdfundings or the ones who make direct donations.

It is not easy everyday because we seriously lack funding, and we have had some blues more than once. ;-(
Yet the many of you who never failed us and continue to support us give us some courage.
Thanks to you!

We will continue in order to bring you an awesome stable GIMP 2.10. 🙂

Have fun with GIMP!

GIMP Motion: part 2 — complex animations

This is the second video to present GIMP Motion, our plug-in to create animations of professional quality in GIMP. As previously written, the code is pretty much work-in-progress, has its share of bugs and issues, and I am regularly reviewing some of the concepts as we experiment them on ZeMarmot. You are still welcome to play with the code, available on GIMP official source code repository under the same Free Software license (GPL v3 and over). Hopefully it will be at some point, not too far away, released with GIMP itself when I will deem it stable and good enough. The more funding (see in the end of the article for our crowdfunding links) we get, the faster it will happen.

Whereas the previous video was introducing “simple animations”, which are mostly animations where each layer is used as a different finale frame, this second video shows you how the plug-in handles animations where every frame can be composited from any number of layers. For instance a single layer for the background used throughout the whole animation, and separate layers for a character, other layers for a second character, and layers for other effects or objects (for instance the snow tracks in the example in the end of the video).

It also shows how we can “play” with the camera, for instance with a full cut larger than the scene where you “pan” while following the characters. In the end, we should be able to animate any effect (GEGL operations) as well. This could be to blur the background or foreground, adding light effects (lens flares for instance), or just artistic effects, even motion graphics…
All this is still very much work-in-progress.

One of the most difficult part is to find how to get the smoother experience. Rendering dozens of frames, each of these composited from several high resolution images and complex mathematical effects, takes time; yet one does not want to freeze the GUI, and the animation preview needs to be as smooth as possible as well. These are topics I worked on and experimented a lot too because these are some of the most painful aspect of working with Blender where we constantly had to render pieces of animation to see the real thing (the preview is terribly slow and we never found the right settings even with a good graphics card, 32GB of memory, a good processor, and SSD hard drives).
One of the results of my work in GIMP core should be to make libgimp finally thread-safe (my patch is still holding for review, yet it works very well for us already as you can see if you check out our branch). So it should be a very good step for all plug-ins, not only for animation only.
This allowed me to work more easily with multi-threading in my plug-in and I am pretty happy of the result so far (though I still plan a lot more work).

Another big workfield is to have a GUI as easy to use, yet powerful, as possible. We have so many issues with other software where the powerful options are just so complicated to use that we end up using them badly. That’s obviously a very difficult part (which is why it is so bad in so many software; I was not saying that’s because they are badly done: the solution is just never as easy as one can think of at first) and hopefully we will get something not too bad in the end. Aryeom is constantly reminding me and complaining of the bugs and GUI or experience issues in my software, so I have no other choices than do my best. 😉

 

You’ll note also that we work on very short animations. We actually only draw a single cut at a time in a given XCF file.  From GIMP Motion, we will then export images and will work on cut/scene transitions and other forms of compositing in another software (usually Blender VSE, but we hear a lot more good of Kdenlive lately, so we may give it a shot again; actually these 2 introduction videos were made in Kdenlive as a test). Since 2 cuts are a totally different viewpoint (per definition), there is not much interest on drawing them in the same file anyway. The other reasons is that GIMP is not made to work with thousands of high-definition layers. Even though GEGL allows GIMP to work on images bigger than memory size in theory, this may not be the best idea in practice, in particular if you want fast renders (some people tried and were not too happy, so I tested for debugging sake: that’s definitely not day-to-day workable). As long as GIMP core is made to work on images, it could be argued that it is acceptable. Maybe if animations were to make it to core one day, we could start thinking about how to be smarter on memory usage.
On the other hand, cuts are usually just a few seconds long which makes a single cut data pretty reasonable in memory. Also note that working and drawing animation films one cut at a time is a pretty standard workflow and makes complete sense (this is of course a whole different deal with live-action or 3D animation; I am really discussing the pure drawn animation style here), so this is actually not that huge of a deal for the time being.

To conclude, maybe you are wondering a bit about the term “cel animation”. Someday I guess I should explain more what was cel animation, also often called simply “traditional animation” and how our workflow is inspired by it. For now, just check Wikipedia, and you’ll see already how animation cels really fit well the concept of “layers” in GIMP. 🙂

Have a fun viewing!

ZeMarmot team

Reminder: my Free Software coding can be supported in
USD on Patreon or in EUR on Tipeee. The more we get
funding, the faster we will be able to have animation
capabilities in GIMP, along with a lot of other nice
features I work on in the same time. :-)

Crossroad 0.7 released and future…

Crossroad 0.7

Last month, I released Crossroad 0.7. Do you remember Crossroad? My tool to cross-compile for Windows from a Linux platform, which I told about a year ago. Well there is not much to say: small release with bug fixes, minor improvements, update of the third-party pre-built Windows package repository (thanks OpenSUSE!), and so on.
Also there used to be a bug in pip, so any crossroad installed through pip was broken (I had a quick look at the time, and I think it was because it would break the install prefix). Fortunately this bug is apparently fixed so getting crossroad through pip is again the recommended installation:

pip3 install crossroad

The example from last year is still mostly valid so have a look if you want to see better what crossroad can do.

Future: Android, ARM, MIPS…

Though I historically started this project to build GIMP for Windows (when debugging for this platform), I had wanted to go further for some time now. Android cross-compilation, or even bare-metal builds come to mind.

10 days ago, I have started to work on the support for more cross-compilers. It’s not available in 0.7, but it should be in 0.8! I have successfully cross-built glib, babl, GEGL (and half a dozen other dependencies for these) for Android quite easily, in barely a few dozen of minutes (for Android ARM, x86, MIPS, etc.). Crossroad really makes cross-compilation just as easy as native compilation. 🙂

I will make a blog post with examples on cross-compiling Glib and GEGL for Android when Crossroad 0.8 will be out (not now since I may change a few things before the release). But really… if you already know how to use crossroad for building for Windows, then it’s exactly the same for Android (except there is no pre-built package installer; does anyone know if such a repository exist somewhere?). Just give a go to the git version if you can’t wait.

Going to mobile? Wait… is that… GIMP for tablets?

As always, I never develop just for the sake of it: I code because I want this for a longer term project. And I have grown interested in small devices, even though I resisted for a long time (I still barely use my phone other than for calling, and I don’t even call much). I don’t think small devices will just replace full-grown desktops and laptops any time soon (oppositely to what some would tell you), but they are definitely funny devices. So let’s have some fun in building Android (or other small devices) programs! 🙂

Now I know that a lot of people have asked for a GIMP on Android. Let me tell you I’m not sure it will happen just now. Not that it can’t. I don’t see why we could not build it on this platform (I will probably do a cross-build at some point, just for the sake of trying) but I believe it would be utter-crap as-is. GIMP has not been thought for small devices at all (I even have sometimes GUI size issues on my laptop display!) and therefore we should either heavily modify its GUI with conditional code for small touch devices,  or simply create a brand new GUI, which is probably a much better idea anyway, with such different usage paradigms. Maybe we could create a new Free Software adapted for smaller devices? If other devs are interested to make one as a continuation of the GIMP project, this could be interesting.
This said, having the main GIMP also more touch-aware would be a very good thing (for screen-tablet users), so who knows how things will evolve…

My first GEGL-powered Android “App”

Now I really wanted to have a go at this so I developed my first application to apply GEGL filters on images. This was also my first Android application, period, so I discovered a lot more than just using native libraries on Android.

I know, there are thousands of these “image effects” applications. Sorry! 😛
Really I just wanted a small and easy stuff based on GEGL, and that popped in my mind. For now, it’s called with the stupid name “Robogoat”, and you are free to look at the code under GPLv3. Current version only applies a Sepia effect (“gegl:sepia” operation) to test that the cross-compiled libgegl works well inside Android (it does!). When it will be ready, we should be able to select any effect from a wide range of GEGL operations. 🙂

Robogoat screenshot: applying a gegl:sepia effect in Android
Robogoat screenshot: applying a gegl:sepia effect in Android

If anyone wants to have fun with it, build it and even provide patches, you are more than welcome!


As a conclusion, I would like to remind that I am trying to make a living by developing Free Software, and for the time being, it doesn’t work that well. All my coding is supported through ZeMarmot project, which funds us for making an animation film while contributing to Free Software, in particular GIMP, but others too. For instance, while working on this Android stuff in the previous week, I improved Crossroad, contributed patches and a bug report to meson (and I may have discovered a bug in json-glib but I must check to be sure, before filling a new bug report) and to gradle, and also I have a few commits pending for babl (for Android support)…

So if you want to support me, you can fund my FLOSS development in US dollar (on Patreon) or in euro (on Tipeee). Thanks! 😀


P.S.: by the way, thanks to Free Electrons (a company for embedded Linux development, which contributes back quite a lot to the kernel; I like this, so here is for my minor help by citing them, even though I was not required to!) for having offered me a training in Android system development, a year ago. This is not the reason I first got interested into hand-held devices (rather the opposite, I went there because I had the interest), nor has it been that much help to what I did above, but that sure showed me how easy it indeed was and gave me a preview of the world of embedded Linux.

Wilber week 2017: our report

Wilber Week 2017: the hacking place
ZeMarmot reached Bacelona airport!
ZeMarmot reached Barcelona airport!

Last week, the core GIMP team has been meeting for Wilber Week, a week-long meeting to work on GIMP 2.10 release and discuss the future of GIMP.  The meeting place was an Art Residency in the countryside, ~50km from Barcelona, Spain, with pretty much nothing but an internet access and a fire place for heating. Of course, both Aryeom and I were part of this hacking week. I personally think this has been a very exciting and productive time. Here is our personal report (it does not include the full result for everyone, only the part we have been a part of).

Software Hacking, by Jehan

GIMP on Flatpak

I’ve wanted to work on an official Flatpak build for at least 6 months, did some early tests already back in September, but could finally make the full time only this week. The build is feature-complete (this was not the case of the original nightly builds of GIMP, used as tests by Flatpak’s main developer, back when it was still called xdg-app; also these incomplete builds seem to have not been available anymore for a few months now), or nearly (since some features are still missing in Flatpak).

I’ll talk more on this later in a dedicated post, detailing what is there or not, and why, with feedback on the Flatpak project.
Bottom line: GIMP will have an official Flatpak, at least starting GIMP 2.10!

Heavy coding and arting going on at #WilberWeek
“Heavy coding and arting going on at #WilberWeek” (photo by Mitch, GIMP maintainer)

Working on the help system, Windows build, and more…

I’ve also worked in parallel on some other topics. For instance I’ve made a new Windows build of GIMP to test a few bugs (with my cross-build tool, crossroad, which I hadn’t used for a few months!), fixed a few bugs here and there, and also spent a good amount of time working on improving language detection for the help system (in particular some broken cases when you don’t have exactly the same interface language as the help you downloaded, since we don’t have documentations for as many languages as we have GUI translations). This part is mostly not merged in our code yet because unfinished. But it should be soon.
All in all, that was 26 commits in GIMP (and 1 minor commit in babl) last week, and a lot more things started.

Art hacking, by Aryeom

Aryeom, ZeMarmot director, contributed a lot of smiles (as always), art and design. Since Mitch forgot our usual “Wilber Flag”, she quickly scribbled one on a big sheet of paper (see in video).

Apart from playing with Wilber stamps, created by Antenne Springborn, Aryeom also spent many hours discussing t-shirt and patch designs with Simon Budig. Here is one of her nice attempts for a very classy outlined-Wilber design:

Outlined-Wilber design by Aryeom
Outlined-Wilber design by Aryeom

Funny story: she chose as a base a font called montserrat, without realizing that the region we were in at the time was called Montserrat as well. Total coincidence!

She has also been working on some missing icons in GIMP, for instance the Import/Export preferences icon.

And with time permitting, she scribbled various drawings on paper, because digital painting doesn’t mean you should forget analog techniques, right?

Social hacking: interviews and merchandise

Developer interviews

I have been wanting to bring a little more life to our communication ever since we got a new website for GIMP. We already produce more regular news. I wish we had even more. I also think we should even extend to community news. So if you’ve got cool events around the world involving GIMP, do not hesitate to tell us about them. We may be able to make it a gimp.org news when time permits.

Something else I wanted is showing the people behind GIMP: developers and contributors, but even the artists, designers and other creators making usage of GIMP as a tool in their daily creative process. I have talked about these interviews for a few months now, and Wilber Week was my first attempt to make them a reality. I interviewed Mitch, GIMP maintainer, Pippin, GEGL maintainer, Schumaml, GIMP administrator, Simon, a very early GIMP developer and Rishi, GNOME Photos maintainer and GEGL contributor.
All these interviews soon to be featured on gimp.org!

And that’s only a start! I am planning on interviewing even more contributors (developers and non-developers) and also artists. 🙂

Merchandising

We regularly have requests about t-shirts or other merchandising featuring Wilber/GIMP. So we sat down and discussed on what should be exactly GIMP’s official position on this topic. As you know, I, personally, am all for Libre Art, so this was my stance. And I am happy that we are currently willing to be quite liberal.

Yet we have a lot of values and that was our main concern: how nice is your design? Is your merchandising using good material? Is it produced with ecologically-conscious techniques? Do you give back to the community?… So many questions and this is why Simon Budig will work on a ruleset of what will be acceptable GIMP merchandising that we will “endorse”. Endorsement from the GIMP project will mean that we will feature your selling page link on gimp.org and also that you will be allowed to feature on your own page some “endorsed by GIMP” text or logo. I’ve been quite inspired by this system which Nina Paley uses for Sita Sings the Blues movie.

Well that’s the current status, but don’t take it as an official position and wait for an official news or page on gimp.org (as a general rule, nothing I write is in any way an official GIMP statement unless confirmed on the main website by text validated by peers).

Release hacking!

The one you’ve all been waiting for, so I kept it for the end, or close: what about GIMP 2.10 release? We finally decided that it is time to get 2.10 going. We still have a few things that we absolutely need to fix before the release, but the main decision is that we should stop being blocked by unfinished cool features.

We have got many very awesome features which are “nearly there”, but mostly untouched for years. Usually it means that it globally works but is either extremely slow (like the Seamless Clone or n-point deformation tools), or that it is much too instable (up to the crash), often also with unfinished GUI…
Well we will have to do a pass through our feature list and will simply disable whatever is deemed non-releasable. The code will still be here for anyone to fix, but we just can’t release half-finished unstable features. Sorry.
The good news is that it suddenly divides our blocker list by 10 or so! And that should make GIMP 2.10 coming along pretty soon.

But so what of all these cool features? Will we have to wait until GIMP 3 now? Not necessarily! We decided to relax the release rules, which come from a time where all free software released major versions with new features and minor versions with bug fixes only (some kind of semantic versioning applied to end software). So now, if any cool new feature comes along or if the currently deactivated features get finished, we are willing to make minor releases with them! Yes you read it well. This makes it much more exciting for developers since it means you won’t have to wait for years to see your changes in GIMP. But it also means that our contribution process gets much more robust to the unfinished-patch-dropping issue. Of course the libgimp API (used by plugins) still stays stable. Changes does not mean breaking stability!
This was also summed-up in an official gimp.org news recently.

I am so happy about this because I have been pushing for this change in our release process for years. Actually the first time I proposed this was in Libre Graphics Meeting 2014, Leipzig (as I explained in my report back then). I call it a rolling release, where we can release very regularly new stuff, even if just a little. This time though, the topic was brought up by Mitch himself.

People hacking

The conclusion of this week is that it was very nice. As Simon Budig put it in his interview: I mostly stay for the people. I think this is the same for us, and these kind of social events are the proof of it. The GIMP project is ­ — before all — made of people, and not just any people, even nice people! Such event is a good occasion for meeting physically, from time to time, and not just with pixels and bits exchanged through the internet.
We also spent a few hours visiting Barcelona, in particular Sagrada Familia, and doing a few hikes in Montserrat.

This slideshow requires JavaScript.

Awesome panorama shot showing several members of GIMP and GEGL (photo by Aryeom)
Panorama shot featuring several members of GIMP and GEGL (photo by Aryeom)

Financial hacking: ZeMarmot

As a conclusion, we remind you that ZeMarmot would be the way for me to work full-time on GIMP software development! We could do nearly as much every week if our project had the funding which allowed us to sustain ourselves while hacking Free Software. So if you wish to see GIMP be released faster with many cool features, don’t hesitate to click our Patreon links (for USD funding) or the Tipeee one (EUR funding).

See you soon!

Don’t be a stranger to GIMP, be GIMP…

I can try and do more coding, more code reviewing, revive designing discussions… that’s cool, yet never enough. GIMP needs more people, developers, designers, community people, writers for the website or the documentation, tutorial makers… everyone is welcome in my grand scheme!

Many of my actions lately have been towards gathering more people, so when I heard about the GNOME newcomers initiative during GUADEC, I thought that could be a good fit. Thus a few days ago, I had GIMP added in the list of newcomer-friendly GNOME projects, with me as the newcomers mentor. I’ll catch this occasion to remind you all the ways you can contribute to GIMP, and not necessarily as a developer.

Coding for GIMP

GIMP is not your random small project. It is a huge project, with too much code for any sane person to know it all. It is used by dozen of thousands of people, Linux users of course, but also on Windows, OSX, BSDs… A flagship for Free Software, some would say. So clearly coding for GIMP can be scary and exciting in the same time. It won’t be the same as contributing to most smaller programs. But we are lucky: GIMP has a very sane and good quality code. Now let’s be clear: we have a lot of crappy pieces of code here and there, some untouched for years, some we hate to touch but have to sometimes. That will happen with any project this size. But overall, I really enjoy the quality of the code and it makes coding in GIMP somewhat a lot more enjoyable than in some less-cared projects I had to hack on in my life. This is also thanks to the maintainer, Mitch, who will bore you with syntax, spaces, tabs, but also by his deep knowledge of GIMP architecture. And I love this.

On the other hand, it also means that getting your patch into GIMP can be a littler more complicated than in some other projects. I saw a lot of projects which would accept patches in any state as long as it does more or less what it says it does. But nope, not in GIMP. It has to work, of course, but it also has to follow strict code quality, syntax-wise, but also architecture-wise. Also if your code touches the public API or the GUI, be ready for some lengthy discussions. But this is all worth it. Whether you are looking for improving an already awesome software, adding lines to your resume, improving your knowledge or experience on programming, learning, you will get something meaningful out of it. GIMP is not your random project and you will have reasons to be proud to be part of it.

How to choose a first bug?

Interested already? Have a look at bugs that we think are a good fit for newcomers! Now don’t feel obligated to start there. If you use GIMP and are annoyed by specific bugs or issues, this may well be a much better entrance. Personally I never contributed to fix a random bug as first patch. Every single first patch I did for Free Software was for an issue I experienced. And that’s even more rewarding!

Oh and if you happen to be a Windows or OSX developer, you will have an even bigger collection of bugs to look into. We are even more needing developer on non-Linux platforms, and that means we have a lot more bugs there, but also most likely a good half of these are probably easy to handle even for new developers.

Finally crashes and bugs which output warnings are often pretty easy since you can usually directly investigate them in a debugger (gdb for instance), which is also a good tool to learn if you never used. Bugs related to a graphical element, especially with text, are a good fit for new developers too since you can easily grep texts to search through the code.

Infrastructure

Now there are whole other areas where you could contribute. These are unloved area and less visible, which is sad. And I wish to change this. One of these is infrastructure! GIMP, as many big projects, have a website, build and continuous integration servers, wikis, mailing lists… These are time-consuming and have few contributors.

So we definitely welcome administrators. Our continuous integration regularly encounters issue. Well as we speak, the build fails, not because of GIMP, instead because minimum requirements for our dev environment are not met. At times, we have had a failing continuous integration for months. The problem is easy: we need more contributors to share the workload. Currently Sam Gleske is our only server administrator but as a volunteer, he has only limited time. We want to step up to next level with new people to co-administrate the servers!

Writers

While we got a new website recently (thanks to Patrick David especially!), more frequent news (here I feel we have to cite Alexandre Prokoudine too), we’d still welcome new hands. That could be yours!

We need documentation for GIMP 2.10 coming release, but also real good quality tutorials under Free/Libre licenses. The state of our tutorials on gimp.org were pretty sad before the new website, to say the least. Well now that’s pretty empty.

Of course translations are also a constant need too. GIMP is not doing too bad here, but if that’s what you like, we could do even better! For this, you will want to contact directly the GNOME translation team for your target language.

Designers

And finally my pet project, I repeat this often, but I think a lot of GIMP workflow would benefit from some designer view. If you are a UX designer and interested, be welcome to the team too!

So here it is. All the things which you could do with us. Don’t be scared. Don’t be a stranger. Instead of being this awesome project you use, it could be your awesome project. Make GIMP! 🙂