That’s my blog… Life and Linux

GNOME Hackfest for Fractional Scaling

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.

 

Ubuntu goes GNOME, theming stays. Let’s test (and tune) it!

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 »

Introducing Locally Integrated Menus to Unity 7

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