fidzu : GNOME

var a = 1n;
var b = a + 42n;
b << 64n
// result: 793209995169510719488n

typeof 1n
// result: 'bigint'

23 May 2019 12:13pm GMT

First of all I do not want people to get their hopes up about $subject of this blogpost. Improving gaming support is a subjects which holds my personal interest and it is an issue I plan to spend time on trying to improve. But this will take a lot of time (think months for simple things, years for more complex things).

As I see it there are currently 2 big issues when running games under Wayland:

1. Many games show as a smal centered image with a black border (letterbox) around the image when running fullscreen.

For 2D games this is fixed by switching to SDL2 which will transparently scale the pixmap the game renders to the desktop resolution. This assumes that 2D games in general do not demand a lot of performance and thus will not run into performance issues when introducing an extra scaling step. A problem here is that many games still use SDL1.2 (and some games do not use SDL at all).

I plan to look into the recently announced SDL1.2 compatibility wrapper around SDL2. If this works well this should fix this issue for all SDL1.2 2D games, by making them use SDL2 under the hood.

For 3D games this can be fixed by rendering at the desktop resolution, but this might be slow and rendering at a lower resolution leads to the letterbox issue.

Recently mutter has has grown support for the WPviewport extension, which allows Wayland apps to tell the compositor to scale the pixmap the app gives to the compositor before presenting it. If we add support to SDL2's Wayland backend for this then, this can be used to allow rendering 3D apps at a lower resolution and still have them fill the entire screen.

Unfortunately there are 2 problems with this plan:

1. 
   
2. SDL2 by default uses its x11 backend, not its wayland backend. I'm not sure what fixes need to be done to change this, at a minimum we need a fix at either the SDL or mutter side for this issue, which is going to be tricky.
   
3. This only helps for SDL2 apps, again hopefully the SDL1.2 compatibility wrapper for SDL2 can help here, at least for games using SDL.
   

2. Fullscreen performance is bad with many games.

Since under Wayland games cannot change the monitor resolution, they need to either render at the full desktop resolution, which can be very slow; or they render at a lower resolution and then need to do an extra scaling step each frame.

If we manage to make SDL2's Wayland backend the default and then add WPviewport support to it then this should help by reducing an extra memcpy/blit of a desktop-sized pixmap. Currently what apps which use scaling do is:

1. 
   
2. render lower-res-pixmap;
   
3. scale lower-res-pixmap to desktop-res-pixmap
   
4. give desktop-res-pixmap to the compositor;
   
5. compositor does a hardware blit of the desktop-res-pixmap to the framebuffer.
   

With viewport support this becomes:

1. 
   
2. render lower-res-pixmap;
   
3. give low-res-pixmap to the compositor;
   
4. compositor uses hardware to do a scaling blit from the low-res-pixmap to the desktop-res framebuffer
   

Also with viewport support, the compositor could in the case of there only being the one fullscreen app even keep the framebuffer in lowres and use a hardware scaling drm-plane to send the low-res framebuffer scaled to desktop-res to the output while only reading the low-res framebuffer from memory saving a ton of memory bandwidth. But this optimization is going to be a challenge to pull off.

22 May 2019 4:44pm GMT

Thank you all for the large amount of feedback I have received after my previous Wayland Itches blog post. I've received over 40 mails, below is an attempt at summarizing all the mails.

Highlights

1. Middle click on title / header bar to lower the Window does not work for native apps. Multiple people have reported this issue to me. A similar issue was fixed for not being able to raise Windows. It should be easy to apply a similar fix for the lowering problem. There are bugs open for this here, here and here.

2. Running graphical apps via sudo or pxexec does not work. There are numerous examples of apps breaking because of this, such as lshw-gui and usbivew. At least for X11 apps this is not that hard to fix. But sofar this has deliberately not been fixed. The reasoning behind this is described in this bug. I agree with the reasoning behind this, but I think it is not pragmatic to immediately disallow all GUI apps to connect when run as root starting today.

We need some sort of transition period. So when I find some time for this, I plan to submit a merge-requests which optionally makes gnome-shell/mutter start Xwayland with an xauth file, like how it is done when running in GNOME on Xorg mode. This will be controlled by a gsettings option, which will probably default to off upstream and then distros can choice to override this for now, giving us a transition period

Requests for features implemented as external programs on X11

There are various features which can be implemented as external programs
on X11, but because of the tighter security need to be integrated into the
compositor with Wayland:

• 
  
• Hiding of the mouse-cursor when not used à la unclutter-xfixes, xbanish.
• 
  
• Rotating screen 90 / 270 degrees à la "xrandr -o [left|right]" mostly used through custom hotkeys, possible fix is defining bindable actions for this in gsd-media-keys.
• 
  
• Mapping actions to mouse buttons à la easystroke
• 
  
• Some touchscreen's, e.g. so called smart-screens for education, need manual calibration. Under X11 there are some tools to get the callibration matrix for the touchscreen, after which this can be manually applied through xinput. Even under X11 this currently is far from ideal but at least it is possible there.
• 
  
• Keys Indicator gnome-shell extension. This still works when using Wayland, but only works for apps using Xwayland, it does not work for native apps.
• 
  
• Some sort of xkill and xdotool utility equivalents would be nice
• 
  
• The GNOME on screen keyboard is not really suitable for use with apps which are not touch-enabled, as it lacks a way to send ctrl + key, etc. Because of this some users have reported that it is impossible to use alternative on screen keyboards with Wayland. Not being able to use alternative on screen keyboards is by design and IMHO the proper fix here is to improve GNOME's on screen keyboard.
• 
  

App specific problems

• 
  
• Citrix ICA Client does not work well with Xwayland
• 
  
• Eclipse does not work well with Xwayland
• 
  
• Teamviewer does not work with Wayland. It needs to be updated to use pipewire for screencapturing and the RemoteDesktop portal to inject keyboard and mouse events.
• 
  
• Various apps lack screenrecording / capture support due to the app not having support for pipewire: gImageReader, green-recorder, OBS studio, peek, screenrecorder, slack
• 
  
• For apps which do support pipewire, there is not an option to share the contents of a window, other then the window making the request. On Xorg it is possible to share a random window and since pipewire allows sharing the whole desktop I see no security reason why we would not allow sharing another window.
• 
  
• guake window has incorrect size when using HiDPI scaling, see this issue
• 
  

Miscellaneous problems

• 
  
• Mouse cursor is slow / lags
• 
  
• Drag and drop sometimes does not work, e.g. dragging files into file roller to compress or out of file roller to extract.
• 
  
• Per keyboard layouts. On X11 after plugging in a keyboard, the layout/keymap for just that one keyboard can be updated manually using xinput, allowing different keyboard layouts for different keyboards when multiple keyboards are connected
• 
  
• No-title-bar shell extension, X button can be hit unintentionally, see this issue
• 
  
• Various issues with keyboard layout switching
• 
  

Hard to fix issues

• 
  
• Alt-F2, r equivalent (restart the gnome-shell)
• 
  
• X11 apps running on top of Xwayland do not work well on HiDPI screens
• 
  
• Push-to-talk (passive key grab on space) does not work in Mumble when using native Wayland apps, see this issue
• 
  

Problems with other compositors then GNOME3 / mutter

I've also received several reports about issues when using another Wayland compositor as GNOME / mutter (Weston, KDE, Sway). I'm sorry but I have not looked very closely into these reports. I believe that it is great that Linux users have multiple Desktop Environments to choose from and I wish for the other DEs to thrive. But there are only so many hours in a day so I've chosen to mainly focus on GNOME.

22 May 2019 4:26pm GMT

• Mail chew, M. ill at home; picked up H. and Charlotte after an exam; built slides, poked projections. Lunch. Monthly mgmt call. Admin.

21 May 2019 3:34pm GMT

• Out for a run, mail chew, pleased to see Lubos' improved script to render perf output in kcachegrind - mmerging a couple of cool tools. Picked up babes from school, customer calls until late.

20 May 2019 9:00pm GMT

First, thanks to everyone for the all the help with UEFI modules. There are a ton left, but also a lot done, so we're getting there. If anyone is intimately familiar with ME firmware, I'd also really like some help with this Intel Management Engine document too. Thanks!

20 May 2019 5:06pm GMT

GDA stands for GNOME Data Access and is a library to wrap database connections and its data using GObject classes, you can execute queries and much more.

VDA stands for Vala Data Access, is a library providing a heavily object oriented API to access databases's data.

The API developed for VDA is going to be:

• Heavily Object Oriented
• Asynchronous almost by default
• Provides GObject to database mapping

Object Oriented

GDA uses lot of structures, they are hard to be introspectable, so hard to be used outside C and Vala.

Providers now are Connection objects, so you have to instantiate them and then call open and catch opened signal to know if you are up with the connection.

SQL statements now are Query objects, created from string and now from structured objects with simple API, they can use execute on itself to get a TableModel, AffectedRows or any other Result object. An object for almost all kind of SQL commands will be added, with a simple easy to use API to provides the data it needs to be executed over the Connection.

There are models for tables, rows and columns, some of them implementing GLib.ListModel, so can iterate over their members, like rows in a table or columns in a row.

Asynchronous

Database operations can take time to be executed on servers, locally or remote, so you now have all Query execution as async methods, so for opening connections.

API

As you can notice, some API are still in development for VDA, so you can use the one already working or access GDA's Connection objects if you are using Providers from it.

Eventually all API will be implemented by native Connection objects, without bind GDA. Searching to provide an easy and fast way to access introspection data from databases.

Easy API for New Database Servers

Currently GDA implementation for Providers is hard to implement for new database servers. VDA provides a new easy to implement interfaces, for new database servers, so is possible to extend VDA by creating new libraries, without depend on plugins.

Map objects to databases

Recently, VDA gains Vda.DataObject interface, it provides mapping your object to database's table's row, where the row's columns are mapped to object's properties and back.

Vda.DataObject supports:

• Gets data from the database, through a SELECT query execution
• Sets data in a table's row using an UPDATE command
• Creates new rows in the tables using an INSERT command
• Removes a row in the table using a DELETE command

Best of all you just need:

• Implement Vda.DataObject with just 3 properties
• Mark your object's properties you want to map to the database's table's row's column, using its nick with a text like: @Property Name::id, this is: your field's in the data base can have any supported name, including spaces, we use @ to mark a property as to be mapped and ::id to mark it as an ID property used to query from the database.

All queries to read/write data to the database will be calculated automatically for you. Your class should set a Vda.Connection and the table's name, through Vda.DataObject.database_connection and Vda.DataObject.database_table properties, this last one just at construction time.

This an example on how your code could be seen. Pay attention at initialization() method, was added here to show you how the table is created in the database and how the data is mapped using compatible types, in this case string to variant. In the near feature, could be possible to add automatic table creation if it doesn't exits yet.

public class Client : Object, Vda.DataObject {

    // Database mapping
    [Description (nick="@id::id")]
    public string id { get; set; }
    [Description (nick="@name")]
    public string name { get; set; }
    [Description (nick="@description")]
    public string description { get; set; }
    [Description (nick="@phone")]
    public string phone { get; set; }

    construct {
      database_table_name = "clients";
      id = GLib.Uuid.string_random ();
    }

    public async string initialization () throws GLib.Error {
      var qct = database_connection.parse_string ("CREATE TABLE IF NOT EXISTS clients (id varchar(50), name varchar(50), description varchar(50), phone varchar(50))");
      yield qct.execute (null);
      var qi = database_connection.parse_string ("INSERT INTO clients (id, name, description, phone) VALUES ('"+id+"','"+name+"','"+description+"','"+phone+"')");
      yield qi.execute (null);
      return id;
    }

    // DataObject
    public string database_table_name { get; construct set; }
    public Vda.Connection database_connection { get; set; }
    public Cancellable cancellable { get; set; }
  }

17 May 2019 10:37pm GMT

For about every 250 bug reports I recieve I get an email offering to help. Most of the time the person offering help isn't capable of diving right in the trickiest parts of the code and just wanted to make my life easier. Now I have a task that almost anyone can help with…

For the next version of the LVFS we deploy we're going to be showing what was changed between each firmware version. Rather than just stating the firmware has changed from SHA1:DEAD to SHA1:BEEF and some high level update description provided by the vendor, we can show the interested user the UEFI modules that changed. I'm still working on the feature and without more data it's kinda, well, dull. Before I can make the feature actually useful to anyone except a BIOS engineer, I need some help finding out information about the various modules.

In most cases it's simply googling the name of the module and writing 1-2 lines of a summary about the module. In some cases the module isn't documented at all, and that's fine - I can go back to the vendors and ask them for more details about the few we can't do ourselves. What I can't do is ask them to explain all 150 modules in a specific firmware release, and I don't scale to ~2000 Google queries. With the help of EDK2 I've already done 213 myself but now I've run out of puff.

So, if you have a spare 5 minutes I'd really appreciate some help. The shared spreadsheet is here, and any input is useful. Thanks!

13 May 2019 12:06pm GMT

A nice feature provided by almost every Unix system is rpath. Put simply it is a way to tell the dynamic linker to look up shared libraries in custom directories. Build systems use it to be able to run programs directly from the build directory without needing to fiddle with file copying or environment variables. As is often the case, Windows does things completely differently and does not have a concept of rpath.

In Windows shared libraries are always looked up in directories that are in the current PATH. The only way to make the dynamic linker look up shared libraries in other directories is to add them to the PATH before running the program. There is also a way to create a manifest file that tells the loader to look up libraries in a special place but it is always a specially named subdirectory in the same directory as the executable. You can't specify an arbitrary path in the manifest, so the libraries need to be copied there. This makes Windows development even more inconvenient because you need to either fiddle with paths, copy shared libraries around or statically link everything (which is slooooow).

If you look at Windows executables with a hex editor, you find that they behave much the same way as their unixy counterparts. Each executable contains a list of dependency libraries that it needs, such as helper.dll. Presumably what happens is that at runtime the dynamic linker will parse the exe file and pass the library names to some lookup function that finds the actual libraries given the current PATH value. This raises the obvious question: what would happen if, somehow, the executable file would have an absolute path written in it rather than just the filename?

It turns out that it works and does what you would expect it to. The backend code accepts absolute paths and resolves them to the correct file without PATH lookups. With this we have a working rpath simulacrum. It's not really workable, though, since the VS toolchain does not support writing absolute paths to dependencies in output files. Editing the result files by hand is also a bit suspicious because there are many things that depend on offsets inside the file. Adding or removing even one byte will probably break something. The only thing we can really do is to replace one string with a different one with the same length.

This turns out to be the same problem that rpath entries have on Unix and the solution is also the same. We need to get a long enough string inside the output file and then we can replace it with a different string. If the replacement string is shorter, it can be padded with null bytes because the strings are treated as C strings. I have written a simple test repository doing this, which can be downloaded from Github.

On unix rpath is specified with a command line argument so it can be padded to arbitrary size. Windows does not support this so we need to fake it. The basic idea is simple. Instead of creating a library helper.dll we create a temporary library called aaaaaaaaaaaaaaaaaaaaaaaa.dll and link the program against that. When viewed in a hex editor the executable looks like this.

Now we can copy the library to its real name in a subdirectory and patch the executable. The result looks like this.

The final name was shorter than what we reserved so there are a bunch of zero bytes in the executable. This program can now be run and it will always resolve to the library that we specified. When the program is installed the entry can be changed to just plain helper.dll in the same way making it indistinguishable from libraries built without this trick (apart from the few extra null bytes).

Rpath on Windows: achieved.

Is this practical?

12 May 2019 11:20pm GMT

We create, develop, document and collaborate as users of Free and Open Source Software (FOSS) from around the globe, usually by working remotely on the Internet. However, human beings have many millennia of evolution that makes us predisposed to communicate most effectively via in-person interaction. We don't just rely on the content of communication, but its manner of expression, the body language of the communicator, and thousands of different non-verbal cues and subtle communication mechanisms. In fact, I believe something that's quite radical for a software freedom activist to believe: meeting in person to discuss something is always better than some form of online communication. And this belief is why I attend so many FOSS events, and encourage (and work in my day job to support) programs and policies that financially assist others in FOSS to attend such events.

When I travel, Delta Airlines often works out to be the best option for my travel: they have many international flights from my home airport (PDX), including a daily one to AMS in Europe - and since many FOSS events are in Europe, this has worked out well.

Admittedly, most for-profit companies that I patronize regularly engage in some activity that I find abhorrent. One of the biggest challenges of modern middle-class life in an industrialized soceity is figuring out (absent becoming a Thoreau-inspired recluse) how to navigate one's comfort level with patronizing companies that engage in bad behaviors. We all have to pick our own boycotts and what vendors we're going to avoid.

I realize that all the commercial airlines are some of the worst environmental polluters in the world. I realize that they all hire union-busting law firms to help them mistreat their workers. But, Delta Airlines recent PR campaign to frighten their workers about unions was one dirty trick too far.

I know unions can be inconvenient for organizational leadership; I actually have been a manager of a workforce who unionized while I was an executive. I personally negotiated that union contract with staff. The process is admittedly annoying and complicated. But I fundamentally believe it's deeply necessary, because workers' rights to collectively organize and negotiate with their employers is a cornerstone of equality - not just in the USA but around the entire world.

Furthermore, the Delta posters are particularly offensive because they reach into the basest problematic instinct in humans that often becomes our downfall: the belief that one's own short-term personal convenience and comfort should be valued higher than the long-term good of our larger communityf. It's that instinct that causes us to litter, or to shun public transit and favor driving a car and/or calling a ride service.

We won't be perfect in our efforts to serve the greater good, and sometimes we're going to selfishly (say) buy a video game system with money that could go to a better cause. What's truly offensive, and downright nefarious here, is that Delta Airlines - surely in full knowledge of the worst parts of some human instincts - attempted to exploit that for their own profit and future ability to oppress their workforce.

As a regular Delta customer (both personally, and through my employer when they reimburse my travel), I had to decide how to respond to this act that's beyond the pale. I've decided on the following steps:

• I've written the following statement via Delta's complaint form:

  I am a Diamond Medallion (since 2016) on Delta, and I've flown more than 975,000 miles on Delta since 2000. I am also a (admittedly small) shareholder in Delta myself (via my retirement savings accounts).

  I realize that it is common practice for your company (and indeed likely every other airline) to negotiate hard with unions to get the best deal for your company and its shareholders. However, taking the step to launch what appears to be a well-funded and planned PR campaign to convince your workers to reject the union and instead spend union dues funds on frivolous purchases instead is a despicable, nefarious strategy. Your fiduciary duty to your shareholders does not mandate the use of unethical and immoral strategies with your unionizing labor force - only that you negotiate in good faith to get the best deal with them for the company.

  I demand that Delta issue a public apology for the posters. Ideally, such an apology should include a statement by Delta indicating that you believe your workers have the right to unionize and should take seriously the counter-arguments put forward by the union in favor of union dues and each employee should decide for themselves what is right.

  I've already booked my primary travel through the rest of the year, so I cannot easily pivot away from Delta quickly. This gives you some time to do the right thing. If Delta does not apologize publicly for this incident by November 1st, 2019, I plan to begin avoiding Delta as a carrier and will seek a status match on another airline.

  I realize that this complaint email will likely primarily be read by labor, not by management. I thus also encourage you to do two things: (a) I hope you'll share this message, to the extent you are permitted under your employment agreement, with your coworkers. Know that there are Diamond Medallions out here in the Delta system who support your right to unionize. (b) I hope you escalate this matter up to management decision-makers so they know that regular customers are unhappy at their actions.

• Given that I'm already booked on many non-refundable Delta flights in the coming months, I would like to make business-card-sized flyers that say something like: I'm a Delta frequent flyer & I support a unionizing workforce. and maybe on the other side: Delta should apologize for the posters. It would be great if these had some good graphics or otherwise be eye-catching in some way. The idea would be to give them out to travelers and leave them in seat pockets on flights for others to find. If anyone is interested in this project and would like to help, email me - I have no graphic design skills and would appreciate help.
• I'm encouraging everyone to visit Delta's complaint form and complain about this. If you've flown Delta before with a frequent flyer account, make sure you're logged into that account when you fill out the form - I know from experience their system prioritizes how seriously they take the complaint based on your past travel.
• I plan to keep my DAL stock shares until the next annual meeting, and (schedule-permitting), I plan to attend the annual meeting and attempt to speak about the issue (or at least give out the aforementioned business cards there). I'll also look in to whether shareholders can attend earnings calls to ask questions, so maybe I can do something of this nature before the next annual meeting.

Overall, there is one positive outcome of this for me personally: I am renewed in my appreciation for having spent most of my career working for charities. Charities in the software freedom community have our problems, but nearly everyone I've worked with at software freedom charities (including management) have always been staunchly pro-union. Workers have a right to negotiate on equal terms with their employers and be treated as equals to come to equitable arrangements about working conditions and workplace issues. Unions aren't perfect, but they are the only way to effectively do that when a workforce is larger than a few people.

10 May 2019 9:52pm GMT

Pitivi 1.0 is scheduled to be released on Monday, May 20th. All the important bugs we were aware of have been fixed.

To fix one of the last issues, Thibault very recently rewrote the timeline/layers/clips management in GES, and this might have introduced new bugs. While we have lots of tests which all pass, they don't cover everything.

We ask you to test the 1.0 RC! Grab a bunch of video files shot with your phone or camera and make some video out of them, trying various features. Tell us if you notice problems, and if you can reproduce them please file an issue describing the steps to reproduce the bug.

You can find us in the #pitivi IRC channel on FreeNode, or in this bridged Pitivi Matrix room.

How to install

To install the Pitivi 1.0 RC, simply run:

flatpak install http://flatpak.pitivi.org/pitivi.flatpakref

If there are conflicts, you can uninstall the conflicting installation.

How to test

Start Pitivi from the console, and keep it in view to notice any warnings or errors which might show up:

flatpak run org.pitivi.Pitivi//stable

You should be able to use any video file supported by GStreamer, but we officially support only a limited set of formats. If the file appears in the media library with a warning sign, right-click it and select proxy to create an optimized media file used automatically instead of the original.

Most useful would be to test the timeline editing, which should be responsive and precise. Try for example splitting and trimming clips, moving them around. Try ungrouping audio-video clips to make the respective video shorter than the audio. Overlap clips to create cross-fade transitions.

If time allows, you can also try adding effects, for example adding a background to a green screen. Mix diverse footage formats in the same timeline. Make a slideshow and include title clips and background music.

For reference, see the user manual. At the end, please render it and show us what you did!

10 May 2019 7:08am GMT

I've been working in the GNOME community for a little under a year and a half now. During my time contributing to the project, I've seen a lot of misunderstandings from the community about how we work. So, I've decided to write a multi-part series on how development on GNOME works.

This first post will cover the basics. In future I'll explain our tooling, how apps are created, and how changes happen across the ecosystem.

The Release Cycle

At the center of GNOME development is the release cycle. Every 6 months we put out a major release, with patch releases in-between. Major releases typically happen in September and March, and are named after the city of the most recent conference. GNOME 3.30 was named after the city we held GUADEC in, and 3.32 is named after where GNOME.Asia took place.

At different intervals in the cycle we have freeze periods, after which no changes can be made to certain parts of the code. Core apps, such as Web, Files, and Settings all strictly follow the release cycle and freezes. Apps outside of the core set like Polari, Builder, and Fractal can follow their own schedules or versioning schemes, but tend to put out releases alongside the GNOME core.

The freeze deadlines often determine what contributions make it into a release. For example, if a UI change is submitted after the UI freeze, maintainers need to seek approval from the Design and Release teams before the change can be merged. Freezes are staggered, and come in the following order:

• UI, Feature, and API/ABI Freezes
• String Freeze
• Hard Code Freeze

The hard code freeze ends once the major release for the cycle is out. If you want to apply a change that violates the other freezes, you need to create a branch for the latest stable release. So, if I need to merge a UI change after the 3.32 release is out, I need to first create a gnome-3-32 branch before I accept the change onto master. This branch will then be used to cherry-pick changes for the 3.32.X releases.

How Apps Are Maintained

Each project within GNOME has its own developers. The Music developers aren't necessarily the same people working on the Shell, and the Shell developers generally aren't the same people working on GTK. While many developers work across the ecosystem on different projects, there is no one team of developers. This is why "GNOME decided such and such" is often inaccurate.

The maintainers of a project have full say over what contributions are or are not accepted. While certain things can be proposed, maintainers have the right to reject proposals. This is, for example, is why Terminal did not have a HeaderBar until 3.32 and doesn't enable it by default. Nobody is forced to do anything, but often developers and designers will agree on a direction for an app, or the ecosystem at large.

Contrary to popular belief, most maintainers are not paid by Red Hat although some core components like Files and GNOME Shell do have Red Hat employees employed to work on them. Other companies such as Canonical, Purism, and Endless employ developers to work on the parts of the stack that matter to them. That said, most contributors are not on company time even if they are employed by the likes of Red Hat. And of course those that are employed to work on GNOME still aren't paid for all of their work on GNOME. Most of our work is done on our own time, as limited by the rest of our lives.

It's also worth noting that GNOME is built with a wide range of technologies; while GTK is written exclusively in C, Music is a Python project and Calculator is implemented with Vala. The Python developers working on Music are great with Python and GStreamer, but they aren't going to be much help fixing a rounding error in Calculator as a general rule, and as volunteers it wouldn't be fair to expect them to be, either.

tl;dr: GNOME is a community of individuals each with their own motivations and vision for their own part of the project doing their best to build a great platform for users.

09 May 2019 11:23pm GMT

On the Meson manual crowdfunding page it is mentioned that the end result can not be put under a fully free license. Several people have said that they "don't believe such a law could exist" or words to that effect. This blog post is an attempt to to explain the issue in English as all available text about the case is in Finnish. As a disclaimer: I'm not a lawyer, the following is not legal advice, there is no guarantee, even that any of the information below is factual.

08 May 2019 6:25pm GMT

GDA is the GNOME Data Access library, able you to use GObject like API to access database provides like PostgreSQL, SQLite and MySQL, among others like JDBC, running queries and get data in data models for your application use.

This new release is an effort to fix bugs in 5.2 stable branch, including:

• Fix Sun JRE 1.8 detection
• Fix JDK 11.0 detection
• Drop unneeded JAVAH variable check
• Fix build for System Installed SQLite libs
• Non-Dates and Timestamps values returns 'NULL' string when converted
• Fix -with-ui, now UI is buildable when enable

Expect more fixes as this version is available in LTS distribution versions and current master targeting 6.0 release is getting more and more fixed on memory leaks, than ever.

08 May 2019 3:38pm GMT

This week, we released GTK 3.96.0. Again, it has been a while since the last release, so it is worth summarizing whats new in this release. There is really too much here to cover it all, so this post will only highlight the most important changes.

This release is another milestone on our way towards GTK 4. And while there are still some unfinished things, this release is much closer to we hope to achieve with GTK 4.

GSK

GSK has seen a number of bug fixes and new tests that are made much easier using a new debug tool, gtk4-node-editor. It can load and display serialized render node trees, such as this one that was saved from the GTK inspector, and compare the output of different renderers.

The 3D transformation support has been brought up to the level where we can do animated transitions like the cube spin below.

GDK

The trend to move toward Wayland inspired APIs has continued, with more X11-only apis being moved to the X11 backend or just removed. Use of child surfaces and global coordinates has been greatly reduced, but this work remains incomplete.

The refactoring of Drag-and-Drop has also continued, with the introduction of GdkDrag and GdkDrop objects. The GTK part of this refactoring is still incomplete.

Events have been simplified and are now used just for input. Other event have been replaced by signals and properties on GdkSurface. In detail, expose events have been replaced by the ::render signal, configure events have been replaced by the ::size-changed signal. Map events have been replaced by the :mapped property, and gdk_event_handler_set() has been replaced by the ::event signal.

The Wayland backend has gained support for the Settings portal for GtkSettings, and uses the text-input-unstable-v3 protocol for its input method support.

GTK

Widgets

One big change for custom widgets is the introduction of GtkLayoutManager, which is a new delegate object that takes over size allocation. Layout managers can optionally use layout children for holding layout properties. This replaces the layout-related child properties in GTK containers such as GtkBox or GtkGrid.

A number of layout managers are available:

• GtkBinLayout, for simple single-child containers
• GtkBoxLayout, for children that are arranged linearly
• GtkGridLayout, for children that are arranged in a grid
• GtkFixedLayout, for freely positioned and transformed children
• GtkCustomLayout, as a quick way to turn traditional measure and size_allocate vfuncs into a layout manager

More layout manager implementations will appear in the future. Most prominently, work is underway on a constraints-based layout manager.

GtkAssistant, GtkStack and GtkNotebook have publicly
accessible page objects for their children. The page objects
are also exposed via a list model. They non-layout related child properties of these containers have been converted into regular properties on these page objects.

Since all existing child properties have been converted to regular properties, moved to layout properties or moved to such page objects, support for child properties has been dropped from GtkContainer.

The core GtkEntry functionality has been moved into a new GtkText widget, which also implements an expanded GtkEditable interface. All existing entry subclasses in GTK have been turned into GtkEditable implementations wrapping a GtkText widget. This also includes a new GtkPasswordEntry.

Other Changes

GTK widgets can transform their children using projective linear
transformations. This functionality is available in CSS and
as a GskTransform argument to gtk_widget_allocate. GtkFixed is
the first container that exposes this functionality. For further examples,
see the swing transition of GtkRevealer, the rotate transitions
of GtkStack or the Fixed Layout example in gtk4-demo.

A number of list models have been introduced, for internal use
and as public API: GtkMapListModel, GtkSliceListModel, GtkSortListModel, GtkSelectionModel, GtkSingleSelection. These will become more widely used when we introduce a list model-based GtkListView.

GtkBuilder can specify object-valued properties inline, instead of referring to them by ID, and the simplify command of gtk4-builder-tool has gained an option to automatically convert GTK 3 UI definition files to GTK 4.

Coming soon

For more information on the things that are still still coming for GTK 4, find us on Discourse, IRC, or look here.

08 May 2019 4:21am GMT

Using a computer is mostly about executing apps, reading, writing and doing. But it can also be about not doing.

Confusing? Bear with me.

Imagine for a second that you are in an elementary school. The leadership is optimistic on exposing students to technology. They have set up big rooms with rows and rows of computers ready for their students to use.

Would you give complete permissions to these teenagers using the computers? Would you allow them to install and uninstall programs as they wish, access any website they feel like, use for as much time they want?

An elementary question

This is an intriguing situation to think about. At the same time that we want to restrict what the user can do - in this case, the student - we still want them to be able to get stuff done.

Thanks to Cassidy Blaede from the elementary OS team, this school-wants-to-limit-students situation was brought to the roundtable during the Parental Controls & Metered Data hackfest that happened during the second half of April.

The event itself was extensively covered already by Cassidy, and by Philip's and Iain's daily reports, and that is not going to be the focus of this article. I'm personally more interested in the design and technological aspects of what was discussed.

Apps or not apps

Naturally, when talking about user restriction, apps are probably the very first aspect of it that comes to our minds. Followed by browsers.

There is not a lot of controversy to the idea of assuming that administrators are likely to be the "supervisors", and users without administrator privilages are the "supervised".

At first, the use case we thought we were dealing was mostly about guardians or parents restricting what kind of contents, applications, or websites their kids would be able to access.

This is natural on systems that are heavily app-based. Smartphones have interesting implementations that are not only sane, but also technically feasible. But the traditional way of distributing apps via distro packages, and executing them without restrictions, makes that task incredibly hard, impossible dare I say. Unfortunately, the Linux desktop in general is not quite there yet.

Flatpak to the rescue!

Implementing app restrictions generically may be close to impossible on the traditional desktop, but it is actually very much feasible on newer technologies such as Flatpak.

If you have an OSTree-based immutable filesystem where all user-managed apps are installed via Flatpak, such as Endless OS or SilverBlue, app restrictions suddenly becomes even more realistic.

In fact, we at Endless have implemented something like that already, even if a bit rudimentary.

Endless OS implementation of app restrictions

For the purpose of continuing the hackfest discussions, Allan managed to do a quick sketch about it:

Disclaimer: this is nowhere near being final.

An interesting aspect of the mockups is the "Supervisor Password"; a password that does not give full root permissions, and yet allows whoever is managing the system to assume the role of supervisor. Think of a teacher, without the administrator password, but still able to supervise students' accounts.

But browsers…

Restricting websites, however, is remarkably tricky to accomplish. It is essentially impossible to whitelist websites, at least when implenting it outside the browsers themselves. In general, blacklisting is easier(ish) than whitelisting because we don't have to deal with the case of websites accessing contents outside their domains.

I'm pretty sure this is a reasonably studied field though, and I simply lack the pre-existing knowledge.

What about me?

While discussing those aspects of restricting users, it quickly became clear that applying restrictions on yourself is perfectly valid. It is actually branded as "Digital Wellbeing" and similar on various mobile OSes.

Those who work in front of computers and have more control over their schedule will appreciate being able to restrict themselves and improve their health, focus, and productivity.

More mockups (and again, quick sketches, not final)

It is also interesting to see per-app usage:

It is not clear yet how a potential new Focus mode would interact with notifications.

Metrics

You might notice that those mockups require some sort of a metrics system that would monitor which app the user is using. This could range from a simple event logger to a sophisticated daemon collecting much more. Nothing is settled in this front, no decision was made yet.

Of course, privacy concerns were taken into account. There is absolutely no room for sharing this data. All data would be stored locally.

My attendance to the Parental Controls & Metered Data hackfest was proudly sponsored by the GNOME Foundation.

07 May 2019 2:37am GMT