You are here

Agreguesi i feed

How Creative DDOS Attacks Still Slip Past Defenses - Hën, 12/03/2018 - 12:17md Distributed denial of service attacks, in which hackers use a targeted hose of junk traffic to overwhelm a service or take a server offline, have been a digital menace for decades. But in just the last 18 months, the public picture of DDoS defense has evolved rapidly.

Michael Meeks: 2018-03-11 Sunday

Planet GNOME - Dje, 11/03/2018 - 10:00md
  • Up, cooked breakfast in bed for J. with M. - presents, cards, a banner, etc. for the sweetheart. Out to All Saints, played bass; enjoyed Max's sermon. Home for roast lunch.
  • Slugged; digested; played guitar much of the afternoon while babes played lego (a break from minetest), and Smash-Up. Julie over for tea.

Jeremy Bicha: webkitgtk in Debian Stretch: Report Card

Planet GNOME - Sht, 10/03/2018 - 6:37md

webkitgtk is the GTK+ port of WebKit. webkitgtk provides web functionality for many things including GNOME Online Accounts’ login panels; Evolution’s HTML email editor and viewer; and the engine for the Epiphany web browser (also known as GNOME Web).

Last year, I announced here that Debian 9 “Stretch” included the latest version of webkitgtk (Debian’s package is named webkit2gtk). At the time, I hoped that Debian 9 would get periodic security and bugfix updates. Nine months later, let’s see how we’ve been doing.

Release History

Debian 9.0, released June 17, 2017, included webkit2gtk 2.16.3 (up to date).

Debian 9.1 was released July 22, 2017 with no webkit2gtk update (2.16.5 was the current release at the time).

Debian 9.2, released October 8, 2017, included 2.16.6 (There was a 2.18.0 release available then but for the first stable update, we kept it simple by not taking the brand new series.)

Debian 9.3 was released December 9, 2017 with no webkit2gtk update (2.18.3 was the current release at the time).

Debian 9.4 released March 10, 2018 (today!), includes 2.18.6 (up to date).

Release Schedule

webkitgtk development follows the GNOME release schedule and produces new major updates every March and September. Only the current stable series is supported (although sometimes there can be a short overlap; 2.14.6 was released at the same time as 2.16.1). Distros need to adopt the new series every six months.

Like GNOME, webkitgtk uses even numbers for stable releases (2.16 is a stable series, 2.16.3 is a point release in that series, but 2.17.3 is a development release leading up to 2.18, the next stable series).

There are webkitgtk bugfix releases, approximately monthly. Debian stable point releases happen approximately every two or three months (the first point release was quicker).

In a few days, webkitgtk 2.20 will be released. Debian 9.5 will need to include 2.20.1 (or 2.20.2) to keep users on a supported release.

Report Card

From five Debian 9 releases, we have been up to date in 2 or 3 of them (depending on how you count the 9.2 release).

Using a letter grade scale, I think I’d give Debian a B or B- so far. But this is significantly better than Debian 8 which offered no webkitgtk updates at all except through backports. In my grading, Debian could get a A- if we consistently updated webkitgtk in these point releases.

To get a full A, I think Debian would need to push the new webkitgtk updates (after a brief delay for regression testing) directly as security updates without waiting for point releases. Although that proposal has been rejected for Debian 9, I think it is reasonable for Debian 10 to use this model.

If you are a Debian Developer or Maintainer and would like to help with webkitgtk updates, please get in touch with Berto or me. I, um, actually don’t even run Debian (except briefly in virtual machines for testing), so I’d really like to turn over this responsibility to someone else in Debian.


I find the Repology webkitgtk tracker to be fascinating. For one thing, I find it humorous how the same package can have so many different names in different distros.

Jiri Eischmann: Flathub Experience: Adding an App

Planet GNOME - Pre, 09/03/2018 - 6:22md

Flathub is a new distribution channel for Linux desktop apps. Truly distro-agnostic, unifying across abundance of Linux distributions. I was planning for a long time to add an application to Flathub and see what the experience is, especially compared to traditional distro packaging (I’m a Fedora packager). And I finally got to it this last week.

In Fedora I maintain PhotoQt, a very fast image viewer with very unorthodox UI. Its developer is very responsive and open to feedback. Already back in 2016 I suggested he provides PhotoQt as a flatpak. He did so and found making a flatpak really easy. However it was in the time before Flathub, so he had to host its own repo.

Last week I was notified about a new release of PhotoQt, so I prepared updates for Fedora and noticed that the Flatpak support became “Coming soon” again. So I was like “hey, let’s get it back and to Flathub”. I picked up the two-year-old flatpak manifest, and started rewriting it to successfully build with the latest Flatpak and meet Flathub requirements.

First I updated dependencies. You add dependencies to the manifest in a pretty elegant way, but what’s really time consuming is getting checksums of official archives. Most projects don’t offer them at all, so you have to download the archive and generate it yourself. And you have to do it with every update of that dependency. I’d love to see some repository of modules. Many apps share the same dependencies, so why to do the same work again and again with every manifest?

Need to bundle the latest LibRaw? Go to the repository and pick the module info for your manifest:

"name": "libraw",
"cmake": false,
"builddir": true,
"sources": [ { "type": "archive", "url": "", "sha256":"56aca4fd97038923d57d2d17d90aa11d827f1f3d3f1d97e9f5a0d52ff87420e2" } ]

And on the top of such a repo you can actually build a really nice tooling. You can let the authors of apps add dependencies simply by picking them from the list and you can generate the starting manifest for them. And you could also check for dependency updates for them. LibRaw has a new version, wanna bundle it, and see how your app builds with it? And the LibRaw module section of your manifest would be replaced by the new one and a build triggered.

Of course such a repo of modules would have to be curated because one could easily sneak in a malicious module. But it would make writing manifests even easier.

Besides updating dependencies I also had to change the required runtime. Back in 2016 KDE only had a testing runtime without any versioning. Flathub now includes KDE runtime 5.10, so I used it. PhotoQt also uses “photoqt” in all file names and Flatpak/Flathub now requires it in the reverse-DNS format: org.qt.photoqt. Fortunately flatpak-builder can rename it for you, you just need to state it in the manifest:

"rename-desktop-file": "photoqt.desktop",
"rename-appdata-file": "photoqt.appdata.xml",
"rename-icon": "photoqt",

Once I was done with the manifest, I looked at the appdata file. PhotoQt has it in a pretty good shape. It was submitted by me when I packaged it for Fedora. But there were still a couple of things missing which are required by Flathub: OASR and release info. So I added it.

I proposed all the changes upstream and at this point PhotoQt was pretty much ready for submitting to Flathub. I never intended to maintain PhotoQt in Flathub myself. There should be a direct line between the app author and users, so apps should be maintained by app authors if possible. I knew that upstream was interested in adding PhotoQt to Flathub, so I contacted the upstream maintainer and asked him whether he wanted to pick it up and go through the Flathub review process himself or whether I should do it and then hand over the maintainership to him. He preferred the former.

The review was pretty quick and it only took 2 days between submitting the app and accepting it to Flathub. There were three minor issues: 1. the reviewer asked if it’s really necessary to give the app access to the whole host, 2. app-id didn’t match the app name in the manifest (case sensitivity), 3. by copy-pasting I added some spaces which broke the appdata file and of course I was too lazy to run validation before submitting it.

And that was it. Now PhotoQt is available in Flathub. I don’t remember how much time exactly it took me to get PhotoQt to Fedora, but I think it was definitely more and also the spec file is more complex than the flatpak manifest although I prefer the format of spec files to json.

Is not your favorite app available in Flathub? Just go ahead, flatpak it, and then talk to upstream, and try to hand the maintainership over to them.

Christian Hergert: Device Integration

Planet GNOME - Pre, 09/03/2018 - 6:51pd

I’ve been working on some groundwork features to sneak into Builder 3.28 so that we can build upon them for 3.30. In particular, I’ve started to land device abstractions. The goal around this is to make it easier to do cross-architecture development as well as support devices like phones, tablets, and IoT.

For every class and kind of device we want to support, some level of integration work will be required for a great experience. But a lot of it shares some common abstractions. Builder 3.28 will include some of that plumbing.

For example, we can detect various Qemu configurations and provide cross-architecture building for Flatpak. This isn’t using a cross-compiler, but rather a GCC compiled for aarch64 as part of the Flatpak SDK. This is much slower than a proper cross-compiler toolchain, but it does help prove some of our abstractions are working correctly (and that was the goal for this early stage).

Some of the big things we need to address as we head towards 3.30 include running the app on a remote device as well as hooking up gdb. I’d like to see Flatpak gain the support for providing a cross-compiler via an SDK extension too.

I’d like to gain support for simulators in 3.30 as well. My personal effort is going to be based around GNU-based systems. However, if others join in and want to provide support for other sorts of devices, I’d be happy to get the contributions.

Anyway, Builder 3.28 can do some interesting things if you know where to find them. So for 3.30 we’ll polish them up and make them useful to vastly more people.

Matthias Clasen: Fedora Atomic Workstation: Trying things out the easy way

Planet GNOME - Enj, 08/03/2018 - 2:21md

If you’ve followed my posts about my first steps with Fedora Atomic Workstation, you may have seen that I’ve had to figure out how to make codecs work in the firefox that is included in the OS image. And then I had to work around some issues with the layered packages that I used for that when I rebased to a newer OS.

But maybe there is a better way to go about this?

Flatpak is the preferred way to install applications on the Atomic Workstation, so maybe that is the way to go. So far, all the flatpaks I’ve installed have come from Flathub, which is a convenient place to find all sorts of desktop apps. But firefox is not there (yet).

Thankfully, flatpak is fundamentally decentralized by design. There is nothing special about Flathub, flatpak can easily install apps from many different sources. A quick search yielded this unofficial firefox flatpak repository, with easy-to-follow instructions. Just clicking on this link will also work. If you open it with a sandboxed firefox, you will see the URI portal in action:

One nice aspect of this is that the nightly firefox is not just a one-off package that I’ve installed, it will receive updates just like any other app on my system. An important detail when it comes to web browsers!

Another nice aspect is that I did not have to remove the firefox that is already installed (I couldn’t anyway, since it is part of the immutable OS image). The two can peacefully coexist.

This is true not just for firefox, but in general: by isolating apps and their dependencies from each other, flatpak makes it very easy to try out different versions of apps without pain.

Want to try some bleeding-edge GNOME apps instead of the stable versions that are available on Flathub? No problem,  just enable the GNOME nightly repository like this:

flatpak remote-add --user --from gnome-apps-nightly

And then the nightly apps will be available for installation next to their stable counterparts. Note that GNOME software will indicate the source for each app in the search results.

Trying out new software has never been safer and easier!

Sorry for the wrong-colored screenshots in this post – there is still a price to pay for living on the bleeding edge of rawhide, even if Atomic Workstation makes it much safer.

Jakub Steiner: What 3 Words?

Planet GNOME - Enj, 08/03/2018 - 8:06pd

I dig online maps like everyone else, but it is somewhat clumsy sharing a location. The W3W service addesses the issue by chunking up the whole world into 3x3m squares and assigning each a name (Supposedly around 57 trillion). Sometimes it’s a bit of a tongue twister, but most of the time it’s fun to say to meet at a “massive message chuckle” for some fpv flying. I’m really surprised this didn’t take off.

Jussi Pakkanen: Stop trying to guess display language based on keyboard layout

Planet GNOME - Mër, 07/03/2018 - 11:41md
A very common setup among non-English speaking computer power users is to have display language in English but have a country specific keyboard layout. For example I'm using the Finnish keyboard because I need to be able to easily type our special letters ö and ä. If your computer comes from someone else (such as your employer) there is not even the possibility to have a non-Finnish keyboard layout.

All of this has worked for tens of years flawlessly. However recently I have noticed that many programs on multiple platforms seem to alter their display language based on keyboard layout, which is just plain wrong. Display language should be chosen based on the display language choice and nothing else.

I first noticed this in the output of ls, which one would imagine to have reached stability ages ago.

Here we see that ls has chosen to print months in Finnish. Why? I have no idea. This was weird on its own, but then it spread to other operating systems as well. For no reason at all the existing Gimp install switched its display language to Finnish.

Let me reiterate: no setting was changed and the version of Gimp was exactly the same. One day it just decided to change its language to Finnish.

Then the issue spread to Windows.

VLC on Windows has chosen on my behalf to show its menus in Finnish in a completely English Windows 7 install. The only things it could use for language detection are geolocation and keyboard settings and both of these are terrible ideas. The OS has a language. It is very clearly specified. All other applications obey it, VLC should too.

The real kicker here is that Gimp on Windows displays English text correctly, as does VLC on macOS.

The newest case is the new Gnome-ified Ubuntu, whose lock screen stubbornly displays dates in the wrong language. It also does not conjugate the words correctly and has that weird american month/date date ordering which is wrong for Finnish.

What is causing this?I don't know. But whoever is behind this: please stop doing that.

Jim Hall: March Madness brackets in PHP

Planet GNOME - Mër, 07/03/2018 - 8:19md
It's March, and that means I've written yet another article about a program that helps you fill in your NCAA "March Madness" game brackets. This article is a bit different. Where my previous articles described how to write a Bash script to "predict" March Madness brackets, this year's article walks through a PHP script that generates a full bracket.

For those of you who aren't in the U.S., we have a game here called Basketball. And every year in March, the university level (called the National Collegiate Athletic Association, or NCAA) holds a single-elimination championship of the different university teams. If you follow basketball, you can fill out a bracket to "predict" the championship outcomes at each round.

Some people really get into creating their brackets, and they closely follow the teams over the season to see how they are doing. I used to work in an office that cared a lot about March Madness (although in honesty, the office I'm in now doesn't really follow the games that much—but forgive me that I didn't update my Linux Journal article to say so.) I didn't want to miss out on the fun in following March Madness.

I don't follow basketball, but one year I decided to write a little random-number generator to predict the games for me. I used this program to fill out my brackets. And a few years ago, I started writing about it.

Read the article, and use the PHP program to fill out your own March Madness bracket! Let me know how your bracket fared in this year's games.
image: Wikimedia (public domain)

Reproducible Builds: Weekly report #149

Planet Debian - Mër, 07/03/2018 - 4:21pd

Here's what happened in the Reproducible Builds effort between Sunday February 25 and Saturday March 3 2018:

diffoscope development

Version 91 was uploaded to unstable by Mattia Rizzolo. It included contributions already covered by posts of the previous weeks as well as new ones from:

In addition, Juliana — our Outreachy intern — continued her work on parallel processing; the above work is part of it.

reproducible-website development Packages reviewed and fixed, and bugs filed

An issue with the pydoctor documentation generator was merged upstream.

Reviews of unreproducible packages

73 package reviews have been added, 37 have been updated and 26 have been removed in this week, adding to our knowledge about identified issues.

Weekly QA work

During our reproducibility testing, FTBFS bugs have been detected and reported by:

  • Adrian Bunk (46)
  • Jeremy Bicha (4)

This week's edition was written by Chris Lamb, Mattia Rizzolo & reviewed by a bunch of Reproducible Builds folks on IRC & the mailing lists.

Reproducible builds folks Reproducible builds blog

Federico Mena-Quintero: Helping Cairo

Planet GNOME - Mër, 07/03/2018 - 1:22pd

Cairo needs help. It is the main 2D rendering library we use in GNOME, and in particular, it's what librsvg uses to render all SVGs.

My immediate problem with Cairo is that it explodes when called with floating-point coordinates that fall outside the range that its internal fixed-point numbers can represent. There is no validation of incoming data, so the polygon intersector ends up with data that makes no sense, and it crashes.

I've been studying how Cairo converts from floating-point to its fixed-point representation, and it's a nifty little algorithm. So I thought, no problem, I'll add validation, see how to represent the error state internally in Cairo, and see if clients are happy with getting back a cairo_t in an error state.

Cairo has a very thorough test suite... that doesn't pass. It is documented to be very hard to pass fully for all rendering backends. This is understandable, as there may be bugs in X servers or OpenGL implementations and such. But for the basic, software-only, in-memory image backend, Cairo should 100% pass its test suite all the time. This is not the case right now; in my tree, for all the tests of the image backend I get

497 Passed, 54 Failed [0 crashed, 14 expected], 27 Skipped

I have been looking at test failures to see what needs fixing. Some reference images just need to be regenerated: there have been minor changes in font rendering that broke the reference tests. Some others have small differences in rendering gradients - not noticeable by eye, just by diff tools.

But some tests, I have no idea what changed that made them break.

Cairo's git repository is accessible through []. As far as I know there is no continuous integration infrastructure to ensure that tests keep passing.

Adding minimal continuous testing

I've set up a Cairo repository at That branch already has a fix for an uninitialized-memory bug which leads to an invalid free(), and some regenerated test files.

The repository is configured to run a continuous integration pipeline on every commit. The test artifacts can then be downloaded when the test suite fails. Right now it is only testing the image backend, for in-memory software rendering.

Initial bugs

I've started reporting a few bugs against that repository for tests that fail. These should really be in Cairo's Bugzilla, but for now Gitlab makes it much easier to include test images directly in the bug descriptions, so that they are easier to browse. Read on.

Would you like to help?

A lot of projects use Cairo. We owe it to ourselves to have a library with a test suite that doesn't break. Getting to that point requires several things:

  • Fixing current failures in the image backend.
  • Setting up the CI infrastructure to be able to test other backends.
  • Fixing failures in the other backends.

If you have experience with Cairo, please take a look at the bugs. You can see the CI configuration to see how to run the test suite in the same fashion on your machine.

I think we can make use of modern infrastructure like gitlab and continuous integration to improve Cairo quickly. Currently it suffers from lack of attention and hostile tools. Help us out if you can!

Skellam distribution likelihood

Planet Debian - Mar, 06/03/2018 - 10:37md

I wondered if it was possible to make a ranking system based on the Skellam distribution, taking point spread as the only input; first step is figuring out what the likelihood looks like, so here's an example for k=4 (ie., one team beat the other by four goals):

It's pretty, but unfortunately, it shows that the most likely combination is µ1 = 0 and µ2 = 4, which isn't really that realistic. I don't know what I expected, though :-)

Perhaps it's different when we start summing many of them (more games, more teams), but you get into too high dimensionality to plot. If nothing else, it shows that it's hard to solve symbolically by looking for derivatives, as the extreme point is on an edge, not on a hill.

Steinar H. Gunderson Steinar H. Gunderson

Debian Bug Squashing Party in Tirana

Planet Debian - Mar, 06/03/2018 - 10:15md

On 3 March I attended a Debian Bug Squashing Party in Tirana. Organized by colleagues at Open Labs Albania Anisa and friends and Daniel. Debian is the second oldest GNU/Linux distribution still active and a launchpad for so many others.

A large number of Kosovo participants took place, mostly female students. I chose to focus on adding Kosovo to country-lists in Debian by verifying that Kosovo was missing and then filing bug reports or, even better, doing pull requests.

apt-cache rdepends iso-codes will return a list of packages that include ISO codes. However, this proved hard to examine by simply looking at these applications on Debian; one would have to search through their code to find out how the ISO MA-3166 codes are used. So I left that for another time.

I moved next to what I thought I would be able complete within the event. Coding is becoming quite popular with children in Kosovo. I looked into MIT’s Scratch and Google’s Blockly, the second one being freeer software and targeting younger children. They both work by snapping together logical building blocks into a program.

Translation of Blockly into Albanian is now complete and hopefully will get much use. You can improve on my work at Translatewiki.

Thank you for the all fish and see you at the next Debian BSP.

Advertisements &b &b Arianit debian – Arianit's Blog

Ross Burton: Rewriting Git Commit Messages

Planet GNOME - Mar, 06/03/2018 - 6:00md

So this week I started submitting a seventy-odd commits long branch where every commit was machine generated (but hand reviewed) with the amazing commit message of "component: refresh patches". Whilst this was easy to automate the message isn't acceptable to merge and I was facing the prospect of copy/pasting the same commit message over and over during an interactive rebase. That did not sound like fun. I ended up writing a tiny tool to do this and thought I'd do my annual blog post about it, mainly so I can find it again when I need to do it again next year...

Wise readers will know that Git can rewrite all sorts of things in commits programatically using git-filter-branch and this has a --msg-filter argument which sounds like just what I need. But first a note: git-filter-branch can destroy your branches if you're not careful!

git filter-branch --msg-filter has a simple behaviour: give it a command to be executed by the shell, the old commit message is piped in via standard input, and whatever appears on standard output is the new commit message. Sounds simple but in a way it's too simple, as even the example in the documentation has a glaring problem.

Anyway, this should work. I have a commit message in a predictable format (: refresh patches) and a text editor containing a longer message suitable for submission. I could write a bundle of shell/sed/awk to munge from one to the other but I decided to simply glue a few pieces of Python together instead:

import sys, re input_re = re.compile(open(sys.argv[1]).read()) template = open(sys.argv[2]).read() original_message = match = input_re.match(original_message) if match: print(template.format(**match.groupdict())) else: print(original_message)

Invoke this with two filenames: a regular expression to match on the input, and a template for the new commit message. If the regular expression matches then any named groups are extracted and passed to the template which is output using the new-style format() operation. If it doesn't match then the input is simply output to preserve commit messages.

This is my input regular expression:

^(?P<recipe>.+): refresh patches

And this is my output template:

{recipe}: refresh patches The patch tool will apply patches by default with "fuzz", which is where if the hunk context isn't present but what is there is close enough, it will force the patch in. Whilst this is useful when there's just whitespace changes, when applied to source it is possible for a patch applied with fuzz to produce broken code which still compiles (see #10450). This is obviously bad. We'd like to eventually have do_patch() rejecting any fuzz on these grounds. For that to be realistic the existing patches with fuzz need to be rebased and reviewed. Signed-off-by: Ross Burton <>

A quick run through filter-branch and I'm ready to send:

git filter-branch --msg-filter ' input output' origin/master...HEAD

Matthias Clasen: Input methods in GTK+ 4

Planet GNOME - Mar, 06/03/2018 - 2:36md

GTK’s support for loadable modules dates back to the beginning of time, which is why GTK has a lot of code to deal with GTypeModules and with search paths, etc. Much later on, Alex revisited this topic for GVfs, and came up with the concept of extension points and GIO modules, which implement them.  This is a much nicer framework, and GTK 4 is the perfect opportunity for us to switch to using it.

Changes in GTK+ 4

Therefore, I’ve recently spent some time on the module support in GTK. The major changes here are the following:

  • We no longer support general-purpose loadable modules. One of the few remaining users of this facility is libcanberra, and we will look at implementing ‘event sound’ functionality directly in GTK+ instead of relying on a module for it. If you rely on loading GTK+ modules, please come and talk to us about other ways to achieve what you are doing.
  • Print backends are now defined using an extension point named “gtk-print-backend”, which requires the type GtkPrintBackend.  The existing print backends have been converted to GIO modules implementing this extension point. Since we have never supported out-of-tree print backends, this should not affect anybody else.
  • Input methods are also defined using an extension point, named “gtk-im-module”, which requires the GtkIMContext type.  We have dropped all the non-platform IM modules, and moved the platform IM modules into GTK+ proper, while also implementing the extension point.
Adapting existing input methods

Since we still support out-of-tree IM modules, I want to use the rest of this post to give a quick sketch of how an out-of-tree IM module for GTK+ 4 has to look.

There are a few steps to convert a traditional GTypeModule-based IM module to the new extension point. The example code below is taken from the Broadway input method.


We are going to load a type from a module, and G_DEFINE_DYNAMIC_TYPE is the proper way to define such types:

G_DEFINE_DYNAMIC_TYPE (GtkIMContextBroadway, gtk_im_context_broadway, GTK_TYPE_IM_CONTEXT)

Note that this macro defines a gtk_im_context_broadway_register_type() function, which we will use in the next step.

Note that dynamic types are expected to have a class_finalize function in addition to the more common class_init, which can be trivial:

static void gtk_im_context_broadway_class_finalize (GtkIMContextBroadwayClass *class) { } Implement the GIO module API

In order to be usable as a GIOModule, a module must implement three functions: g_io_module_load(), g_io_module_unload() and g_io_module_query() (strictly speaking, the last one is optional, but we’ll implement it here anyway).

void g_io_module_load (GIOModule *module) { g_type_module_use (G_TYPE_MODULE (module)); gtk_im_context_broadway_register_type (G_TYPE_MODULE (module)); g_io_extension_point_implement (GTK_IM_MODULE_EXTENSION_POINT_NAME, GTK_TYPE_IM_CONTEXT_BROADWAY, "broadway", 10); } void g_io_module_unload (GIOModule *module) { } char ** g_io_module_query (void) { char *eps[] = { GTK_IM_MODULE_EXTENSION_POINT_NAME, NULL }; return g_strdupv (eps); } Install your module properly

GTK+ will still look in $LIBDIR/gtk-4.0/immodules/ for input methods to load, but GIO only looks at shared objects whose name starts with “lib”, so make sure you follow that convention.


And thats it!

Now GTK+ 4 should load your input method, and if you run a GTK+ 4 application with GTK_DEBUG=modules, you should see your module show up in the debug output.


Debarshi Ray: Emojis in VTE

Planet GNOME - Hën, 05/03/2018 - 3:36md

It’s been one of those weeks when gnome-terminal and vte keep stumbling on some really weird edge cases, so it was a happy moment when I saw this on Fedora 27 Workstation.

Jussi Pakkanen: Compiling Cargo crates natively with Meson

Planet GNOME - Dje, 04/03/2018 - 2:35md
Recently we have been having discussions about how Rust and Meson should work together, especially for mixed language projects. One thing which multiple people have told me (over a time span of several years, actually) is that Rust is Special in that everyone uses crates for everything. Thus there is no point in having any sort of Rust support, the only true way is to blindly call Cargo and have it do everything exactly the way it wants to.

This seems like a reasonable recommendation so I did what every reasonable person would do and accepted this as is.

But then curiosity takes hold of you and you start to wonder. Is that really the case?
Converting Cargo manifests to Meson projectsThe basic setup of a Cargo project is fairly straightforward. The file format is mostly declarative and most crates are simple libraries that have a few source files and a bunch of other crates they link against. Meson has the same primitives, so could they be automatically converted.
It turns out that for simple examples you can. Here is a sample repo that downloads the Itoa crate from github, converts the Cargo build definition into a Meson project and builds it as a subproject (with Meson, not Cargo) of the main project that uses it. This prototype turned out to require 71 lines of Python.What about dependencies other than itoa?The script currently only works for itoa, because does not seem to provide a web API for queries and the entire site is created with JavaScript so you can't even do web scraping easily. To get this working properly the only thing you'd need is a function to get from (crate name, version) to the git repo.What about dependencies of dependencies?They can be easily grabbed from Cargo.toml file. Combined with the above they could be downloaded and converted in the same fashion.What doesn't work?A lot. Unit tests are not built nor run, but they could be added fairly easily. This would require adding compile options so the actual source could be built with the unittest flags. This is some amount of work but Meson already supports a similar feature for D so adding it should not be a huge amount of work. Similarly docs are not generated.What about provides a fairly simple project model and everything more complex should be handled by writing a program that does everything else necessary. This suffers from the same disadvantages as every Turing complete build system ever has, and these scripts are not in general possible to convert automatically.
However based on documentation the common case seems to be to call into external build tools to build dependency libraries in other languages. In a build system that builds both parts at the same time it would be possible to create a better UX for this (but again would obviously not be something you can convert automatically).Could this actually work in practice with real world projects?It might. It might not. Ignoring the previous segment no immediate showstopper has presented itself thus far. It might in the future. But you never know until you try.

Adrien Plazas: One Widget to Adapt Them All and to The Librem 5 Port Them

Planet GNOME - Dje, 04/03/2018 - 8:56pd

In my previous article I shared my plans to help porting existing GTK+ applications to Purism's upcoming Librem 5 phone without having to fork them. This article will present the GTK+ widget I developed for Purism to make this happen.

For more information on what Purism is working on for the Librem 5, please check Nicole Faerber's latest article.

C'est pas sorcier

The underlying idea is to allow applications to dynamically switch between the two main GNOME application layouts: a row of panels — each panel being the view of an element from the previous one — and a stack of panels. The goal isn't to changes applications using the stack paradigm but the ones using the row one, allowing them to reach smaller sizes and to be usable on constrained sizes while keeping their initial paradigm and design when the screen space is sufficient. The development cost to port the applications to this adaptive design should be as low as possible.

To achieve that, I wrote a GTK+ widget which acts similarly to a GtkBox when there is plenty of space for its children, but which adapts automatically and acts similarly to a GtkStack when there isn't, displaying only one of its children. I called this widget HdyStackableBox and it is being developed for the libhandy library.

The widget's minimum size is the minimum size of its visible child, matching the minimum size of a GtkStack. The widget's natural size is the sum of the natural sizes of its children, matching size of a GtkBox.

The threshold below which the widget will turn into a stack is the sum of the natural sizes of its children — hence, when allocated less than its natural size the widget will turn into a stack. In box mode, the minimum size allocated to the children is their natural size, combined to the previously defined threshold this allows a collapsing priority property to naturally emerge as, when nesting HdyStackableBoxes, the wrapping one will collapse into a stack before the nested one. This is what I consider the biggest feature of this widget: this widget offers an adaptive behavior with no magic number involved.

Features of HdyStackableBox

HdyStackableBox is still in development, here is a list of already implemented features.

  • Mode: box or stack.
  • Adaptive design.
  • Box homogeneity.
  • Stack homogeneity.
  • Mode transition:
    • None and slide animations.
    • Its duration is settable up to 250ms (like GtkRevealer).
  • Child transition:
    • None animation.
    • Its duration is settable up to 200ms (like GtkStack).
  • Named children.
  • Unlimited children.

Here is a list of features that may or may not be implemented later.

  • Draw on its own windows: the animations currently causes the widget to draw out of its allocated space.
  • Mode transition: slide over animation, similarly to hiding the left panel of DzlBin.
  • Child transition: slide animation.
  • Orientation: this is partially implemented.
  • Text direction: right-to-left languages should be supported.
Gimme! Gimme! Gimme!

The code is currently hosted at my fork of libhandy. You can test the widget by cloning the repo in GNOME Builder, moving to the wip/aplazas/stackablebox branch, building and running the project.

To test the widget in real world applications, I quickly tested it on GNOME Contacts. It is mostly ported and should work just fine, if not don't hesitate to report any strange behavior to me but only regarding the adaptive port.

GNOME Contacts with adaptive design and full navigation in stack mode

Adaptive GNOME Contacts running on an i.MX 6 development board and a phone screen.

I also tested it on Geary, there is no navigation implemented yet but it's a good test case of a complex UI with a HdyStackableBox nested into another.

Geary and its nested stackable boxes.

Adaptive design is useful even on the desktop for Geary.

Sorry for the graphical glitches, I suspect they are caused by a mix of out-of-bound drawings and improper/missing resizing and redraw queries, they will be fixed. You can test these by yourself by cloning, building and running these branches in GNOME Builder.

Keep in mind that my libhandy, GNOME Contacts and Geary forks are expected to disappear at some point in the future, and that I don't guaranty their quality as this is all in development.

/* TODO */

As you can see in the list of unimplemented features and in the videos, there is still a lot to do, polishing the widget to make it featureful and bug free will take time, probably a few more weeks of focused development. In the meantime, feedback from designers on what this widget could be used for and — perhaps more importantly — what it shouldn't be used for is more than welcome!

Once ready, what about turning it into GtkStackableBox? That would help its adoption by important applications like Settings, which probably don't want an extra dependency just for a widget but which could then work on the Librem 5 without yet another major redesign.

Jim Campbell: About

Planet GNOME - Sht, 03/03/2018 - 4:08pd

My name is Jim Campbell. I am a contributor to the GNOME Documentation Project, and am a co-organizer of the Chicago GNU/Linux User Group. I currently live in Chicago, Illinois.

If you'd like to get in touch with me, feel free to send me an email! You can reach me at: jcampbell - at - gnome dot org.


This site is built with Gutenberg, a Rust-based static site generator.


All media and text on this website are provided under the CC-by-SA 4.0 license unless otherwise noted.

Jim Campbell: LibrePlanet 2016 - Freedom Sympatico

Planet GNOME - Sht, 03/03/2018 - 4:08pd

Hello!! I emerge from my blogging slumber as part of some post-hospital-merger / post-Affordable-Care-Act-administration free software activities. You see, I went to LibrePlanet this past weekend, and I was as happy as this guy to be there:

The various LibrePlanet session videos are making their way out to the LibrePlanet MediaGoblin instance, and I encourage you to check them out as they become available. It was a well-run, informationally-dense conference.

This year's event seemed to have a bit of an advocacy and social justice bent. I'm thinking in particular of LittleSis and of the Library Freedom Project. I'm also thinking of Luis Villa's talk, where he drove home how we can't just give people software licensed under the GPL and think that they automatically have their computing freedom - that we need to make that software compelling for users to actually want to use. I found this to be sympatico with some of the recent work and discussions around UserOps.

On the technical project side of things, Ring seems interesting, though in early stages of development. GNU Guix seems to at least be beta quality. GNOME is now available as a desktop in GNU Guix, so I may be checking it out soon.

DRM and the W3C

Something that wasn't part of the conference, but which immediately followed it, was a rally against inclusion of the Encrypted Media Extensions specification. The spec is currently under consideration by the W3C. If you want more info about the protest, Chris Webber gave a thorough recap of it, along with details of the post-protest roundtable discussion at the MIT Media Lab.

The interesting thing about the EME spec is that it doesn't describe DRM - it just seems to describe an intricately shaped hole in which the only thing that will fit is DRM.


Subscribe to AlbLinux agreguesi