mrxvt is a cool light-weight terminal emulator, not tied to a specific desktop environment and with minimal dependency. This was also one of my very first bigger contributions to Free Software. Well I had patches here and there before, but that’s one project where I stuck around longer and where I was quickly given commit rights. So it is dear to my heart. It was also my first big feature attempt since I started a branch to add UTF-8 support (actually any-encoding support), which is the normal way of things now but at the time, many software and distributions were still not working with UTF-8 as a default. Then I left for years-long wandering our planet on a motorcycle (as people who know me are aware) and because of this, drastically slowed down FLOSS contributions until a few years ago. Back as a contributor, mrxvt is not my main project anymore (you know which these are: GIMP and ZeMarmot!). I moved on.
Now I have to admit the awful truth: I don’t use mrxvt much anymore. My main reason is actually because I need dearly UTF-8 and even though I’d love to finish whatever I started on this topic years ago, I don’t have the opportunity to do this anymore. Whatever terminal I use now* is good for me.
Yet mrxvt is still used, and we have regularly people asking about its development. So this is just a small call, if not too late:
if anyone is interested into taking over mrxvt, you are welcome to do so!
I have recently moved the code from subversion (on Sourceforge) to git on gitlab. So consider this new repository as the new official upstream of mrxvt. But be it know that my goal here is not to take back active development. I just can’t make the time to it. I can only assure that I would maintain it with GI (historical maintainer who also has commit right on the new repo as well) and would review and merge any patch which makes sense. If any developer who previously had commit rights on our subversion repository asks me for, I can give you commit rights there too.
Last but not least: if anyone wants to take over, we will gladly give ownership. But please send a few patches first. We had a few people who wanted to become the upstream without even showing a piece of code. Well we want to give the baby, but making sure first we give it to someone who cares. So just make a few patches that we can review, and we’ll happily give over mrxvt.
* Full disclosure: my current terminal of choice is Guake. Well it has unfortunately its share of bugs, but I really love the “making it appear and disappear in a click”. Considering that the terminal emulator is undoubtly the software I use the most daily, making it a special one, with its own windowing (not lost in alt-tab hell) is a very good trick to me.
So this year was our first GUADEC, for both Aryeom (have a look at Aryeom’s report, in Korean) and I. GUADEC stands for “GNOME Users And Developers European Conference”, so as expected we met a lot of both users and developers of GNOME, the Desktop Environment we have been happily using lately (for a little more than a year now). It took place at the Karlsruhe Institute of Technology in Germany.
Apart from some people we knew from Libre Graphics Meeting events over the years, we met a lot of new faces, and that’s very cool. We have to spread ZeMarmot love, right?! 🙂
My first impression is the remarkable organization of GUADEC. They planned social events every day (barbecue, picnic with football, beer nights, dinners… even an ice cream truck at free price!), very well planned schedules, efficient sponsorship, workshops and hackfests, a cake for the 19th birthday… They know their geeks and we nearly never ran out of coffee (well, excepted during the hackfests ;-()!
GUADEC opens with a huge barbecue!GUADEC picnic
Of course, we were not here just for the beer, there were a lot of very cool talks. I was quite interested into Endless and their OS based on GNOME. It was interesting to see the design experiment around GNOME maps too. There were also a bunch of discussion relative to security, and definitely the project on everyone’s mouth was Flatpak. This is clearly a technology that a lot of people have been waiting for, and the center of many discussions.
But also the small feedback that we got on how the GNOME Foundation works was quite insightful. Obviously this is only a small piece of it, but being able to participate and view some of the decision process, discuss about the money that the foundation had been able to raise, how it should be used, about new events around GNOME (like LAS GNOME). This all felt like an exciting time and a cool community to be part of.
Another of my activities was trying to get designers interested into GIMP. For people who have followed my work a little, you know I have been really involved into getting GIMP a design revival (taking over the GUI wiki, creating an official GIMP GUI mailing list, trying to make other developers interested into this topic again and proposing some ideas here and there…), yet with very limited success so far (well I had some, but would really love if things could go forward at a better pace). I think GIMP is clearly a great software, both historically and technically. Historically because it is the root of several awesome technologies, like GTK+ (no GNOME without, right?) or lately GEGL, and because many people would call it a “flagship” for Free Software. But great technically as well: I am very amazed how good the code is. It has its zones of darkness (every software has, especially after more than 20 years of existence), because it is still well organized, clean, following clear coding standards with quality code. There is obviously a good technical maintainership. Now the GUI is less than perfect. Not because it is flawed, but because it follows here too 20-year-old design standards. Any software this age has this kind of problem, especially with design paradigms evolving faster and faster. Yet I believe a software that great deserves a chance to get a new face. So what’s the link to GUADEC? Well I have tried to approach various GNOME designers and getting them interested to GIMP again. If you are one of these designers I approached, hopefully I convinced you to give it a try. If I didn’t approach you, I may just not have known who you are, and do not hesitate to come to me. I am not saying that any complete huge redesign will happen overnight. But you definitely have open ears and we, at GIMP, are willing to discuss how to make a better user experience! We can start small.
Another reason for our presence was obviously to present our project: ZeMarmot. We were quite pleased to discover that some people knew about us. I was clearly going there thinking we would be like total strangers. But not only did some people recognize us, but we even had someone telling us his daughter was a huge fan. What? We got our first fan girl?
By the way, they had this badge machine, so while we were there, we printed and created our first hand-made badges of ZeMarmot. About 3 dozens of them. They are therefore quite exclusive so if you got some of them while being there, don’t throw them away!
Oh and by the way, that’s Creative Commons by-sa badges, like our movie! 😉
For people interested into our talk, here it is! You’ll see some quite exclusive contents with a few seconds of some cuts of the pilote. Enjoy!
And so here we are, ready to leave Germany. This was a very interesting event. We may come back next year, who knows? Only regret I have is that I was really hoping to participate to a workshop, but since our hotel was already booked, it was not made possible. Well next year maybe…
So thank you GNOME for the event and also for sponsoring our travel there! 🙂
So you may have heard the news: we recently released a new development version of GIMP, version 2.9.4 (as well as a bugfix release 2.8.18, but this is not as awesome).
Small edit: I realized that my blog post has been linked on many major news website. I didn’t expect this! Therefore I just want to make clear that whatever I wrote below is my view of GIMP future. It may not be shared by other developers who have their own priorities and this post has not be written with the other devs. In other word, anything here is not written as anything official from the GIMP project itself, but from me only, a single contributor to GIMP.
GIMP 2.9.4
I am not going to rewrite all of the official news, because you may as well read it on gimp.org. Anyway I co-wrote the news with the rest of the team and provided several screenshots. So reading there is also partly same as reading here. 😉
I’ll just illustrate with this cool picture of the live preview of operations (here a gaussian blur) directly on canvas, split for comparison, implemented by Mitch, our own benevolent dictator (or are we all his dictators?). The image on canvas is by Aryeom, ZeMarmot‘s director.
GIMP 2.9.4 screenshot. Canvas image by Aryeom Han (Creative Commons by-sa).
Pretty cool feature, uh?
GIMP & ZeMarmot project
As you can read on gimp.org, ZeMarmot is a contributor to GIMP through my own contributions (which amounts to about 14% of commits for this specific release. Commits number is not always the most perfect metrics but as good as any).
Painting
So what did we bring to the table? Well there are the stuff which we like most first: painting. So I developed symmetry painting last year. Here are some symmetrical doodles drawn by Aryeom in just a few seconds, thanks to the symmetry modes:
Symmetrical doodles by Aryeom (Creative Commons by-sa).
I also helped on the integration of the MyPaint brushes, and in particular contributed upstream on a whole build system rework which, as a side effect improved the codebases of libmypaint and MyPaint (quote from Mypaint’s blog post):
Development of MyPaint will continue of course; in fact making this split happen has improved a lot of things in the codebases of both projects ☺ Big thanks to @Jehan for making this all work so well!
Internationalization
Also the fact that Aryeom is Korean, that we both lived in several countries in Europe, Asia and Oceania, that we speak English, French, Japanese, Korean (well my Korean is lacking!), and that I love languages and am a grammar geek made us good targets to notice anything wrong with GIMP’s support of non Western languages. So I have fixed some bugs and even crashes related to Input Methods and made the text tool finally compliant with input method engines (it used to have an ugly overlay box, not integrated at all in the input box, and without any standard formating).
Writing Korean (left) or Japanese (right) in GIMP 2.9.4’s text tool.
Of course, I did several other fixes related to languages since I contribute to GIMP like each language translated in itself in the list of language in the preference, or bugs with GUI with right-to-left languages, like Arabic (did I say I was a language geek? I love all these differences and particularities).
Other than this, both Aryeom and I are trying to build a more diverse community by engaging FLOSS and GIMP enthusiasts in Japan, South Korea (some tutorial videos in Korean even) or other countries in their native languages. A hard and long job but we are trying. 🙂
Code review and code maintenance
Well I code a lot of other stuff, smaller features (like the email plugin in GIMP 2.9.4, using xdg-email, implemented a few weeks ago) and bug fixes since I like GIMP hard-rock solid and as stable as possible but that’s obviously less visible. I am also trying to step up more and more for code review and maintenance of small pieces of the software, since Mitch really needs the help (apparently the whip is not enough help! Go figure!). Well this is still work in progress and I wish I could make time to bring more cool code into GIMP, but it still allowed the action search (equivalent to the space-menu of Blender), which I think is one of the coolest feature of GIMP 2.9/2.10 and making menus so old school. This was originally contributed by Srihari, then I reviewed, rewrote and fixed parts of it to fit our high standards on code quality. Well I think that’s one of the features I am the most proud as a reviewer (instead of as the original author). This is also very rewarding to work with other coders, especially when talented and with interesting ideas.
Searching an operation in GIMP with the action search.
There are more code I reviewed and integrated, like lately the cool command line’s batch processing macro or even the whole revamping of the user interface (new themes and icons). Arguably this is less “useful”. Well it depends. I met some people who claimed it will change their life, while others would hate the new design direction (though note that old icons and theme are still available in preferences). But anyway this was an idea hanging around on mailing list for years, so I took on myself to attend to new contributors willing to help on the matter (Klaus Staedtler for the icons and Benoit Touchette for the themes). This is also an interesting adventure, I think.
New themes by Benoit Touchette and icons originally by Barbara Muraus and Jakub Steiner, heavily updated and completed by Klaus Staedtler.
In the end working on all these fronts is very cool but also exhausting. Hopefully the more time goes, the more I will be able to do! 🙂
Future of GIMP
GEGL everywhere?
I see a lot of good things happening around GIMP. And not just from me, but from all the awesome people in GIMP team and projects around. GEGL for one is a hell of a cool project and I think it could be the future of Free and Open Source image processing. I want to imagine a future where most big graphics program integrates GEGL, where Blender for instance would have GEGL as the new implementation of nodes, with image processing graphs which can be exchanged between programs, where darktable would share buffers with GIMP so that images can be edited in one program and updated in real time in the other, and so on.
Well of course the short/mid-term improvements will be non-destructive editing with live preview on high bit depth images, and that’s already awesomely cool right?
Painting again, better UI, export and much more…
Of course we want to go further for painting features and workflow improvement, but also the UI which really needs some reworking here and there (which is also why I created the gimp-gui mailing list, meant to discuss all sort of topics UI and UX related). That also includes improving support for graphics tablet and alike.
I also have a lot of ideas, some may come to be implemented in a form or another, or not (the export process for instance is still untouched for now). Even when this happens, it’s ok: contributing to Free Software is not just adding any random feature, that’s also about discussing, discovering others’ workflow, comparing, sometimes even compromising or realizing that our ideas are not always perfect. This is part of the process and actually a pretty good mental builder. In any case we will work hard for a better GIMP. 🙂
Among the many other features we are really keen on are the ability to select many layers at once (this is often a pain for Aryeom, since she usually works with many dozens of layers when animating), macros, improving the API to be able to customize the GUI (and not only adding menu items) and the behavior of GIMP, get more communication between GIMP and plugins and in general reacting to hooks, and much much more.
Now there are stuff which are also cool, like better HiDPI support but since we don’t own a HiDPI screen anyway, this is harder to test.
Also I like GIMP for being generic. While other programs choose to be specialized, which is a valid choice, we can notice most graphics programs end up with the same features in the end anyway. Indeed brushes and other painting features are actually very useful to photographers as well. On the other hand, painters regularly use filters and transformation tools originally thought for photographers. Designers use everything as well. So I think the approach of a program which aims to do everything well is quite acceptable too.
Well you see, we have a lot of plans about GIMP, that seems nearly impossible but that’s exciting. And of course, there are the plugins for animation that I am working on, on a good pace. I think I will be able to present the main GIMP plugin for animation quite soon on this website. Stay tuned! 🙂
Help us by helping ZeMarmot?
As often, I will conclude by promoting our permanent monthly funding of ZeMarmot. I know this is very annoying! We want to make a difference, something cool: a Libre animation film together with Free Software code. And trying to make this into more than just a hobby. Right now we are barely there.
I regularly talk about the more “artistic” side here, not often enough about the “technical” coding side. So I decided to use the opportunity of GIMP 2.9.4 release to make this small (non exhaustive) report of stuff I had been doing these last months and what are our goals on the software side (GIMP in particular). If you like what you read here about my contributions, then you like what ZeMarmot is doing, because this is all the same project. And therefore if ever you can afford it, we would welcome financial help so that we can continue software development as well as the production of the animation film.
TL;DR; if you don't care at all about how crossroad works,
and you just want to cross-build GIMP in a few commands,
see at the bottom of the article.
Over the years, I have written a tool to cross-compile software under a GNU/Linux OS for other targets: crossroad. Well to this day, the only supported targets are Windows 32/64-bit. I realized I never advertised this tool much which — even though it has been originally built to help me build and hack a specific project (GIMP) — ended up as a generic cross-compilation system for Linux.
“The crossroads” where Robert Johnson supposedly sold his soul to the Devil, by Joe Mazzola (CC by-sa 2.0)
So today, I will explain crossroad by giving a concrete example:
Cross-compiling GIMP on GNU/Linux for Windows system
The basics
The cool stuff about crossroad is that it allows to cross-build as easily as a native build. For instance f your build system were the autotools, you would run the famous triptych ./configure && make && make install, right? Well with crossroad, you only wrap the configure step but the rest is the same! cmake is also fully supported, even though my examples below won’t show it (check out the manual for more).
All what crossroad does is preparing you a suitable environment, with the right environment variables, but also wrappers to various tools (for instance, you get the x86_64-w64-mingw32-pkg-config tool inside a crossroad environment, which is no more than a wrapper to detect packages inside the cross-built prefix only).
Enough chit-chat. Let’s install crossroad!
pip3 install crossroad
Running crossroad the first time
I will now go through a full cross-build of GIMP for Windows 64-bit, from a brand new crossroad install. It may be a little long and boring, but I want to show you a full process. So you can just run:
$ crossroad --list-targets crossroad, version 0.6 Available targets:
Uninstalled targets: w32 Windows 32-bit w64 Windows 64-bit
See details about any target with `crossroad --help <TARGET>`.
Ok so at this point, you may have no cross-compilation compiler installed. Let’s see what I need for Windows 64-bit.
$ crossroad --help w64 w64: Setups a cross-compilation environment for Microsoft Windows operating systems (64-bit).
Not available. Some requirements are missing: - x86_64-w64-mingw32-gcc [package "gcc-mingw-w64-x86-64"] (missing) - x86_64-w64-mingw32-ld [package "binutils-mingw-w64-x86-64"] (missing)
The package name was actually based off a Mint or a Mageia, I think. If you use Fedora for instance, you will want to install mingw64-gcc and mingw64-binutils. Just adapt to your case.
Let’s check the output of crossroad again:
$ crossroad --help w64 w64: Setups a cross-compilation environment for Microsoft Windows operating systems (64-bit).
Installed language list: - C Uninstalled language list: - Ada Common package name providing the feature: gnat-mingw-w64-x86-64 - C++ Common package name providing the feature: g++-mingw-w64-x86-64 - OCaml Common package name providing the feature: mingw-ocaml - Objective C Common package name providing the feature: gobjc++-mingw-w64-x86-64 - fortran Common package name providing the feature: gfortran-mingw-w64-x86-64
We could stop here, but I actually know some programs make use of the C++ compiler, so let’s also install `mingw64-gcc-c++`. And now we are good to go!
I create a Windows 64-bit cross-build environment, that I will call “gimp-build”:
$ crossroad w64 gimp-build Creating project "gimp-build" for target w64... You are now at the crossroads... Your environment has been set to cross-compile the project 'gimp-build' on Windows 64-bit (w64). Use `crossroad help` to list available commands and `man crossroad` to get a full documentation of crossroad capabilities. To exit this cross-compilation environment, simply `exit` the current shell session.
Dependencies
babl
Now let’s cross-build babl! Very easy one to start with because it does not have any dependencies:
$ cd /path/to/src/of/babl/ $ crossroad configure && make && make install
Done! You’ll notice that you don’t even need to specify a prefix. crossroad is taking care of it.
GExiv2
$ cd /path/to/src/of/gexiv2 $ crossroad configure
The configure ends up with a pretty clear error:
checking for GLIB... no configure: error: GLib is required. Please install it.
Well basically you have to install glib. And then you think: the hell is starting! Do I have to build every dependency by hand? Fortunately no! crossroad relies on the OpenSUSE cross platform builds and can automatically download many dependencies for you. The reason I don’t do it for for all dependencies (babl, GEGL, libmypaint and GExiv2 in this tutorial) is when packages are either too old or non available. Install glib with:
$ crossroad install glib2-devel
That’s all! Neat right? Well you also have to install Exiv2 (trying to run the configure again, you’d see another error. I spare you the wasted time). You can run a separate command, or could have installed them both at the same time:
$ crossroad install glib2-devel libexiv2-devel
Try again:
$ crossroad configure
In the configuration summary, you’ll see that introspection and python bindings won’t be built-in. But since they are not needed for GIMP, we don’t care.
$ make && make install
And now GExiv2 has been cross-built too!
gegl
Now for gegl:
$ cd /path/to/src/of/gegl $ crossroad configure
Once again, you’ll get a few dependency errors. I spare you the try and fail process. Here are all the other mandatory libs to install:
Well there are actually more dependencies you could install or build yourself, but I don’t think they are really needed for GIMP. I’ll just leave it there. Now I build:
$ make
But then… a build error (I’ll admit: I left a dependency error on purpose!)!
In file included from /usr/include/SDL/SDL_main.h:26:0, from /usr/include/SDL/SDL.h:30, from /home/jehan/dev/src/gegl/operations/external/sdl-display.c:35: /usr/include/SDL/SDL_stdinc.h:74:20: fatal error: iconv.h: No such file or directory compilation terminated. Makefile:1277: recipe for target 'sdl_display_la-sdl-display.lo' failed make[4]: *** [sdl_display_la-sdl-display.lo] Error 1 make[4]: Leaving directory '/home/jehan/dev/crossbuild/w64/gegl/operations/external'[…]
Well that’s a good example to debug. Look well at the paths… /usr/include/[…], they are definitely for the native platform! So something is wrong.
Also I don’t even remember having installed SDL through crossroad anyway. Well if you were to check out the config.log, you would understand why the configure script found it:
configure:22069: checking for sdl-config configure:22087: found /usr/bin/sdl-config configure:22100: result: /usr/bin/sdl-config
Sometimes, some projects would use their own *-config script instead of relying on pkg-config (SDL seems to also have a pkg-config file, not sure why we’d prefer usind sdl-config, but well…). And while pkg-config allows to really separate the build and target environments, I can’t remove the current $PATH because a lot of native tools are needed in a cross-compilation. All this to say: you may encounter issues with software distributing custom *-config script. Be warned!
Anyway let’s install SDL, don’t forget to re-run configure (otherwise the native lib will still be used), then build again.
$ crossroad install libSDL-devel && crossroad configure && make && make install
Easy said, easy done.
libmypaint
Only a single dependency (json-c), then classical configure, make, make install:
$ crossroad install libjson-c2 libjson-c-devel && crossroad configure && make && make install
GIMP
And now for the main course! Once again, I spare you some of the search of dependencies. Here for mandatory deps:
I’ll skip completely Python dependencies. This is the only major part of GIMP I’m still having issues with in my cross-builds so I will run configure with --disable-python.
Note 1: libwmf-devel has the same issue as SDL, thus the configure script would see it installed if you have it on your main system because of the libwmf-config in your $PATH.
Note 2: you can use crossroad search to discover package names. Even better, sometimes you know a file name that configure is looking for (after a dependency error, check out the configure.ac file or the config.log file for this info). For instance, I can’t find a libghostcript but I see that GIMP‘s configure is looking for the file ghostscript/iapi.h to detect ghostscript:
$ crossroad search --search-files iapi.h "iapi.h" not found in any package name. The following packages have files matching the search "iapi.h": - headers - libgs-devel
Then using crossroad list-files libgs-devel, I can confirm that this is the right package (crossroad info libgs-devel also confirms this is the package for Ghostscript development files).
Back to building GIMP:
$ crossroad configure --disable-python
$ make && make install
Note that I don’t built some options in, like the Ascii Art, the help browser, or OpenEXR because I could not find prebuilt dependencies, but it should not be hard for you to build the dependencies yourself as we did for babl/GEGL/…
Running under Windows!
And now you can for instance make a zip to put on a Windows, like this:
This will just compress the whole target build, where GIMP for Windows is under bin/gimp-2.9.exe. Now this is *not* an installer or whatever finale. The target directory is full of files useful for building, yet completely useless for the finale installation. crossroad is *not* meant for making installers… to this day at least (saying that I would not be against if anyone wanted to implement something of the sort. Why not?! Send me a patch!).
Since I usually run Windows in a Virtualbox VM, rather than zipping a whole archive, I would simply share a directory and symlink the target directory like this:
$ cd /path/to/dir/shared/with/windows/vm/
$ crossroad --symlink w64 gimp
Note: in your Windows environment, you must update the PATH environment variable to add your build’s bin/ directory otherwise Windows won’t find your various built DLLs. You’ll find information on how to do so everywhere in the web.
I use crossroad as a developer, to test and sometimes patch directly GIMP for Windows, without ever getting out of my Linux OS. Well I still test under a Windows VM, which runs in Linux. But I develop and compile in my GNU/Linux shell.
Hopefully this tool can be useful to other people willing to test their program under Windows while hacking on GNU/Linux.
About having a good build system
If you followed good programming practice, and use a full-featured build system such as autotools and cmake, chances are that you can cross-build your program with barely any fix to the code. This is for instance what happened when I ported GExiv2 to autotools after we started using it in GIMP. GExiv2 maintainer would say in the blog post:
This in turn allows gexiv2 to build on Windows, something we’d not targeted at all when we began development but is obviously a hard requirement for GIMP.
Just having a good build system turn their Linux-only library into a multi-platform one. Pretty cool, no? And now libmypaint got the same fate, I autotooled it making it just so easy to cross-compile!
But if you have hand-made makefiles (like GExiv2 did), a scons build (like libmypaint did), or other build systems which don’t have a proper support for cross-building, this won’t be as easy. Think twice when you set up your software. The tool you use for builds is definitely not something to take lightly!
The one-step crossbuild script
This was all for you to see how crossroad is working. If you are only interested into building GIMP specifically, I compiled my whole tutorial below into a single build script that you are welcome to copy paste and run with crossroad like this:
crossroad install glib2-devel libexiv2-devel libjson-glib json-glib-devel \
libjpeg8-devel libpng-devel cairo-devel libtiff-devel librsvg-2-2 \
librsvg-devel pango-devel libwebp5 libwebp-devel libjasper-devel \
gdk-pixbuf-devel libSDL-devel libjson-c2 libjson-c-devel atk-devel \
gtk2-devel libbz2-1 libbz2-devel liblzma-devel liblcms2-2 \
liblcms2-devel libgs8 libgs-devel libmng1 libmng-devel \
libpoppler-glib8 libpoppler-glib-devel poppler-data \
xpm-nox-devel headers iso-codes-devel libwmf-devel headers
git clone git://git.gnome.org/babl
cd babl && crossroad configure && make && make install && cd ..
git clone git://git.gnome.org/gegl
cd gegl && crossroad configure && make && make install && cd ..
git clone git://git.gnome.org/gexiv2
cd gexiv2 && crossroad configure && make && make install && cd ..
git clone https://github.com/mypaint/libmypaint.git
cd libmypaint && crossroad configure && make && make install && cd ..
git clone git://git.gnome.org/gimp
cd gimp && crossroad configure --disable-python && make && make install
If you copy these into a file, say build-gimp.sh, you can run it at once with:
$ crossroad w64 gimp-build --run build-gimp.sh -n
I hope you enjoyed this tutorial on how to build GIMP with crossroad!
Note: if you like what I do, consider sponsoring our
animation film (CC by-sa), made with GIMP: ZeMarmot!
We fund it with Patreon (USD) and Tipeee (EUR).
