Planet GNOME

We’ve just released Mallard 1.1. Let’s take a look at what’s new. All of these features are already supported in tools like Yelp and Pintail.

This is part 3 in a 3-part series. Read part 1 and part 2.

Keywords

MEP-0014: Informational keywords element

One of the most visible additions in Mallard 1.1 is the introduction of the keywords element. If you look through a lot of real-world documents, you’ll find some that stuff synonyms into the desc element just to match things that users search for. This is not ideal.

In Mallard 1.1, we’ve introduced the keywords element to aid search systems built into tools like Yelp and Pintail. We decided to keep the element simple, using just a comma-separated list of terms instead of any nested keyword elements.

External info links

MEP-0007: External Info Links

Mallard features a number of types of automatic links, like seealso links. These links tend to automatically link in both directions, hence why we call them automatic links. The exact way they automatically link back depends on the link type. They all use informational link elements with an xref attribute, and the link text for these links is taken from informational elements like title and desc of the target node.

Since automatic links use the xref attribute, they were only able to link to pages within the same document, not to anything on the web. This makes some sense. After all, we can’t very well make random web pages automatically link back to our page. But sometimes you really do just want to have a seealso link to an external web page, even if it can’t automatically link back.

In Mallard 1.1, you can use the href attribute on informational links. Exactly how this works depends on the link type, but in general for things like seealso links, the link will appear in the list with your internal links. Because we can’t reliably fetch external resources for the link text every time we build a document, the informational link element can now have a title and desc element to specify the title and desc of the target.

Inline highlights

MEP-0009: Inline Highlight Element

Another highly visible change is the new hi element. This element can be used to highlight text that you’ve added or changed when progressively building up code examples. You can see it in action in the Mallard Ten Minute Tour.

In fact, we’ve been using this element (in the experimental namespace) in the Ten Minute Tour and other places since before Mallard 1.0 was even released. It was (I think) the first thing we added to the experimental namespace, and certainly the longest element in continual use without being in an actual spec. I wasn’t sure back then if we really wanted to add it, because it was unlike any inline element in any other semantic format. Years and years of usage have proven it’s worth having.

You can also use the ins and del style hints when including a diff in a Mallard page. These will do what you expect: green background, and red background with a strikethrough, respectively. Also, the yelp-xsl stylesheets let you use any of red, orange, yellow, green, blue, or purple as style hints to set the background color. Have fun.

Linkable sequences

Mallard features ubiquitous linking, meaning that any of the three linking attribute can be used on any inline element, so you don’t have to use two separate element to make a function name be both code and a link. Well, almost any inline element. In Mallard 1.0, you couldn’t put linking attributes on the guiseq and keyseq elements. I have completely forgotten whatever reason I might have had for doing that, and multiple people have since convinced me that was a mistake. Mallard 1.1 fixes this. You can now do ubiquitous linking on guiseq and keyseq.

Speaking of guiseq and keyseq, we’re considering creating a shorthand syntax for them so you can easily write simple GUI paths and key sequences without nested gui and key elements. Comment on the issue to let us know your thoughts.

And more

That’s it for part 3 of 3. If you haven’t already, read part 1 and part 2. For more information, you can read the Mallard 1.1 changes, the Mallard 1.1 enhancement proposals, and the 1.1 milestone issues.

Want to get involved? Take a look at our 1.2 milestone issues. Or check out the Documentation issue label and help us write tutorials. Keep in touch on the Mallard mailing list.

Before deep diving into the more extensive architectural changes that I’ve been working on GNOME Shell and Mutter, let’s take a moment to highlight the latest changes to GNOME Settings.

Being the (co)maintainer of Settings for a full year now, the development pace has been great so far. I would go as far as to say that the project is healthy and sustainable now. The shared maintainership model that we adopted allows us to decrease the review time, and yet make sure that every single contribution is reviewed by at least one maintainer.

Looking at the numbers, we managed to review 110 merge requests targeting 3.32 (and more if we consider the ones targeting 3.30 as well!). That is almost one merge request reviewed and merged every single day. Considering that this is mostly composed of volunteer work, I am comfortable to say that we found a very efficient maintainership model.

Without further ado, let’s see what happened during this cycle.

New Panels Applications

Mockups for controlling application settings were around and being discussed for some time now, but it eventually came the day where they were to be implemented. And thanks to the fantastic work by Matthias Clasen, we now have a new Applications panel:

The new Applications panel showing information and settings of a Flatpak-based application.

Flatpak-based applications naturally have more system integration points. There are ongoing ideas being discussed about which other integration points should be, but nothing settled so far.

Non-Flatpak applications don’t have as many controllable integration points.

There are more immediate improvements that will land before GNOME 3.32 release, but it’s a great addition already.

Sound

Robert Ancell has been working on the Sound panel redesign for some time now, and it’s close to landing. This is how it looks like so far:

Redesigned Sound panel with a vertical layout and better organization of the options.

Thanks to the awesome work of Outreachy intern Clarissa Borges, we have user testing results of this new layout. And they look pretty damn good! Overall, the testing clearly shows how much of an improvement the redesigned panel is.

Under the Hood Display

The Display panel is one of the hardest ones to deal with. Mostly because the almost entirety of the UI is programatically done. This was incredibly annoying, since it is somewhat hard to replace bits of the code with template widget without accidentally changing a lot of code.

Thanks to Benjamin Berg, however, this is not a problem anymore: the Display panel now uses modern best practices and is composed of smaller widgets. A new monitor scale widget is also on the way, although it potentially can be postponed to GNOME 3.34.

Responsive Panels

Purism is a great upstream player in GNOME, and so far demonstrated deep understanding on how upstream communitites work. Naturally, I had the chance to review and eventually land some fantastic working making GNOME Settings responsive:

Responsive GNOME Settings. More to Come

Thanks to the hard work of these and many other awesome contributors, GNOME Settings is improving the way users can control their systems. But these are not the only improvements that will be part of 3.32, and of course, there is much more being targeted to 3.34!

Replace libtool, turn full GNU Make? Every once in a while I start pondering ways to get rid of the slowness and overwhelming complexity of the autotools machinery, in particular autoconf and libtool. GNU Make has been a great companion for 20 years, and automake helps with some of the complexity in…

We’ve just released Mallard 1.1. Let’s take a look at what’s new. All of these features are already supported in tools like Yelp and Pintail.

This is part 2 in a 3-part series. Read part 1.

Table header cells

MEP-0012: Table Header Cells

Mallard mostly follows the HTML table model, with some simplifications of how things are styled. One element that was notably absent from Mallard tables, however, was the th element. The th element allows you to mark a cell as being a header for a row or column, even if it’s not in a thead element (as row headers wouldn’t be).

This was a pretty obvious and easy addition. I was so confident Mallard 1.1 would get a th element that I added a Ducktype shorthand for it well before Mallard 1.1 was released.

Custom roles for links

MEP-0003: The role Attribute on the links Element

This one’s pretty exciting, though a bit advanced. In Mallard, links can have roles which affect things like link text. These work with the multiple informational titles you can provide for a page or section. So, for example, if your language needs to do declensions for different parts of speech, you could write your links like this:

<link role="subject" xref="useful"/> is really useful. For useful info, check out <link role="object" xref="useful"/>.

Then in useful.page, you would have something like this:

<info> <title type="link" role="subject">Subject Title</title> <title type="link" role="object">Object Title</title> </info> <title>Normal Title</title>

Mallard will pick up the right title. More often, however, you don’t write your links inline, but instead you do automatic linking with informational links and possibly the links element. What happens then?

In Mallard 1.0, different types of automatic links have implicit roles. So the topic links on a guide page will automatically use the "topic" role to select link text from titles, for example. There are implicit roles for topic, guide, seealso, and series links.

So far, so good. But what if you want to use different titles for link text when coming from different guide pages with different topic link styles? This is where the new Mallard 1.1 feature comes in. In Mallard 1.1, you can add a role attribute to a links element to set the primary role to use for all the links it generates. The implicit role for that links type will still be used as a secondary role.

<links type="topic" role="fancyrole"/> Boring schema changes

In Mallard 1.0, sections were required to have id. There were a couple of reasons I made that decision, but in the end it turned out to annoy more people than it helped. So in Mallard 1.1, section IDs are optional.

We also made a perfectly boring schema change to make it easier for the Cache Files schema to extend the Mallard schema. (There’s also a new Cache Files 1.1 release.) Although RELAX NG is a mostly great schema language for extensible schema design, it does take some effort to design schemas that can be extended. Mallard got a lot of things right, but sometimes we find something to improve.

And more

That’s it for part 2. If you haven’t already, go read part 1, and keep your eye out for part 3. For more information, you can read the Mallard 1.1 changes, the Mallard 1.1 enhancement proposals, and the 1.1 milestone issues.

Want to get involved? Take a look at our 1.2 milestone issues. Or check out the Documentation issue label and help us write tutorials. Keep in touch on the Mallard mailing list.

i've just landed a big milestone for the Flicker Free Boot work I'm doing for Fedors 30. Starting with todays rawhide kernel build, version 5.0.0-0.rc4.git3.1, the fastboot option for the i915 Intel display driver is enabled by default on systems with a Skylake CPU/iGPU and newer, as well as on Valleyview and Cherryview (Bay- and Cherry-Trail) systems.

This means that the last modeset / flicker during boot of UEFI systems using the integrated Intel GPU for display output is now gone.

I have started reading recently about music theory and such, with the purpose to try to learn music (again). This lead me to look at music software, and what we have on Linux.

I found a tutorial by Ted Felix on Linux and MIDI

I quickly realised that trying these apps on my Dell XPS 13 was really an adventure, mostly because of HiDPI (the high DPI screen that the PS 13 has). Lot of the applications found on Fedora, by default, don't support high DPI and a thus quasi impossible to use out of the box. Some of it is fixable easily, some of it with a bit more effort and some, we need to try harder.

Almost all the apps I have tried used Qt. With Qt5 the fix is easy, albeit not necessarily user friendly. Just set the QT_AUTO_SCREEN_SCALE_FACTOR environment variable to 1 as specified in Qt HiDPI support documentation. There is also an API to set the attribute on the QCoreApplication object. There must be a good reason why this opt-in and not opt-out.

This is the case of Muse3 (aka muse sequence not to be confused with MuseScore which work out of the box, at east from Flathub), and Rosegarden.

LMMS and Hydrogen on the other hand are using Qt4 on Fedora 29. The good news? They both have been ported to Qt5, so it is just a matter of building these newer versions. After doing so, they still need the workaround described above.

This is where Flathub comes into play: make them available on Flathub, where we can set that environment variable for the runtime.

In the end, I have Hydrogen available on Flathub, the three others in queue for Flathub, and all have had patches submitted (with Muse3 and Rosegarden already merged upstream).

Now what other cool Free Software music oriented application exist?

It’s that time of the year again! Tomorrow I am flying to Brussels for what will be my 11th FOSDEM!

I will be carrying the Hack Computer (+ cool stickers) with me and I am happy to give a quick demo and talk about this new project or Endless with anyone interested.

Such a mean machine!

Looking forward to meeting everybody!

Some personal highlights:

Emoji OSK

The reworked OSK was featured a couple of cycles ago, but a notable thing that was still missing from the design reference was emoji input.

No more, sitting in a branch as of yet:

https://blogs.gnome.org/carlosg/files/2019/01/Screencast-from-21-01-19-155541.webm

This UI feeds from the same emoji list than GtkEmojiChooser, and applies the same categorization/grouping, all the additional variants to an emoji are available as a popover. There’s also a (less catchy) keypad UI in place, ultimately hooked to applications through the GtkInputPurpose.

I do expect this to be in place for 3.32 for the Wayland session.

X11 vs Wayland

Ever since the wayland work started on mutter, there’s been ideas and talks about how mutter “core” should become detached of X11 code. It has been a long and slow process, every design decision has been directed towards this goal, we leaped forward on 2017 GSOC, and eg. Georges sums up some of his own recent work in this area.

For me it started with a “Hey, I think we are not that far off” comment in #gnome-shell earlier this cycle. Famous last words. After rewriting several, many, seemingly unrelated subsystems, and shuffling things here and there, and there we are to a point where gnome-shell might run with --no-x11 set. A little push more and we will be able to launch mutter as a pure wayland compositor that just spawns Xwayland on demand.

What’s after that? It’s certainly an important milestone but by no means we are done here. Also, gnome-settings-daemon consists for the most part X11 clients, which spoils the fun by requiring Xwayland very early in a real session, guess what’s next!

At the moment about 80% of the patches have been merged. I cannot assure at this point will all be in place for 3.32, but 3.34 most surely. But here’s a small yet extreme proof of work:

https://blogs.gnome.org/carlosg/files/2019/01/Screencast-from-14-12-18-172645.webm

Performance

It’s been nice to see some of the performance improvements I did last cycle being finally merged. Some notable ones, like that one that stopped triggering full surface redraws on every surface invalidation. Also managed to get some blocking operations out of the main loop, which should fix many of the seemingly random stalls some people were seeing.

Those are already in 3.31.x, with many other nice fixes in this area from Georges, Daniel Van Vugt et al.

Fosdem

As a minor note, I will be attending Fosdem and the GTK+ Hackfest happening right after. Feel free to say hi or find Wally, whatever comes first.

The very first update in the series is about GNOME Shell and Mutter. I’ve been increasingly involved with the development of those two core components of GNOME, and recently this has been the focus of my development time.

Fortunately, Endless allows me to use part of my work time to improve it. Naturally, I prioritize my upstream work considering what will impact Endless OS the most. So far, that lead to a series of very nice improvements to Mutter and GNOME Shell.

GNOME Shell

Most of my work time dedicated to GNOME Shell was oriented to performance and cleanup. At Endless, we have a modified GNOME Shell that constantly needs to be rebased. Since I’m taking care of these rebases now, it makes sense for me to also make myself familiar with the vanilla GNOME Shell codebase.

ShellGenericContainer

I’ll start with the work that makes me the proudest: removing the Shell.GenericContainer class.

First, a bit of history.

There was a time when GJS, the JavaScript engine that GNOME Shell is based on, did not support subclassing GObjects and overriding virtual functions. We could only instantiate GObject-based classes, and subclass them, all thanks to GObject-Introspection, but not override their virtual functions. This made, for example, implementing ClutterContent in JavaScript impossible.

For that reason, GNOME Shell developers created ShellGenericContainer: an actor that sends signals for various virtual functions. Because GJS supports signals, that worked well.

There are a few problems with that approach though:

• Signals are slow, and should not be used on hot paths like layouting or rendering;
• Going in and out of JavaScript territory is expensive;
• It makes the JavaScript code slightly more complicated;

Thanks to the fantastic work by Jasper St. Pierre, GJS now supports overriding virtual functions. And that made Shell.GenericContainer obsolete. So I spent quite some time untangling it from GNOME Shell, and results were positive:

In general, running GNOME Shell without Shell.GenericContainer (blue line) led to more stable framerates compared to the current state (red line).

This is now merged and will be available with GNOME Shell 3.32, to be released on March 2019.

Improvements to the texture cache

After various investigations, another potential improvement that showed up was on StTextureCache. Textures (icons, image files, etc) are cached in GNOME Shell by StTextureCache, and that happened by keeping a ClutterTexture object alive.

That turned out to be a problem.

ClutterTexture is deprecated. Clutter has a new interface for drawing the contents of an actor: ClutterContent. It does not necessarily make the code faster, but it allows different actors to share a single ClutterContent without having to override ClutterActor.paint(). In other words, it is a nice and sane abstraction layer to control what an actor is drawing.

So I went ahead and wiped out ClutterTexture from StTextureCache. Then wiped it out entirely from GNOME Shell.

Unexpectedly, it made a small but noticeable difference! Icons are now slightly faster to load, but the most visible impact was in the startup animation.

Mutter

I did not know how fun and exciting compositors could be. It definitely is a new passion of mine, working on Mutter! So much has happened that it’ll be hard to summarize.

Goodbye, Autotools

During last year’s GUADEC, Jonas Ådahl worked on a Meson port of Mutter. After a series of reviews, and a few follow-up fixes, it reached almost complete feature parity with Autotools – the only exception being installed tests.

So I went ahead and added installed tests to the Meson build too.

And also removed Autotools.

Naturally, builds are much faster now. Saving us a few minutes per day.

Wayland vs X11

Another area that was interesting to work on was untangling X11-specific code from Wayland, and vice-versa. There are a handful of developers working on that already, and I had my fair share in better splitting X11 and Wayland code paths in Mutter.

Specifically, I worked on splitting X11-specific code from MetaWindowActor into subclasses. Mutter already handles different surfaces correctly; on X11 sessions, all surfaces are MetaSurfaceActorX11, and under Wayland, MetaSurfaceActorWayland.

MetaWindowActor has now the same split: Wayland windows have a MetaWindowActorWayland associated, while X11 windows have MetaWindowActorX11.

Interestingly, XWayland windows are X11 windows with a Wayland surface. You can check that using GNOME Shell’s Looking Glass:

Example of a Xwayland window; it has a MetaSurfaceActorWayland surface, and a MetaWindowActorX11 actor associated.

There’s a lot more happening in this front, but I’ll spare the words for now. You’ll hear more about it in the future (and not necessarily from me).

CPU-side picking

More recently, I’ve been experimenting with the Cogl journal and ironing out a few bugs that are preventing a completely CPU-side picking implementation.

Picking is the process to figure out which element is beneath the cursor. There are two big approaches: geometry-based, and color-based. On games, the latter is the usual approach: each object in the scene is drawn with a plain color, and the final image is read to find out the color beneath a point. Geometry-based picking is what browsers usually do, and it’s basically math around rectangles.

Clutter uses color-based picking, but has a nice feature around that: a journal that tracks drawing operations and, under some conditions, hits an optimized path and does geometry-based picking. This is interesting for Mutter and GNOME Shell because it avoids sending draw operations to the GPU unecessarily when picking, reducing resource usage.

Unfortunately, due to various bugs and implementation details, we do not hit this optimization, causing GPU commands to be issued when they could be avoided.

Figuring out these bugs is what I’ve been experimenting with lately.

 

 

There’s much more that happened, so I will probably do a part 2 of this article soon. But those are big points already, and the post is becoming lengthy.

Many of these experiments and investigations already landed, and will be available with GNOME 3.32. This is all valuable work that is partially sponsored by my employer, Endless, and I’m happy to keep working on it!

On GNOME we usually had no good way of using remote display devices like Chromecast, Miracast or AirPlay. VLC for example does support streaming to Chromecast, but the Miracast implementations were all not integrated well enough to be usable. Also, at least Miracast requires the use of the H264 or H265 codecs, which have been problematic due to licensing requirements.

I have been working on a gnome‑screencast application, which currently has working support for Miracast devices. It requires a current development version of NetworkManager, but should work out of the box otherwise. If you are on Fedora, you can try out gnome‑screencast by using my copr repository.

To stream to a Miracast (revision 1) device, a few things need to happen. First we need to establish a Wi‑Fi Direct connection. We also need to start an RTSP server that the sink can connect to. And finally, once the sink is connected, a GStreamer pipeline is used to fetch the screen content from mutter, encode it and send it to the Miracast sink.

For the encoding, gnome-screencast will make use of the OpenH264 and Frauenhofer FDK ACC codecs that are available on Fedora. If you have better encoders installed, then these may be used automatically.

When available, gnome‑screencast will make use of the Mutter Screencasting API which allows it to grab the screens content on Wayland. The API is still improving in mutter, and in the future it will be possible to add support to stream the cursor separately.

One major piece that was missing for Miracast devices is integrated support for Wi‑Fi Direct (a.k.a. Wi‑Fi P2P) in our platform. While this was supported in the lower parts of the stack (Kernel and wpa_supplicant), we were lacking the required bits in NetworkManager to enable the usage in GNOME. I worked on adding the required support and thanks to Thomas Haller this has now been merged into NetworkManager 1.16.

With all this in place, it is possible to implement proper support for screen-casting using Miracast in GNOME. The below video shows gnome-screencast in action streaming my laptop screen with the Blender short film “Caminandes 3: Llamigos“ playing.

If you have a Miracast compatible device, then please try out the copr repository. You can report issues on github. Also, feel free to comment here or write me a mail with your experiences.

It’s been a few months already since I (re)joined Igalia as part of its Chromium team and I couldn’t be happier about it: right since the very first day, I felt perfectly integrated as part of the team that I’d be part of and quickly started making my way through the -fully upstream- project that would keep me busy during the following months: the Chromium Servicification Project.

But what is this “Chromium servicification project“? Well, according to the Wiktionary the word “servicification” means, applied to computing, “the migration from monolithic legacy applications to service-based components and solutions”, which is exactly what this project is about: as described in the Chromium servicification project’s website, the whole purpose behind this idea is “to migrate the code base to a more modular, service-oriented architecture”, in order to “produce reusable and decoupled components while also reducing duplication”.

Doing so would not only make Chromium a more manageable project from a source code-related point of view and create better and more stable interfaces to embed chromium from different projects, but should also enable teams to experiment with new features by combining these services in different ways, as well as to ship different products based in Chromium without having to bundle the whole world just to provide a particular set of features. 

For instance, as Camille Lamy put it in the talk delivered (slides here) during the latest Web Engines Hackfest,  “it might be interesting long term that the user only downloads the bits of the app they need so, for instance, if you have a very low-end phone, support for VR is probably not very useful for you”. This is of course not the current status of things yet (right now everything is bundled into a big executable), but it’s still a good way to visualise where this idea of moving to a services-oriented architecture should take us in the long run.

With this in mind, the idea behind this project would be to work on the migration of the different parts of Chromium depending on those components that are being converted into services, which would be part of a “foundation” base layer providing the core services that any application, framework or runtime build on top of chromium would need.

As you can imagine, the whole idea of refactoring such an enormous code base like Chromium’s is daunting and a lot of work, especially considering that currently ongoing efforts can’t simply be stopped just to perform this migration, and that is where our focus is currently aimed at: we integrate with different teams from the Chromium project working on the migration of those components into services, and we make sure that the clients of their old APIs move away from them and use the new services’ APIs instead, while keeping everything running normally in the meantime.

At the beginning, we started working on the migration to the Network Service (which allows to run Chromium’s network stack even without a browser) and managed to get it shipped in Chromium Beta by early October already, which was a pretty big deal as far as I understand. In my particular case, that stage was a very short ride since such migration was nearly done by the time I joined Igalia, but still something worth mentioning due to the impact it had in the project, for extra context.

After that, our team started working on the migration of the Identity service, where the main idea is to encapsulate the functionality of accessing the user’s identities right through this service, so that one day this logic can be run outside of the browser process. One interesting bit about this migration is that this particular functionality (largely implemented inside the sign-in component) has historically been located quite high up in the stack, and yet it’s now being pushed all the way down into that “foundation” base layer, as a core service. That’s probably one of the factors contributing to making this migration quite complicated, but everyone involved is being very dedicated and has been very helpful so far, so I’m confident we’ll get there in a reasonable time frame.

If you’re curious enough, though, you can check this status report for the Identity service, where you can see the evolution of this particular migration, along with the impact our team had since we started working on this part, back on early October. There are more reports and more information in the mailing list for the Identity service, so feel free to check it out and/or subscribe there if you like.

One clarification is needed, tough: for now, the scope of this migrations is focused on using the public C++ APIs that such services expose (see //services/<service_name>/public/cpp), but in the long run the idea is that those services will also provide Mojo interfaces. That will enable using their functionality regardless of whether you’re running those services as part of the browser’s process, or inside their own & separate processes, which will then allow the flexibility that chromium will need to run smoothly and safely in different kind of environments, from the least constrained ones to others with a less favourable set of resources at their disposal.

And this is it for now, I think. I was really looking forward to writing a status update about what I’ve been up to in the past months and here it is, even though it’s not the shortest of all reports.

One last thing, though: as usual, I’m going to FOSDEM this year as well, along with a bunch of colleagues & friends from Igalia, so please feel free to drop me/us a line if you want to chat and/or hangout, either to talk about work-related matters or anything else really.

And, of course, I’d be also more than happy to talk about any of the open job positions at Igalia, should you consider applying. There are quite a few of them available at the moment for all kind of things (most of them available for remote work): from more technical roles such as graphics, compilers, multimedia, JavaScript engines, browsers (WebKit, Chromium, Web Platform) or systems administration (this one not available for remotes, though), to other less “hands-on” types of roles like developer advocate, sales engineer or project manager, so it’s possible there’s something interesting for you if you’re considering to join such an special company like this one.

See you in FOSDEM!

Here you can find the introduction, the update 1, the update 2 and the update 3.

Graphical recap

After 4 long posts talking about USB devices, lock screen and keyboards are you a bit lost? Are you trying to find an answer to the question: “What will happen when I plug a USB device?”

Don’t worry, I’m here to help you with an easy to follow flowchart.

GNOME Control Center, USBGuard version check

In our implementation we use functionality that are available only from USBGuard 0.7.5. In reality the last version of USBGuard is the 0.7.4, but the changes that we need are already in master. So to be more precise, we require a version newer than 0.7.4.

Because USBGuard will most likely be an optional dependency, how do we check if the running version is new enough? Given the fact that the new version of USBGuard has an additional get/set method for ImplicitPolicyTarget, I added a check to GNOME Control Center where I try to get this parameter. If it fails it means that the running version of USBGuard is too old.

The time has come. Merge Requests!

After a call with Georges Basile Stavracas Neto and Benjamin Berg we agreed that probably the best way forward was to create the required merge requests as early as possible. Even if we will probably aim for an inclusion in the GNOME 3.34 cycle, doing it now will facilitate the gathering of feedback for the actual implementation and, maybe even more importantly, feedback for our design choices.

So this morning I prepared the required merge requests.

gnome-settings-daemon tests

I wrote a couple of tests for the USB daemon. The first is about testing the configuration sync between gsettings and USBGuard. The second checks if the “allow everything” rule gets added correctly to the USBGuard configuration.

They work but the code is still ugly. So right now they are not included in the MR that I did. After a cleaning and another correctness check I’ll be able to do so.

Progress on the second part, the keyboard’s dangerous keys

Right now I added a keyboard protection entry in gsettings. I’m not 100% sure if this will be the best place where to store it, but is good enough for starting. And also, if necessary, it will be easy to change it later on.

I did a first implementation on Mutter and so far is it working as expected. When we receive a key input event we check if the protection is active. If it is we check if the pressed key is a dangerous one. If that’s also true we generate a sha256 hash starting from the device name, the vendor id, the product id and its serial number.

Then we will be able to match this hash against a whitelist/blacklist database.

I’m also working on presenting these information on control center. The first step is a tab similar to the thunderbolt one, where we have a general toggle to enable/disable the USB keyboard protection and then a list of known devices with their current permission.

I’ll try to not use too much time on this first implementation of control center because it will be more a proof of concept and a base to better understand how to store persistent devices information and how to pass them to mutter.

And the performance?

While I wrote the key handling on mutter I asked myself: “and the performance?”. I was really curios about it, so I added a timer around the key handling method in mutter and I timed how much my additional check affected the performance.

• Mutter stock: 1-2 usec to compute the pressed key.
• With my modification with keyboard security off: 1-2 usec. It’s just an extra if check.
• With keyboard security on: 1-2 usec. An extra if and a binary search against an int list of keys.
• Keyboard security on and you press a “dangerous” key: 7-12 usec. In this case we also need to compute the sha256 of the device.

For prospective, the best consumer monitors available right now have an input lag of 9-10ms, while an average monitor can take 30ms or more. This site has been used as a source.

Keeping in mind that 1 millisecond (ms) is 1000 microseconds (us), I’m pleased to see that even when we need to generate a sha256 hash the performance hit is negligible.

FOSDEM

This weekend I’ll attend the FOSDEM event. So if you want to talk a bit about this project I’ll be there.

On Sunday Tobias Muller and me will have a talk where we will present this project.

What to expect next and comments

Hopefully by the next project update we will have a working first implementation of “limit keyboard capabilities” with all the required pieces together.

Feedback is welcome!

Time flies, Flatpak 1.0 was released four months ago.  Today we released the next major version, Flatpak 1.2. Lets take a look at what’s new.

New User Experience

A lot of effort since 1.0 has gone into improving the commandline user experience. This includes everything from better progress reporting to search and completion.

I’ve already written a detailed post about this aspect of the Flatpak 1.2 work, so I not going to say much more about it here.

Life-cycle control

1.2 includes new commands which make it easier to manage running Flatpaks.

Like other containers, Flatpaks are just regular processes, so traditional tools like ps and kill can be used with them. But there is often a bit more to a Flatpak sandbox than just a single process – there’s a babysitter, and D-Bus proxies,  and it can be a little daunting to identify the right process to kill, in a process listing.

To make this easy and obvious, we’ve added two new commands, flatpak ps and flatpak kill. For now, flatpak ps just lists basic information, but it is the natural place to show e.g. resource consumption in the future.

This functionality is available to other Flatpak front ends as well, in the form of the FlatpakInstance API in libflatpak.

Logging

Installing software is serious business, and it is well worth keeping a record of changes over time.

Flatpak now logs changes to installations and installed apps in the systemd journal. We take advantage of the capabilities offered by the journal, and write structured logs that contain useful fields like the affected remote, the commit IDs, and so on.

A particularly nice feature of the journal is that it keeps track of the originator of changes for us, so even if Flatpaks system-helper service is modifying the system installation, we still record the user who initiated the change.

You can of course use journalctl to study these logs. We also added a flatpak history command, which may be a bit more convenient, since it offers filtering and display that is more tailored to the specfics of Flatpak.

In the ecosystem

Portals are an important part of the Flatpak approach, and we’ve made releases of the portals to go along with the new Flatpak.  The 1.2 release of the portals brings a new location portal, a new portal for toolkit settings, respecting desktop lockdown settings, and better validation of input in all portals.

Flatpak itself also got some changes that will improve sandboxing in the future. One noteworthy change is that Flatpak will now bind dconf defaults and locks into the sandbox.  This will become useful with the next GLib release, when GSettings will no longer be using the dconf backend, allowing us to close an all-to-common sandbox hole.

In a similar vein, Flatpak is now creating a fontconfig configuration snipplet that will be used by a future fontconfig release to map font directories to their caches.

The common theme in these changes is that the libraries in the runtime need some changes to work well in a sandboxed setting. Getting these changes in place takes time, but we’re making steady progress.

Over the fence

On the desktop side, both GNOME Settings and GNOME Software will show Flatpak permissions in more detail in their upcoming releases.

Looking ahead

Now that Flatpak 1.2 is out, we are getting  ready to unveil a much-improved Flathub. Stay tuned!

This week I started a new small project called Timetrack, you can find the code in the gnome gitlab.

This is a simple app to store an activity log in a sqlite database and to provide useful reports in the future. The main idea is to use this for may day to day work, so I'll be able to keep track of my working hours and other activities.

The need

There's a lot of timetrack applications. There are good web apps and also some desktop applications. At first, I tried to find a gnome-shell plugin, but I didn't find any extension that is good for me.

I've had a custom simple web app to track my time.

I've been using this app for a long time, but I don't like to use web apps for simple tasks so I want something local.

So I tried with some gtk desktop applications, but none of the applications that I've found looks good to me.

I wanted a simple timetrack app, without any complex stuff, so I thought that it won't be hard to implement it. So I started with a simple python app based on the code of Password Safe.

So I started to code and in two days I had a simple application that works. The applications is now on flathub so it's available for use.

The functionality

Right now, Timetrack has a limited set of features, but I think I'll improve the app with new features as soon as I need something. So, the current version can:

• Track activity time with a simple button, showing the activity time spent
• List last activities
• Edit / Delete activities
• Simple report by day, week or month
• Report navigation using a calendar

I've plans to add more functionalities in the near future, like:

• Report export to plain text and csv
• Comments for activities
• Tags for activities
• Detailed reports
• Activity Graphs

All of this is stored in a sqlite database, if you install the app using flatpak you can find the database in this path: ~/.var/app/net.danigm.timetrack/data/timetrack.sqlite3.

I've done the icon for this app using the gnome-clocks icon and adding some colors to it.

If you find this app useful, don't hesitate and use it. Any feature request or bug report is welcome. And of course, all is free software, so if you want to collaborate, go ahead and send me some Merge Request.