When we introduced HiDPI support in GNOME a few years ago, we took the simplest possible approach that was feasible to implement with the infrastructure we had available at the time.

Some of the limitations:

• You either get 1:1 or 2:1 scaling, nothing in between
• The cut-off point that is somewhat arbitrarily chosen and you don’t get a say in it
• In multi-monitor systems, all monitors share the same scale

Each of these limitations had technical reasons. For example, doing different scales per-monitor is hard to do as long as you are only using a single, big framebuffer for all of them. And allowing scale factors such as 1.5 leads to difficult questions about how to deal with windows that have a size like 640.5×480.5 pixels.

Over the years, we’ve removed the technical obstacles one-by-one, e.g. introduced per-monitor framebuffers. One of the last obstacles was the display configuration API that mutter exposes to the control-center display panel, which was closely modeled on XRANDR, and not suitable for per-monitor and non-integer scales. In the last cycle, we introduced a new, more suitable monitor configuration API, and the necessary support for it has just landed in the display panel.

With this, all of the hurdles have been cleared away, and we are finally ready to get serious about fractional scaling!

Yes, a hackfest!

Jonas and Marco happen to both be in Taipei in early June, so what better to do than to get together and spend some days hacking on fractional scaling support:

https://wiki.gnome.org/Hackfests/FractionalScaling2017

If you are a compositor developer (or plan on becoming one), or just generally interested in helping with this work, and are in the area, please check out the date and location by following the link. And, yes, this is a bit last-minute, but we still wanted to give others a chance to participate.

With the big push towards 1.0 now over, the development in GNOME recipes has moved to a more relaxed pace. But that doesn’t mean that nothing is happening! In fact, our team is growing, we will have two interns joining us this cycle, Ekta and Paxana.

While we are waiting for Ekta and Paxana to start working on the big projects for this cycle (sharing and unit conversion),  a number of smaller improvements have landed and will hopefully appear in a development release soon.

More recipes

We were somewhat successful in getting recipe contributions from the GNOME community.

Thanks to everybody who has contributed – keep it coming !

One consequence of this success is that we have too much data to ship with the application – the tarball for 1.0 was bigger than 100MB. To avoid this problem growing even further, the current development release downloads all recipe and image data at runtime, when needed. I’m very interested in feedback about how well that works.

More cuisines

Another consequence is that we now have so many cuisines represented that they don’t fit on one page anymore.

To address this, I’ve added an expander to show more cuisines.

Another improvement around cuisines is that we now offer all the cuisines that we know about to the cuisine combo box when you are editing recipes. A small step towards a user interface that adapts to your use of the application.

Inline editing

One of the findings of our testing session with Jakub and Tuomas at devconf was that creating a recipe was too fiddly, in particular the popover-heavy editing of the ingredients list.

To address this, we are moving to an inline editing approach for the ingredients list. To make this easier, I first refactored the ingredients list to be a separate widget which is now shared between the edit page and the details page (in a read-only mode).

Ekta is helping me with this.

Row reordering

Another outcome of our testing session was that we need to let the user reorder the ingredients list, which was not possible back in January. For 1.0, we added buttons to move a row up or down, but that was more of a stop-gap solution.

What we really want is to reorder rows by drag-and-drop,so I spent a bit of time recently to figure out drag-and-drop support for list boxes.

Temperature conversion

Last, but not least, we also added some preliminary support for unit conversion.

For now, we can display temperatures in Celsius or Fahrenheit. Currently, this gets determined by a setting, but as the next step, we are going to pick this up from the locale.

Paxana is working on this, as a warm-up for her internship project.