Report of GUADEC 2016

Hi all!

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?! 🙂

IMG_20160812_144317

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 opens with a huge barbecue!
GUADEC picnic
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.

IMG_20160812_145043

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! 😉

IMG_20160813_163038

IMG_20160813_163834

IMG_20160813_163851

IMG_20160813_162921

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…

IMG_20160814_181727

So thank you GNOME for the event and also for sponsoring our travel there! 🙂

ZeMarmot sponsored by GNOME

Improving the export process in GIMP

While I have been working for days on the animation software for ZeMarmot, I wanted to “rest” my brain a little and came back to an old project of mine, which I should have implemented months ago.

So let’s get the troll out straight away: yes, this is about the split between save and export on GIMP. Now I was not there when the decision was taken, but I think it makes sense anyway. Saving is about “your work”, your process. XCF is — in such a view — not an image format, but a project format. It contains much more than the final visual image. Same as you would not save a “.mpeg“, “.avi” or “.mov” in blender, but a “.blend“, you don’t save a “.jpeg” or “.png” either, but a “.xcf” (another analogy for developers out there: “.blend” or “.xcf” can be compared to your source files — which is definitely what they are in a multimedia project — and the image or video formats as the compiled binary).

Yet I understand that some users have a hard time understanding this since there are nearly no difference in our GUI between saving and exporting.
save-export
What’s the difference, you’d ask? And you’d be right.

In the last 2 days, I refactored the whole GimpFileDialog code, which was completely mixing every concepts with hard-to-read if {} else {} statements inside a single class. GimpFileDialog became a generic parent class, containing only logics common to all file dialogs, and I added 3 specific children: GimpOpenDialog, GimpSaveDialog and GimpExportDialog.
This will allow us to do easily much more interesting graphical interfaces specific to each process.

As a proof of concept, I tested a “Scale at export” feature, which would allow to rescale images at export time, without touching the original. Who indeed never worked on some high resolution image, then needed to export it in lower resolution (to upload on some website, send through email or whatever…)? The current GUI would force to scale the original image, export it, then not forget to cancel the scale afterwards (if you forget, save and quit — for instance by habits — you are doomed: you just completely lost data and hours of high res work!).
Here for a UI test:
Save for Export in GIMP

Now before you tell anything: I know that the above screenshot does not look so nice, with a lot of wasted space on the right. I reused an existing widget (the same used in the “Scale Image” dialog, if you know GIMP well) and have not been trying to customize for this first version. The goal was mostly to test the new refactored code and we have some more thinking and discussion before actually adding these features (there are many more things that could be rethought to improve export, at deeper levels too).
The refactoring is now merged to master; the “Scale at export” isn’t yet though (feel free to test it on its git feature branch though, it’s functional).

Of course this is only the start of greater things. One may want to crop an image, change the color space (particularly if you were working in non sRGB), or even apply any GEGL operation before export (like “sharpen” after downscaling).
This should all be possible soon. Of course we’d have to work on the ideal UI to not clutter the export dialog. I will keep readers updated for when the next steps will occur.

I believe this is partially what some people would call a “Save for Web” feature, though I personally don’t like this naming since it is far too restrictive. You may want to change your exported image for far many more reasons that just “the web”.

Now I’ll be back to ZeMarmot (and I remind everyone who wants to support me to improve GIMP they can still support our Open Animation Film)!