I am happy to announce that yesterday Polari joined the Gitlab pilot project. This means that if you encounter any issue that has not been reported yet, it should now be reported in GNOME’s gitlab instance.
Happy hacking!
I am happy to announce that yesterday Polari joined the Gitlab pilot project. This means that if you encounter any issue that has not been reported yet, it should now be reported in GNOME’s gitlab instance.
Happy hacking!
If you have updated to the recently released GNOME development version, you may have noticed that some window decorations look slightly different. Of course it is quite normal for the theme to evolve with the rest of GNOME, but in this case the visual changes are actually the result of some bigger changes under the hood which deserve some more explanation.
It is well-known that GTK+ gained support for client-side decorations a while ago – after all, most GNOME applications were quick in adopting custom titlebars, which have become one of the most distinguished patterns of GNOME 3 applications. However it is less well-known that client-side decorations may also be used for windows with no custom decorations, namely when using GDK’s wayland backend.
Why is this interesting?
It isn’t really. Whether the non-customized decorations are provided by the window manager or by the toolkit is transparent to the application, and there is no reason why users should care either.
Except that on GNOME 3.14, decorations looked like this:
Ouch. There is an all-too-obvious visual difference for something that should be an implementation detail, and the possibility of users encountering both styles in the same session doesn’t help either.
Of course it would be easy to just blame the GNOME design team – after all, while the metacity-1 theme format used by the window manager is hugely different from CSS as used by GTK+, it would still be possible to create a more consistent look from the lowest common denominator of both formats. But if the goal is to have both types of decorations match as closely as possible, using different themes and expecting an already overworked team to put additional work into papering over the differences is hardly the best solution.
Did I mention that the metacity-1 format is also plainly unpleasant?
So from GNOME 3.16 on, the window manager theme will be gone. Instead, window manager decorations will use the same theme information GTK+ uses for its client-side decorations. As you would expect, both types of decorations now look much more consistent as a result:
Besides the improved consistency, using a single theme has some additional benefits:
Now it would be dishonest to pretend that there aren’t any downsides – the metacity theme has been around a decade longer than GTK+’s client-side decorations, so it is hardly surprising that there is a greater selection of the former around. And support for window-decorations in 3rd party GTK+ themes is often dodgy, if it exists at all. However with more and more GNOME applications using custom titlebars and the upcoming transition to wayland, it does not get easier to ignore GTK+’s decorations – some broken decorations may be better than all broken decorations, but the correct way forward is of course to fix GTK+ themes. It’s CSS after all, which is much more familiar to most artists than the old format, and quite a bit nicer as well, so here’s hoping that the situation will improve rapidly.
In the meantime, let those of us who stay with the default theme enjoy some nicer-looking decorations for all windows …
Some of you may already know: it has been roughly a week since metacity/mutter switched to GSettings. The fallout has been quite small, so this seems like a good time to sum up the changes which may be of wider interest:
So that’s it for today – if you encounter any issues not mentioned above, feel free to file bugs.
(Hopefully my next blog post will be a bit more interesting …)
deswejen fahr ick nächstens wieder hin
Also I’m probably expected to mention my joint talk with Jakub, though I feel slightly bad that he does not appear anywhere in the announcement. But then, maybe it’s him who should feel bad for weaseling out of all the paper stuff …
See you there!
I’m Florian Müllner and I’m one of the hundreds who worked on GNOME 3 …
So the weeks of craziness have come to an end – the awesomeness of GNOME 3 is out and the time to celebrate has come.
It is a great achievement, and I am proud and happy to be a part of it and the community which made it happen.
If you have not tried it out yourself yet, do so now. Seriously.
Just be warned – once you’ve fallen for it, there’s no turning back. One of those little details will get at you, and you’ll live happily ever after. What will it be for you? The new System Settings? Streamlined Nautilus? Resident notifications? Chat integration? Topic-based help? The modern and polished theme?
All of those are awesome, but it’s actually a very tiny detail which does it for me:
Each time I find myself forced to use GNOME 2 now, I end up throwing the pointer to the upper left corner, followed by mild irritation and the feeling of something seriously missing. Muscle memory at its best …
Indeed, this is one of the many ways that we’ve made GNOME 3 better.
The relayout has landed, further development will happen on the master branch. All those who switched their build to the overview-relayout branch should update their .jhbuildrc-custom to revert to master.
Thanks for the patience everyone!
Yesterday I finally opened a Bugzilla bug to land the overview-relayout branch, so the review process has now started and hopefully the work will appear on master soon.
Most recent changes have been internal, but as seen above, the overall design has been tweaked a bit (not least thanks to Allan Day‘s input): the large black boxes around the currently selected view are gone, and the controls to add/remove workspaces have been moved to the screen edge (yup, the F–word!) and slide out on hover and during drags. Also the animation when entering or leaving the overview has been modified to only zoom the window previews — addressing a common complaint about the animation being visually expensive (well, or just “too much”), and resulting in the first bug filed explicitly against the overview-relayout branch — woops.
Apart from those tweaks I managed to implement Dash DND, so it is now possible to add / reorder / remove favorites from the dash using DND. The implementation probably still will require some adjustments, but the first reactions have been quite positive, so you might want to give it a try; the impatient can add branches['gnome-shell'] = (None, 'overview-relayout')
to their .jhbuildrc, otherwise stay tuned for those changes coming to a Shell near you soon …
I suppose by now most have seen the mockups Jon presented at GUADEC – a nice visual overhaul with the special jimmac touch™. Just in case you don’t know what I’m talking about, this is the mockup:
Some of you know already that I am busy implementing those mockups – today I finally felt confident enough about it to show it off, so I pushed a public branch. Even though there’s still a lot of work to do (especially with regard to the new DND behavior), it is slowly getting there:
Obviously, the devil is in the detail – not to talk about some gross hacks used – so I wouldn’t expect the branch to land soonish. But there it is, for fellow hackers and ancious users to give it a try …
Jon has been pestering me for quite a while now to start blogging about my work on GNOME Shell – apparently I finally gave in. I guess a short introduction to fellow Gnomies is appropriate before talking about work, so here we go:
My name is Florian Müllner. I was born and raised in the boring plains of Northern Germany. I have been living in Madrid with my boyfriend during the last couple of years. I am older than Paris Hilton, but younger than Perez Hilton. I started hacking on the Shell a little more than a year, and working for Red Hat a little less than a month ago. If you want to bribe me, you can buy me beer.