Treviño's Blog

The fractional scaling era for GNOME shell has finally arrived!

The news spread out quite quickly, once last Friday Jonas pressed the button and that triggered the last-second merge for the relevant proposals we prepared for Mutter and GNOME Shell in order to get this available for GNOME 3.32.

As someone might recall, we started this work some years ago (ouch!) and lead to an Hackfest in Taipei, but in between other work to do and priorities which caused this to be delayed a bit. While the first iteration was ready for some time now. But at every review we improved things fixing bugs (like missing scaled widgets) and optimizing some code paths, so hopefully this time helped in serving better quality :).

We’ve still quite a lot of work to do (see these issues for mutter and shell) and some fixes that we have in queue already, but the main task is there. So starting from now the shell will paint all its elements properly and in good visual quality at any fractional scaled value, and independently for every monitor.

Monitors with different scaling values, and a window drawn in between the two

As you might have noticed in the screenshot above, the X11 apps are still not really scaled in quality, while it’s not possible for them all (like xterm there), we need to work for a solution that will cover the legacy applications which does support scaling, and at the same time those which doesn’t want to be scaled at all (games!).

As per what said above, this feature is still considered experimental and then you need to enable it via:

gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"

Doing this will allow you to set more a wider set of scaling values under Control Center, display panel.

For what concerns Extensions, most of them should work with no change, but not those using directly the St.TextureCache, as we changed the methods signature by adding a resource_scale parameter.
We discussed weather adding another method instead (as gir doesn’t support default values), but since 3.32 will need anyway a rewrite of most extensions anyways, and since it’s better to have them to behave properly with resource scale since the beginning (instead of blurred contents), we decided not to do it.
So, please sync with this change (and sorry :)).

Putting my Ubuntu hat now, this won’t change much things for default ubuntu experience, since it’s still using X11 (although I’ve something in the works for this too), but people who want to take advantage of this can easily just login using the Ubuntu on Wayland session, enable the experimental setting and profit.

As final world, thanks to people who helped having this in by reviewing and testing the code.

Hi Folks,

I’m writing these lines while I’m in the flight to Almeria where this year’s GNOME Users And Developers European Conference will take place, typing with my Thinkpad Bluetooth keyboard on my mobile phone (I’ve to admit that the Android physical keyboard usage is getting awesome, allowing proper WM actions) :), as the battery of my T460p was already over after the flight from Florence to Madrid during which I fixed some more shell JS errors.

This will be my first GUADEC ever, and as a fresh Foundation member, I’m quite excited to finally join it.

I’m not coming alone, of course, as this year the ubuntu-desktop team will be quite crowded, as me, Ken VanDine, Sébastien Bacher, Didier Roche, Iain Lane, James Henstridge and Robert Ancell will be part of the conference, to give input and help to get GNOME even better.

Soo, looking forward to meet you all very soon (almost landed – or better – trying to, in the mean time)!

As always, I’ve to thank Canonical for allowing me and the desktop crew to be part of this great community reunion. But also for being one of the silver sponsors of the event.

These are the events that really matter in order to get things done.

Since some time in both some freenode ubuntu-related and gnome channels, people might have been bothered (or not :)), but the presence of this IRC bot (named ubot5-ng in freenode):

Since people asked, as I’ve set in the /whois, I’m the man behind it, and it’s actually running for some time from a snap inside a cloud instance I manage and hosted by Canonical.

This was just a quick-hack (so take it as it is) I did as I was annoyed by  not to getting the bug infos when linking the the always increasing references to GNOME or Debian projects. The source-code is here, while configuration files (can provide samples if curious) are just enabling the minimum necessary for having this joining the channels and disabling all the other plugins.

However, it currently supports parsing issues and merge proposals for Github and various Gitlab instances (gitlab itself, Freedesktop, GNOME, and Debian Salsa)

Yeah, I know:

• There are other bot options, but I just wanted to hack something quickly
• It should be moved to git, cleaned up removing the unused bugzilla stuff
• Supybot should be replaced with its new fork Limnoria
• I should host the code in a GNOME gitlab project together with the configuration (without the API tokens, of course)
• Jonas asked for colors 😀

I’ll probably do this once I’ve some free time (hard to find, in between my travels), but in the mean time, in case this bothers you, let me know, if instead want it to join other channels, tell me too 🙂

EDIT 31/05: added Freedesktop gitlab too
EDIT 22/08: project code added to gitlab, bot is now named gitbot in freenode

Hey guys, although I’ve been around for a while hidden in the patches, some months ago (already!?!) I did my application to join the GNOME Foundation, and few days after – thanks to some anonymous votes – I got approved :), and thus I’m officially part of the family!

So, thanks again, and sorry for my late “hello” 🙂

As previously announced, few days ago I attended the GNOME Fractional Scaling Hackfest that me and Red Hat‘s Jonas Ådahl organized at the Canonical office in Taipei 101.
Although the location was chosen mostly because it was the one closest to Jonas and near enough to my temporary place, it turned out to be the best we could use, since the huge amount of hardware that was available there, including some 4k monitors and HiDPI laptops.
Being there also allowed another local Caonical employee (Shih-Yuan Lee) to join our efforts!

As this being said I’ve to thank my employer, for allowing me to do this and for sponsoring the event in order to help making GNOME a better desktop for Ubuntu (and not only).

Going deeper into the event (for which we tracked the various more technical items in a WIP journal), it has been a very though week, hard working till late while trying to look for the various edge cases and discovering bugs that the new “logically sized” framebuffer and actors were causing.

In fact, as I’ve already quickly explained, the whole idea is to paint all the screen actors at the maximum scale value across the displays they intersect and then using scaled framebuffers when painting, so that we can redefine the screen coordinates in logical pixels, more than using pixel units. However, since we want to be able to use any sized element scaled at (potentially any) fractional value, we might incur in problems when eventually we go back to the pixel level, where everything is integer-indexed.

We started by defining the work items for the week and setting up some other HiDPI laptops (Dell XPS 15 and XPS 13 mostly) we got from the office with jhbuild, then as you can see we defined some list of things to care about:

• Supporting multiple scaling values: allowing to scale up and down (< 1.0) the interface, not only to well-known value, but providing a wider range of floats we support
• Non-perfect-scaling: covering the cases in which the actor (or the whole monitor) when scaled up/down to a fractional level has not anymore a pixel-friendly size, and thus there are input and outputs issues to handle due to rounding.
• GNOME Shell UI: the shell StWidget‘s need to be drawn at proper resource scaling value, so that when they’re painted they won’t look blurred.
• Toolkit supports: there are some Gtk issues when scaling more than 2x, while Qt has support for Fractional scaling.
• Wayland protocol improvements: related to the point above we might define a way to tell toolkits the actual fractional scaling value, so that they could be scaled at the real value, instead of asking them to scale up to the upper integer scaling level. Also when it comes to games and video players, they should not be scaled up/down at all.
• X11 clients: supporting XWayland clients

Read the rest of this entry »

As Ubuntu users know, Unity desktop shell had HiDPI displays support since 14.04, however while the unity shell has been able to scale at any fractional value (despite we limited the setting to only 8 values per integer), GTK3 and GNOME Shell just supported integer scaling values.

Although I see the technical reason for that (pixels can’t be divided!), I think that our approach still worked quite well by using proper round functions, as it’s really hard to notice the visual flaws that this introduced at such high resolutions.

At the same time, to get proper scaling for GTK apps, we used the stratagem of mixing the UI scaling with the text scaling factor, so that the multiplication between the two values will match the user-requested scaling level.
This worked pretty well in single-monitor instances, while in multi-monitor environments the idea was to use xrandr scaling to get matching results, but this has not been done, mostly due to an X11 bug which didn’t allow to go further…

Anyway, this is the past and present, but let’s talk about the future… Ubuntu will use GNOME Shell (in Wayland, when possible), and so far there’s no support for multi-monitor scaling or fractional scaling, but things are changing!

Jonas Ådahl is leading this efforts and he started with supporting a new configuration API for monitors, that is a prerequisite for pursuing the GNOME Fractional Scaling initiative.
Basically, the main implementation idea is to make GTK and various toolkits to scale at an higher value, and then using mutter to scale actors down at composition level.
While it might be a little more resource intense, it’s also true that this will work nicely (especially in multi-monitor environments with different scaling values) and that there’s no other option, given that GTK scaling system can’t be changed at this point (too many things now assume it’s an integer).

Ubuntu cares about having a proper HiDPI support in next releases, so the Desktop Team decided to join the upstream initiative, and since I’m currently around asia, we’ve organized a GNOME Hackfest, that will be hosted by Canonical in its Taipei office in Taipei 101 in order to continue the work Jonas is doing and plan how to proceed with future work items.

Hi guys! Again… Long time, no see you :-).

As you surely know, in the past weeks Ubuntu took the hard decision of stopping the development of Unity desktop environment, focusing again in shipping GNOME as default DE, and joining the upstream efforts.

While, in a personal note, after more than 6 years of involvement in the Unity development, this is a little heartbreaking, I also think that given the situation this is the right decision, and I’m quite excited to be able to work even closer to the whole opensource community!

Most of the aspects of the future Ubuntu desktop have to be defined yet, and I guess you know that there’s a survey going on I encourage you to participate in order to make your voice count…

One important aspect of this, is the visual appearance, and the Ubuntu Desktop team has decided that the default themes for Ubuntu 17.10 will continue to be the ones you always loved! Right now some work is being done to make sure Ambiance and Radiance look and work good in GNOME Shell.

In the past days I’ve released a  new version of ‘light-themes‘ to fix several theming problems in GNOME Shell.

This is already quite an improvement, but we can’t fix bugs we don’t know about… So this is where you can help make Ubuntu better!

Read the rest of this entry »

Hey Ubuntu folks¹!

This is the Unity desktop team and during the last months we focused, as always, in polishing and improving the user experience of our default window manager for the next upcoming LTS!
In fact, while in the last months most of the Canonical commitment to Ubuntu has been directed to the Touch form factors, the “classic” desktop has not been forgotten at all and, we’re still working hard on it, to give our users the best experience and to approach smoothly to the convergence vision that we’ll get with Unity 8.

Part of this work have been the spread improvements, the HighDPI support, the new decorations and tons of various bugs fixed; however with this important milestone coming we also wanted to finally propose a solution to fix the main UX bug we have in Unity since its very first release: the menus being hard to find or too far from their parent window.

In fact, having the applications menus in the top panel really worked very well in small screens but now, especially with HiDPI monitors getting more and more popular, the top panel could be really too far from the actual window location… The solution, that the UX designer JohnLea has defined are the Locally Integrated Menus (LIM).

Ubuntu Unity Integrated Menus

People might recall that also at 12.04 times we implemented a first prototype of LIM, however due to some very-hard-to-fix issues we had with core applications, we decided not to try to propose an half-working solution for an LTS.

So, almost 2 years have passed, but our intent to get this feature done was still strong, although this time we wanted to implement LIMs in the proper way, as Ubuntu quality standards deserve. In addition designers defined a new and improved revision of their work, proposing to show the menus inside the decorations themselves in horizontal mode (until we’ve room for them); so, continuing to save the precious vertical space and keeping the nice look of menu-less windows unchanged.

To be honest, we’d loved to land this way before, but the amount of technical work needed has not to be underestimated.
Being more precise, one of the blockers we had in 12.04 was our dependency on the legacy compiz decor plugin + gtk-window-decorator, that has worked “OK” in the last years but – a part from using deprecated technologies (gtk2 in primis) – it really would have made this concept impossible to realize.

So, the first step has been moving away from the old gtk2-based decorations and writing brand new decorations supporting Gtk3 CSS theming² inside Unity itself; this has been an huge work (including writing a brand-new widget system for handling compiz textures in a more natural way), but it gave us great benefits in the end such as much faster windows resizing , improved look, support for dynamic scaling (for both HighDPI and accessibility reasons).

Once we had this new layout where to place any widget quite easily, all took shape in few lines, we only had to handle the fact that now menus opens on mouse button release and only if the user doesn’t keep it pressed for too long³, while a slightly trickier part was to handle the case where we had a too small window to show menus in horizontal mode, and where we had to fallback to a dropdown menu.

LIM’s dropdown, shown if we have not enough space

As this is an LTS release, before setting this menu mode as the default we wanted to have some community feedback. For now, you have to enable it using the Unity Control Center Appearance panel, and let us know what you think!

Unity Control Center with Application Menu settings

Tweakers might be happy to know that there are also other settings you can use to adjust your LIM experience under the com.canonical.Unity.IntegratedMenus gsettings schema, that allows to define the pressure and movements thresholds, and to also enable double-click over the menus (to maximize the window, if you’re fast enough); However, while you can adjust the settings for now, we encourage to use the defaults as they are based on wide user testing and are coherent with our design guidelines.

After some words, I guess it’s time to see them in action, and upgrade your Ubuntu Trusty machine to enjoy them!

Youtube Video

[1] Hello Planet, I should also probably say! 😉
[2] We really encourage and support anyone who wants to update its theme to support Unity
[3] Maximum press time is configurable, but default values are based on design user testing