This is Part 3 of a blog post series summarizing the Developer Center BoF. See also Part 1: The Developer Experience and Part 2: Possible Audiences.

When we talk about improving GNOME and the infrastructure around it, we often quickly skip right ahead to talking about solutions ("The developer center is missing feature X"). However, before we can jump ahead into an informed discussion about solutions, we need to agree what it is we want to solve, that is:

• What kind of challenges does our audiences face when they look for documentation currently?
• What kind of challenges do our community face when they want to contribute to our current documentation?
• What consequences do these challenges have for the developer experience?

Defining the challenges should be possible for us now since we have already defined the possible audiences and what we mean when we say our developer documentation.

Challenges

The following highlighted challenges are based on the list of challenges identified in the BoF and my own reflections:

1. The documentation is fragmented

The documentation we have currently lives in multiple places. While our C documentation currently lives in developer.gnome.org, our GNOME Newcomer Guide is hosted on wiki.gnome.org. The GJS API Reference lives in devdocs.io. The PyGObject Manual lives in readthedocs.net. Documentation fragmentation refers to the issue that developers have to end up going to different websites than developer.gnome.org and potentially end up finding unofficial documentation which might be outdated or misleading.

2. The documentation branding is inconsistent/out of date

Our developer center uses outdated visual looks which is inconsistent with our other infrastructure (wiki, website, etc.). Documentation hosted outside developer.gnome.org also use different branding and visual style which makes it hard to distinguish maintained, official documentation from unmaintained documentation.

3. It is unclear from the landing page what documentation the Developer Center contains.

The Developer Center hides its documentation behind four large categories on the home page. The category naming is ambiguous ("Guides" vs "Application development overview") and does not give you a proper overview of what our documentation constitutes of. The front page navigation categorizes content, instead of trying to create on-boarding paths for specific audiences and in worst case our audiences apply guesswork to find what they are looking for.

3. It is unclear what documentation is up to date.

Our documentation being as scattered as it is, makes it difficult to assess what of our documentation is good and actively maintained for our readers. By searching documentation on developer.gnome.org you can still find documentation for GTK+ 2 and many guides has not been updated for years and may therefore be deprecated.

4. Our audiences use many different programming languages.

Much of GNOME is written in C and has bindings to many languages which is both a blessing and a curse. Our developer center currently provides API references in C, and various tutorials in Python, Javascript, C++ and more. Supporting the many different programming languages grows the complexity of unifying the developer center and provide a good experience everywhere. However, those language bindings are maintained because there are people out there who use them and prefers them over other languages and this will probably not change. Some of these people have also spent many hours writing documentation for binding languages on external websites and made external API references hosted outside GNOME Developer Center. I think these people are important for us to reach out to, when we discuss this challenge.

5. Which programming language should I choose?

This is related to number 4. For certain audiences such as third party developers and newcomers, the large language support can lead to confusion. Ideally this could be purely up to preference, but in reality some language bindings are more developed, maintained , tested and documented than others.

We should keep in mind that while some of our possible audience confront this challenge, many others in our possible audience already have language preferences, which I think is why proposing solutions related to this issue in the past has presented heated debates.

6. No on-boarding path to Developer Center from GNOME.org

GNOME.org has paths for getting involved with GNOME and downloading our platform through distributions, but we have no on-boarding path for developers who wants to start developing apps using GNOME technology.

7. Maintenance of infrastructure & documentation

Currently, the Developer Center infrastructure and documentation suffers from low to non-existing maintenance. It's a sign we need to take serious. Do we need lower the barrier to contributing to the developer documentation? What can we do to make the infrastructure easier to maintain? The underlying issue here likely also ties into why we now see new GNOME documentation hosted on other websites by different maintainers powered by different underlying technologies. I think this challenge needs both thinking from a technical point of view (how we might support editing multi-language documentation and auto-generated documentation) and an organizational point of view (assigning maintainership, reviewing our docs, aligning visions).

Your Input

What do you think constitutes a major challenge for the Developer Center? I'll review the comments made to this blog post and have also started an issue on Gitlab you can comment on.

Follow the effort

This was the last part of my blog series on the Developer Center GUADEC BoF. On Thursday 26th July, 16:00 UTC we will have a developer center call and if you are interested you can see the agenda and sign up here. Here are a few links if you wish to follow the ongoing efforts closely:

• Watch the Developer Portal Repository.
• Find us in the #docs channel and subscribe to gnome-doc-list where we will send call invitations, meeting summaries and framadates.
• Sign up for the hackfest (currently draft) which will happen in February after FOSDEM 19.
• There is also the DeveloperPortal group on Telegram.

The next step for us will be to come up with short-term and long-term plans for the developer center and the call on Thursday will be the first step towards this. If there is interest, I will write a blog post summarizing our progress.

22 Jul 2018 4:19pm GMT

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!

21 Jul 2018 11:07pm GMT

After a longer than expected journey, I arrived in Almería in time for paella, beers, and catching up with friends on beaches of the lovely Mediterranean. Before I decided to come, I set some goals for the trip:

• meeting with LAS GNOME team
• sort out issues I've had with GNOME's build system(s) for applications
• get automated testing working with the Jasmine-GJS testing framework and identify an area lower in GNOME's stack where I can contribute
• attend some awesome talks and learn what my fellow GNOMErs have been up to lately

I met with Rosanna, Sri, and Louisa to strategize about talks for the upcoming LAS GNOME conference. The CfP and travel sponsorship applications are open (submit your talks now!) and the deadline is July 27th. We discussed the FOSS community in the US, and identified new potential audiences and areas to showcase. Keep an eye on the LAS GNOME Twitter account for updates on all the great stuff we have planned for the conference.

I was particularly interested in and disappointed by Michael Catanzaro's talk "Migrating from JHBuild to BuildStream". I appreciate all the time and effort the Release Team has put into maintaining and developing the build systems, so I'm including my experience here as an example, not as a criticism.
Over time I've gotten used to JHBuild and become adept at searching for and fixing its sometimes bizarre error messages. A few months ago, after running into some modules that failed on JHBuild, I read the announcement about GNOME's modulesets moving to BuildStream. I spent a couple days removing JHBuild and rebuilding everything in BuildStream. Except I ran out of disk space. So I removed as much as I could and started over. Except then PulseAudio wouldn't work. Luckily I'd occasionally run into the same errors caused by an unavailable PulseAudio daemon when I was using JHBuild. I tried restarting the daemon, etc, and looked for info on the subject. In the end it turned out that PulseAudio wasn't available within the sandbox, so I scrapped BuildStream and went back to JHBuild.
Going forward, I'm planning to move from JHBuild to using FlatPak, Builder, and GNOME's nightly runtime build. I'm happy that the community is providing solutions, and, while things are still in a confusing state, at least they are moving quickly in interesting and promising directions.

When I was working mostly with Python I got into the habit of using TDD. As is usual in startupland, we had a release every two weeks, and features were being sold before they were developed (maybe that part's not so normal). I love tests: they document the expected behavior of the code, they shorten the development cycle by integrating debugging and coding, and they catch it when you break something in code you think you haven't touched. You can just stick nice hook in your repo, and then you can't push till everything is working.
During my time on the Board I found that I had less time for development, and I really wanted automated testing so I wouldn't cut corners on testing and accidentally release broken code. The Sound Recorder is hastily written student code, and somewhat fragile. So I started writing tests with Dogtail and Behave, only to find that the framework had been deprecated. Hence my mission to get Jasmine GJS working.
Jasmine takes a very different approach to testing from Dogtail and Behave. Behave uses ATSPI to provide a context from the actual running application. Using that context you can manipulate the UI elements. Jasmine GJS provides a framework more adapted to API testing. I had a short discussion with Philip Chimento about how he is using mock objects, and got my tests working. I also got a chance to talk to Philip about some easy bugs in GJS. I've been using C++ at work, and I use Javascript to write application code for GNOME, so GJS seems like a great option.

Last but not least, I got to attend a bunch of great talks by my fellow GNOMErs! I particularly enjoyed Federico's talk on porting Librsvg to Rust (complete with awesome illustrations of fairies by his daughter), Christian Hergert and Corentin Noël's talk on Builder, and Benjamin Otte's talk on GTK+ and developing for GPUs. I'm looking forward to watching all the great talks I couldn't see during the conference!

21 Jul 2018 9:59pm GMT

Here's a little timeline of some fun we had with the GNOME master Flatpak runtime last week:

• Tuesday, July 10: a bad runtime build is published. Trying to start any application results in error while loading shared libraries: libdw.so.1: cannot open shared object file: No such file or directory. Problem is the library is present in org.gnome.Sdk instead of org.gnome.Platform, where it is required.
• Thursday, July 12: the bug is reported on WebKit Bugzilla (since it broke Epiphany Technology Preview)
• Saturday, July 14: having returned from GUADEC, I notice the bug report and bisect the issue to a particular runtime build. Mathieu Bridon fixes the issue in the freedesktop SDK and opens a merge request.
• Monday, July 16: Mathieu's fix is committed. We now have to wait until Tuesday for the next build.
• Tuesday, Wednesday, and Thursday: we deal with various runtime build failures. Each day, we get a new build log and try to fix whatever build failure is reported. Then, we wait until the next day and see what the next failure is. (I'm not aware of any way to build the runtime locally. No doubt it's possible somehow, but there are no instructions for doing so.)
• Friday, July 20: we wait. The build has succeeded and the log indicates the build has been published, but it's not yet available via flatpak update
• Saturday, July 21: the successful build is now available. The problem is fixed.

As far as I know, it was not possible to run any nightly applications during this two week period, except developer applications like Builder that depend on org.gnome.Sdk instead of the normal org.gnome.Platform. If you used Epiphany Technology Preview and wanted a functioning web browser, you had to run arcane commands to revert to the last good runtime version.

This multi-week response time is fairly typical for us. We need to improve our workflow somehow. It would be nice to be able to immediately revert to the last good build once a problem has been identified, for instance.

Meanwhile, even when the runtime is working fine, some apps have been broken for months without anyone noticing or caring. Perhaps it's time for a rethink on how we handle nightly apps. It seems likely that only a few apps, like Builder and Epiphany, are actually being regularly used. The release team has some hazy future plans to take over responsibility for the nightly apps (but we have to take over the runtimes first, since those are more important), and we'll need to somehow avoid these issues when we do so. Having some form of notifications for failed builds would be a good first step.

P.S. To avoid any possible misunderstandings: the client-side Flatpak technology itself very good. It's only the server-side infrastructure that is problematic here. Clearly we have a lot to fix, but it won't require any changes in Flatpak.

21 Jul 2018 2:22pm GMT

At this year's GUADEC in Almería we had a team of volunteers recording the talks in the second room. This was organized very last minute as initially the University were going to do this, but thanks to various efforts (thanks in particular to Adrien Plazas and Bin Li) we managed to record nearly all the talks. There were some issues with sound on both the Friday and Saturday, which Britt Yazel has done his best to overcome using science, and we are now ready to edit and upload the 19 talks that took place in the 2nd room.

To bring you the videos from last year we had a team of 5 volunteers from the local team who spent our whole weekend in the Codethink offices. (Although none of us had much prior video editing experience so the morning of the first day was largely spent trying out different video editors to see which had the features we needed and could run without crashing too often… and the afternoon was mostly figuring out how transitions worked in Kdenlive).

This year, we don't have such a resource and so we are looking to distribute the editing. If you can, please get involved so we can share the videos as soon as possible!

The list of videos and a step-by-step guide on how to edit them is available at https://wiki.gnome.org/GUADEC/2018/Video. The guide is written for people who have never done video editing before and recommends that you use Kdenlive; if you're already familiar with a different tool then of course feel free to use that instead and just use the process as a guideline. The first video is already up, so you can also use this as a guide to follow.

If you want to know more, get in touch on the GUADEC mailing list, or the #guadec IRC channel.

20 Jul 2018 5:22pm GMT

• Mail; built metrics with Tor. Booked travel to the ownCloud conference too.
• Interested by Bradley arguing for reduced restrictions on speech in codes of conduct: an encouraging direction of travel. Personally, I think protecting speech, academic freedom, and more is well worth the cost of hearing some unpleasant opinions. Having said that - one of the things that dismays me about FLOSS conferences are the tedious, low-level and lazy attacks on Trump voters and their mental capacity (I have no vote in any US election). I really dislike political polarization as a modern-day US export: the idea that by painting your opponent as completely evil you galvanize your support base is not new, but getting worse. Carefully re-reading some various recent polarizing views from some emminent lawyers, it seems that it is possible to be deeply concerned about the US's direction of travel and the role of the judiciary without being unhinged. I can believe such concern might move some to the point of drastic action - such as voting for the only plausible short-term protection from some perceived long-term evil - without actually having a pro-incoherence approach themselves. I can also imagine economic concerns, perhaps unfairly conflated with immigration being a key issue - under-addressed by the mainstream (as arguably in the Brexit vote). It would be good to hear some more balanced criticism of the lamentable failures of the alternatives in both parties too - as well as in the electorate (or the media) for following their long term trend of being more interested in politics & news as entertainment, rather than policy & information.
• ESC meeting; posted minutes, dinner, TDF Advisory Board call.

19 Jul 2018 5:21pm GMT

Flatpak allows sandboxed apps to interact with the rest of the system via portals. Portals are simply D-Bus services that are designed to be safe to expose to untrusted apps.

Principles

There are several principles that have guided the design of the existing portals.

Keep the user in control

To achieve this, most portals will show a dialog to let the user accept or deny the applications' request. This is not a hard rule - in some cases, a dialog is just not practical.

Avoid yes/no questions

Direct questions about permissions tend to be dismissed without much thought, since they get in the way of the task at hand. Therefore, portals avoid this kind of question whenever possible and instead just let the user get on with the task.

For example, when an app is requesting to open a file on the host, we just present the user with a fille chooser. By selecting a file, the user implicitly grants the application access to the file. Or he can cancel the file selection and implicitly deny the applications' request.

Don't be annoying

Nothing is worse than having to answer the same question over and over. Portals make use of a database to record previous decisions and avoid asking repeatedly for the same thing.

Practice

The database used by portals is called the permission store. The permission store is organized in tables, with a table for each portal that needs one. It has a D-Bus api, but it is more convenient to explore it using the recently added flatpak commands:

flatpak permission-list
flatpak permission-list devices
flatpak permission-list desktop-used-apps video/webm

The first command will list all permissions in all tables, the second will show the content of the "devices" table, and the last one will show just the row for video/webm in the "desktop-used-apps" table.

There are also commands that deal with permissions on a per-application basis.

flatpak permission-show org.gnome.Epiphany
flatpak permission-reset org.gnome.Epiphany

The first command will show all the permissions that apply to the application, the second will remove all permissions for the application.

And more…

The most important table in the permission store is the "documents" table, where the documents portal stores information about host files that have been exported for applications. The documents portal makes the exported files available via a fuse filesystem at

/run/user/1000/doc

A useful subdirectory here is by-app, where the exported files are visible on a per-application bases (when setting up a sandbox, flatpak makes only this part of the document store available inside the sandbox).

It is instructive to browse this filesystem, but flatpak also has a dedicated set of commands for exploring the contents of the documents portal.

flatpak document-list
flatpak document-list org.gnome.Epiphany

The first command lists all exported files, the second shows only the files that are exported for an individual application.

flatpak document-info $HOME/example.pdf

This command shows information about a file that is exported in the document portal, such as which applications have access to it, and what they are allowed to do.

Lastly, there are document-export and document-unexport commands that allow to add or remove files from the document portal.

Summary

If you want to explore how portals work, or just need to double-check which files an app has access to, flatpak has tools that let you do so conveniently.

19 Jul 2018 5:06pm GMT

It's been ten days since I came back from GUADEC 2018, and I've finally caught up enough to find the time to write about it. As ever, it was a pleasure to see familiar faces from around the community, put some new faces to familiar names, and learn some entirely new names and faces! Some talk highlights:

• In "Patterns of refactoring C to Rust", Federico Mena Quintero pulled off the difficult trick of giving a very source code-centric talk without losing the audience. (He said afterwards that the style he used is borrowed from a series of talks he referenced in his slides, but the excellent delivery was certainly a large part of why it worked.)
• Christian Hergert and Corentin Noël's talk on "What's happening in Builder?" left me feeling good about the future of cross-architecture and cross-device GNOME app development. Developing OS and platform components in a desktop-containerised world is not a fully-solved problem; between upcoming plans for Builder and Philip Chimento's Flapjack, I think we're getting there.
• I'm well-versed in Flatpak but know very little about Snap, so Robert Ancell's talk on "Snap Package support in GNOME" was enlightening. It's heartening that much of the user-facing infrastructure to solve problems common to Snap and Flatpak (such as GNOME Software and portals) is shared, and it was interesting to learn about some of the unique featues of Snap which make it attractive to ISVs.

I couldn't get to Almería until the Friday evening; I'm looking forward to checking out video recordings of some of the talks I missed. (Shout-out to the volunteers editing these videos!)

One of the best bits of any conference is the hallway track, and GUADEC did not disappoint. Fellow Endlesser Carlo Caione and I caught up with Javier Martinez Canillas from Red Hat to discuss some of the boot-loader questions shared between Endless OS and Silverblue, like the downstream Boot Loader Specification module for GRUB, and how to upgrade GRUB itself-which lives outside the atomic world of OSTree-in as robust and crash-proof a manner as is feasible.

On the bus to the campus on Sunday, I had an interesting discussion with Robert Ancell about acquiring domain expertise too late in a project to fix the design decisions made earlier on (which has happened to me a fair few times). While working on LightDM, he avoided this trap by building a thorough integration test suite early on; this allowed him to refactor with confidence as he discovered murky corners of display management. As I understand it (sorry if I've misremembered from the noisy bus ride!), he wrote a library which essentially shims every syscall. This made it easier to mock and exercise all the complicated interactions the display manager has with many different parts of the OS via many IPC mechanisms. I always regret it when I procrastinate on test coverage; I'll keep this discussion in mind as extra ammunition to do the right thing.

My travel to and from Almería was kindly sponsored by the GNOME Foundation. Thank you!

19 Jul 2018 2:36pm GMT

That's my seventh edition of GUADEC (and counting) and I just can't get enough!

This year's edition was once again a blast. The best opportunity to put faces into the names we interact daily throughout the communication channels of our community, and to meet new folk.

Once again a volunteer, this year a chaired the sessions in the auditorium during the first day, organized one of the newcomers activities, and the football game. Don't forget to check out the conference photos.

Lots of work got done, as you must have read from other posts in Planet GNOME. It was no different for Boxes. Our annual Birds of a Feather session was more of a whole afternoon chat under the shadow in front of the university cafeteria. We managed to count with the presence of very experienced members of our community to give us some valuable insights on how we can sanely introduce new features and optimize the existing ones.

We discussed the challenges and possibilities of the OVF support, enabling us to Import and Export virtualization appliances allowing users to easily share their VMs with each other, and perform migrations and backups. That is work that has already started and will be partially shipped in 3.30, and later complemented in the next cycle.

There we often heard of feature requests for enhancements we already landed. Therefore justifying my recent work in the new machine assistant to make the "Download an OS" page, and remote connections more discoverable. Expect more work in this area, making it easier for users to find and benefit from features we already have, such as: bridged network, file sharing, clipboard integration, notifications passthrough, multiple brokers, etc…

Another relevant topic fairly discussed during our meeting was the integration of Boxes into the Purism mobile development workflow as a simulator in which they could easily run their Flatpak bundles built with GNOME Builder. Alberto Fanjul participated in the discussions describing their requirements and suggesting features. Expect some interesting work in this regard for our next development cycle.

A few more specific topics were discussed related to changes under the hood related to speeding up things and making some processes more fail-proof.

Boxes among other apps got stickers!

GUADEC was also an opportunity for me to meet our Google Summer of Code mentee Adi Manglik, and chat about his challenges adding Power consumption capabilities to GNOME Usage and of being a newcomer in our community.

I would like to thank the GUADEC organizers for hosting an amazing conference. The Social Events were great, from the sangria at the beach party to the guided tour to Alcazaba ending with a delightful party at the sunset with incredible flamenco dances, it is all fantastic with friends.

Last but not least, I'd like to thank my employer Red Hat for sponsoring my trip! I hope to see you all again very soon!

19 Jul 2018 9:07am GMT

This year I attended my second GUADEC in beautiful Almería, Spain. As with the last one I had the opportunity to meet many new people from the extended GNOME community which is always great and I can't recommend it enough for anybody involved in the project.

Downstreams

The first thing that surprised me this year was the representation of GNOME downstreams including Canonical, Purism, System76 and Elementary. Each one brought to the table different perspectives on what the GNOME platform means for them and I had some great conversations with all of them. Shout out to the Elementary folks in particular who have been doing great work and I hope the two communities can grow together and improve each other (they also made a nice blog post).

Flatpak

Flatpak continues to have a lot of healthy discussions at these events. @matthiasclasen made a post summarizing the BoF so check that out for the discussions of the soon landing 1.0 release.

So lets start with the Freedesktop 18.07 (date based versioning now!) runtime which is in a much better place than 1.6 and will be solving lots of problems such as multi-arch support and just long term maintainability. I was really pleased to see all of the investment in BuildStream and the runtime from CodeThink which is really needed in the long term.

Flathub is in a good place thanks to all of the hard work of @jgarciao, @ramcq, and @nedrichards but there is still a ton of work to be done improving the infrastructure to streamline everything.

Lastly there was a Flatpak workshop in which I helped @cassidyjames package a simple Elementary app which I hope leads to more in the future. They certainly have a unique perspective on why Flatpak would be valuable compared to most app developers since they already have their own store and single supported distro they are more focused on the self-hosting and sandboxing parts rather than the cross-distribution aspects.

GTK

There was of course a lot of discussion about GTK this year; Again @matthiasclasen already made an in-depth post about the main BoF so I won't duplicate that here. There were other discussions though including a BoF about theming which will hopefully lead to a common base between Adwaita, Pop, and Communitheme moving forward. Purism also had a talk about using GTK for mobile interfaces which looked promising.

@nirbheek had a talk about GTK on Windows which has always been an important topic of mine having been building it in various ways for years now. I'm very excited that everything is slowly falling into place with the Meson transition of most projects, plans for binary dependencies on Windows, GTLS backend using SChannel, etc.

Future

One of my favorite things to come from this GUADEC was the excitement the Foundation had about expanding. Rosanna Yuen had a talk about how they are going to use the recent influx of funds from the anonymous donor by hiring a few employees and how they are going to focus on getting more funding in the future. This can only be good for the Foundation and the Project as lack of resources is a constant problem in all FOSS projects.

Another constant problem within GNOME is the documentation so I went to the developer experience BoF. It was mostly focused on setting the stage for what needs to be done which is a lot but I plan on staying involved with this initiative as it continues to evolve and Bastian has made a multi part blog series over the topic with meetings scheduled in the future so hopefully something great comes of this.

In the end I'm looking forward to the future of GNOME and I will be going to LAS in Denver this September so I hope to see everybody again along with some new faces.

19 Jul 2018 4:00am GMT

• Mail; admin, monthly all-hands call. A little hackery, some estimation, worked late on proposals.

18 Jul 2018 9:00pm GMT

Karlovy Vary - Ankali.

GUADEC in Almería was a great opportunity to catch up with some technologies in the GNOME world, hang out with lovely folks again, and spend time at the beach.

• Wrote stock answers / canned replies for GNOME Gitlab (to be used in your local browser as a user script) as stock answers are not supported yet by default in Gitlab.
• Realized that I can still directly push into Git repositories hosted in GNOME Gitlab. Also created my first proper merge request after forking in Gitlab. Workflows.
• I finally removed GNOME Evolution's ancient Quick Reference PDF, after Raniere Silva had moved the list of keyboard shortcuts into the Evolution user help (thanks for your patch!). Also fixed a good bunch of Evolution user documentation issues.
• One last time: Presented Bugzilla activity statistics at the AGM.
• Closed about 2500 open tickets of unmaintained products in GNOME Bugzilla.
• Had a GNOME Release Team meeting.
• Realized that Sébastien and I enjoy the idea of better development statistics. As volunteer time is too precious to reinvent wheels:
  • A shell script to pull and/or update all Git repositories in GNOME Gitlab
  • Print the date of the last non-translation commit (translation commits are located in the /po subdirectory) in a git repository: git log -n 1 --pretty=format:"%cd" --date=short -- !(po)
  • Print the number of non-translation commits since a certain date: git log --after=2010-07-10 --pretty=oneline -- !(po) | wc -l
  • Print the number of different non-translation committers since a certain date: git log --after=2010-07-10 --committer='' --pretty=format:"%ae" -- !(po) | sort -u | wc -l
  • Print the email addresses of people listed as maintainers in a project's DOAP file: xmlstarlet sel -N doap="http://usefulinc.com/ns/doap#" -N rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" -t -v "/doap:Project/doap:maintainer/foaf:Person/foaf:mbox/@rdf:resource" somename.doap
• Carlos was kind enough to tell me about Quick actions in Gitlab plus keyboard shortcuts, to save me some triage time. Plus to answer all my Bugzilla to Gitlab related questions (or concerns?) as I had not followed closely for the last months…
• …which also made me curious how far GNOME has already migrated from Bugzilla to Gitlab (kudos to Carlos, Andrea, Alberto, the Gitlab crew, and everybody else involved in planning and performing this move!) so I decided to gather some numbers yesterday:
  • 265 products in GNOME Bugzilla have zero open tickets, do not accept filing new tickets in Bugzilla anymore, and do not exist in Gitlab either. Ancient stuff. Nothing to do.
  • 103 products in GNOME Bugzilla have zero open tickets and do not accept filing new tickets in Bugzilla anymore as you get redirected to Gitlab. Either already fully migrated or small projects. Nothing to do.
  • Doxygen has 1908 open tickets in Bugzilla, does not accept new tickets in Bugzilla, and does not exist in Gitlab.
  • 17 products in GNOME Bugzilla have zero open tickets and do accept filing new tickets in Bugzilla. That's projects to still set up in Gitlab, I'd say.
  • 197 products in GNOME Bugzilla have 23426 open tickets in total and do not accept filing new tickets in Bugzilla anymore as you get redirected to Gitlab. That's tickets to either mass-migrate from or close with an explanation in Bugzilla, I'd say.
  • 51 products in GNOME Bugzilla have 5791 open tickets in total and still accept filing new tickets in Bugzilla. That's products and tickets to set up in Gitlab and either mass-migrate from or close with an explanation in Bugzilla, I'd say.

18 Jul 2018 8:21pm GMT

Battery life
I was very happy to see that Fedora Workstation 28 in the Phoronix benchmark got the best power consumption on a Dell XPS 13. Improving battery life has been a priority for us and Hans de Goede has been doing some incredible work so far. And best of all; more is to come :). So if you want great battery life with Linux on your laptop then be sure to be running Fedora on your laptop! On that note and to state the obvious, be aware that Fedora Workstation adoption rates are actually a major metric for us to decide where to put our efforts, so if we see good growth in Fedora due to people enjoying the improved battery life it enables us to keep investing in improving battery life, if we don't see the growth we will need to conclude people don't care that much and more our investment elsewhere.

Desktop remoting under Wayland
The team is also making great strides with desktop remoting under Wayland. In Fedora Workstation 29 we will have the VNC based GNOME Shell integrated desktop sharing working under Wayland thanks to the work done by Jonas Ådahl. It relies on PipeWire to share you Wayland session over VNC.
On a similar note Jan Grulich, Tomas Popela and Eike Rathke has been working on enabling Wayland desktop sharing through Firefox and Chromium. They are reporting good progress and actually did a video call between Firefox and Chromium last week, sharing their desktops with each other. This is enables by providing a PipeWire backend for both Firefox and Chromium. They are now working on cleaning up their patches and prepare them for submission upstream. We are also looking at providing a patched Firefox in Fedora Workstation 28 supporting this.

PipeWire
Wim Taymans talked about and demonstrated the latest improvements to PipeWire during GUADEC last week. He now got a libpulse.so drop in replacement that allows applications like Totem and Rhythmbox to play audio through PipeWire using the PulseAudio GStreamer plugin as Pipewire now provides a libpulse.so drop in replacement. Wim also keeps improving the Jack support in PipeWire by testing Jack applications one by one and fixing corner cases as he discovers them or they are reported by the Linux pro-audio community. We also ended up ordering Wim a Sony HT-Z9F soundbar for testing as we want to ensure PipeWire has great support for passthrough, be that SPDIF, HDMI or Bluetooth. The HT-Z9F also supports LDAC audio which is a new high quality audio format for Bluetooth and we want PipeWire to have full support for it.
To accelerate Pipewire development and adoption for audio we also decied to try to organize a PipeWire and Linux Audio hackfest this fall, with the goal of mapping our remaining issues and to try to bring the wider linux audio community together. So I am very happy that Arun Raghavan of PulseAudio fame agreed to be one of the co-organizer of this hackfest. Anyone interested in attending the PipeWire 2018 hackfest either add yourself to the attendee list or contact me (contact information can be found through the hackfest page) and I be happy to add you. The primary goal is to have developers from the PulseAudio and JACK communities attend alongside Wim Taymans and Bastien Nocera so we can make sure we got everything we need on the development roadmap and try to ensure we all pull in the same direction.

GNOME Builder
Christian Hergert did an update during GUADEC this year on GNOME Builder. As usual a ton of interesting stuff happening including new support for developing towards embedded devices like the upcoming Purism phone. Christian in his talk mentioned how Builder is probably the worlds first 'Container Native IDE' where it both is being developed with being packaged as a Flatpak in mind, but also developed with the aim of creating Flatpaks as its primary output. So a lot of effort is being put into both making sure it works well being inside a container itself, but also got all the bells and whistles for creating containers from your code. Another worthwhile point to mention is that Builder is also one of the best IDEs for doing Rust development in general!

Game mode in Fedora
Feral Interactive, one of the leading Linux game companies, released a tool they call gamemode for Linux not long ago. Since we want gamers to be first class citizens in Fedora Workstation we ended up going back and forth internally a bit about what to do about it, basically discussing if there was another way to resolve the problem even more seamlessly than gamemode. In the end we concluded that while the ideal solution would be to have the default CPU governor be able to deal with games better, we also realized that the technical challenge games posed to the CPU governor, by having a very uneven workload, is hard to resolve automatically and not something we have the resources currently to take a deep dive into. So in the end we decided that just packaging gamemode was the most reasonable way forward. So the package is lined up for the next batch update in Fedora 28 so you should soon be able to install it and for Fedora Workstation 29 we are looking at including it as part of the default install.

18 Jul 2018 3:35pm GMT

Ever since the dawn of times, we've been crafting pixel perfect icons, specifically adhering to the target resolution. As we moved on, we've kept with the times and added these highly detailed high resolution and 3D modelled app icons that WebOS and MacOS X introduced.

As many moons have passed since GNOME 3, it's fair to stop and reconsider the aesthetic choices we made. We don't actually present app icons at small resolutions anymore. Pixel perfection sounds like a great slogan, but maybe this is another area that dillutes our focus. Asking app authors to craft pixel precise variants that nobody actually sees? Complex size lookup infrastructure that prominent applications like Blender fail to utilize properly?

Blender: Linux is the only platform with botched app icon.

For the platform to become viable, we need to cater to app developers. Just like Flatpak aims to make it easy to distribute apps, and does it in a completely decetralized manner, we should emphasize with the app developers to design and maintain their own identity.

Having clear and simple guidelines for other major platforms and then seeing our super complicated ones, with destructive mechanisms of theming in place, makes me really question why we have anyone actually targeting GNOME.

The irony of the previous blog post is not lost on me, as I've been seduced by the shading and detail of these highres artworks. But every day it's more obvious that we need to do a dramatic redesign of the app icon style. Perhaps allowing to programatically generate the unstable/nightlies style. Allow a faster turnaround for keeping the style contemporary and in sync what other platforms are doing. Right now, the dated nature of our current guidelines shows.

Time to murder our darlings…

18 Jul 2018 12:55pm GMT

This is Part 2 of a blog post series summarizing the Developer Center BoF. See also Part 1: The Developer Experience.

Hi Again! As promised I will now cover our discussion of possible audiences at the GUADEC Developer Center BoF.

Possible Audiences

"Developers" can mean many things. There are several subclasses of developers we need to take into consideration so we can decide how to scope the developer center. Deciding a primary audience will become important later to take design decisions and align our vision. Note that I say "primary" - to create a good developer experience we still need to ensure a good story for other audiences we care about. In this list, one person may fit into several audiences and all of the audiences will need to be well defined (e.g. with a description):

• GNOME newcomers (interested in contribution)
• Experienced GNOME stack developers (fx library developers)
• Experienced GNOME app developers
• Third party app developers (unfamiliar with GNOME technology)
• Interns (think GSoC or Outreachy)
• Shell Extension developers
• GTK+/Shell Theme developers
• Distribution maintainers
• People who are new to programming
• Programmers from all over the world
• Programmers who prefer video tutorials
• User Interface Designers (?)

At this point we can start identifying some constraints which our users' behavior and goals depends on:

• What they wish to accomplish (an app, an extension, a design)
• Their familiarity with the GNOME stack.
• Learning preferences (text tutorials, video tutorials,..).
• Programming language preferences
• Spoken language preferences
• and possibly more..

We need to consider which of these we think is important in the short-term and in the long-term. Simultaneously, we need to consider the maintainability of the Developer Center and its content too. This is a list of possible audiences - eventually we should decide on short-term priorities.

Among the six attendees at the GUADEC BoF there was fairly wide interest in having the GNOME Developer Center cater to application developers and especially third party developers. I know that me and Carlos are also interested in having the developer center provide a good experience for newcomers, who share's their unfamiliarity with GNOME technology and terminology with third party developers. In general, I think catering to application developers is a good approach as more users of our technologies benefit our ecosystem.

What's Next

By knowing what our developer experience of (Part 1) and with the possible audiences in mind (Part 2) we can start consider what challenges our current experience encounters, which we ought to solve. I will cover this in my last part of this blog post series, Part 3: Challenges.

Your Input

If you have any additions to the lists above or comments, let us know! Comment on this blog post or on the related Gitlab issue.

17 Jul 2018 9:19pm GMT

Over the course of the past couple of months, I was able to achieve a promising progress in modernising Five or More, although I would have to say there is a fair share of aspects to tackle yet.

I opted for rewriting the code module by module, without combining C and Vala code. There was was an old attempt to port Five or More to Vala, but I chose not to use it due to the fact that the partial port was 4 years old and it definitely needed an update, which might have taken quite some time, and might have produced some nasty bugs. While doing so, I paid extra attention to keep things nicely separated: all of the currently ported modules separate the game logic from the drawing logic and the UI.

I also managed to port the app menu and the preferences window. However, due to the new design gudelines, which are currently only in the state of a proposal, the app menu might require future alterations.

App Menu access with functional callbacks

The app window is currently resizable and it sports a customisable coloured board. After each click, the next shapes contained inside the next pieces widget are being spawned inside the game board.

Changing the board colour from the Preferences menu

Changing the board size from the Preferences menu and resizing the window (for some reason there is a colour flick when recording the screen for this one)

Clicking inside the game board area

I am currently working on the pathfinding algorithm, which will basically allow the user to move a shape from cell A to cell B inside the game grid.

The short todo list includes adding the game over logic and implementing both the scores and high scores system, by using the libgnome-games-support. There are also some extra-features to be added, such as animations, sounds and gamepad-support, and providing a fresh looking UI.

17 Jul 2018 12:47pm GMT