Branches and code hosting

Can you check as well that build/communitheme/gnome-shell.css is updated after your second ninja install?

Comfirm, same files

$  ll  /usr/share/gnome-shell/theme/ubuntu-communitheme/gnome-shell.css
-rw-r--r-- 1 root root 47294 nov 27 14:44 /usr/share/gnome-shell/theme/ubuntu-communitheme/gnome-shell.css

$  ll build/communitheme/gnome-shell.css 
-rw-r--r-- 1 root root 47294 nov 27 14:44 build/communitheme/gnome-shell.css

I created the repo for the gtk2/3 side of the theme here:

The build system and local install should work, but you have to manually switch to the theme using gnome tweaks. @didrocks, how do I configure the session so that the communitheme is chosen by default? I can’t seem to find how this is done for Ambiance. Or will this only happen when we get a .deb installer?

Afaik, these are the following tasks for me, did I miss something?

  1. Fix session
  2. Add repo for icon theme (a snapshot of Matthieu’s repo per his wishes) + build system
  3. Add packaging for gtk and icon theme
  4. Create ppa
  5. Create auto-merge script

@didrocks, some more questions:

  • Why do the Ubuntu packages have a different build system than upstream? Upstream already uses Meson, the Ubuntu version uses Makefiles. Should we eventually try to move to the upstream build system?
  • For GTK2; I currently haven’t added a theme engine, so it should default back to the Adwaita theme engine. Do we want to modify the theme engine too, or should we just not bother? (Any idea how common gtk2 apps are?)
1 Like

I tried @didrocks’ instructions on Ubuntu 17.10, and these seem to work, the calendar indeed changes to red.


However, the theme is still Ambiance because the session isn’t linked to the GTK3 part yet:


Thanks @merlijn-sebrechts, I wasn’t looking at calendar in the top bar, but at the calendar application. Now it is working.
Thanks @didrocks as well :+1:

@c-lobrano: nice that you figured it out! Indeed, the branch is only for GNOME Shell + the additional session. @merlijn-sebrechts is working on the GTK one, which will impact the calendar application :slight_smile:

@merlijn-sebrechts: nice work and thanks for testing as well! Please find below my answers… :wink:

It will only happen when the session deb is installed (if you never changed your theme, same principle than for vanilla session). Look at the override files in debian/. Indeed, it makes sense to have something integrated distro-wide. However, when working on a project and iterate over it (using upstream build system), you don’t want to set things by default. This is why I didn’t ship the override file in the upstream build system.

So, not needed.

I’ll do it (in January, as I won’t be around in December) if you don’t mind, I have a clear understanding of this.

Why a snapshot? Shouldn’t we move the upstream branch directly rather than fork? I thought on that project we won’t import/copy anything and just reuse the git directly.

I think if you can add to your task list an easy way to create packages for PR as well, so that the designers can try easily without building the branch before merging, that would be sweet! (and attach/report the package artefacts as part of the PR). This is some interesting CI work IMHO :slight_smile: (using Travis to build packages, pubish the artefacts and using github API).
What do you think?

Debian packages is always a Makefile in debian/rules. This is integrated with debhelper, which itself call the upstream meson build system (and do all the packaging magic, stripping and producing debug artefacts + helpers). Nothing to change here :slight_smile:

I think we should aim to get a theme engine for GTK2 apps, to be on par with our current Ambiance theme, having a GTK2 theme engine. It’s clearly less a priority than for GTK3.

As a reference:

$ reverse-depends libgtk2.0-0 | wc -l

So, quite a lot, even if all those are not applications :slight_smile:


Matthieu says that he prefers us to fork and use him as an upstream: However, the “snapshot” will of course be a fork of his repo with the history etc. attached.

Good idea, I’ll take a look at it.

Slightly related: how will the connection between Github and launchpad happen? Do we need a separate build pipeline in launchpad for the Ubuntu packages?

I find that a little bit odd, any particular reason for this? At worse, we can have a different branch adding packaging, but a different repo seems like extra effort to get things resynced on and such…

You will need to dig into the launchpad API. But I think for PR, it will be easier to build the package in Travis CI and publish it that way, getting launchpad out of the loop as it’s hard to create ppa on demand, removing them, and such…

Hey @godlyranchdressing, @c-lobrano, @Merk42, @isantop and @merlijn-sebrechts

I hope you guys are doing good!

How is your status on the theme?
You already created a GitHub project, for now, I have some questions:

  • Do we start from scratch (guess Gnome shell base) or from the Ubuntu Ambiance theme to not have to redo everything they have done to make the Dock work and so on?
  • Are you able to implement and adjust/design the Ubuntu Dock?
  • Are the icons already implemented?
  • I was testing a few changes on the original theme in a 17.10 VM because it is much better to see it in a working system. I could adjust a few things like the top-panel and fonts and the dock, but I just could not find where to adjust the window panel colors and the window panel inner box-shadows. Maybe you can give me a hint to help with my tests.

So thanks, I like to kick off at least some testing and basic work because there is not too much time until April and I guess we all wanna see 18.04 in a new style :slight_smile:

And a screenshot of my testing in the VM (looks better and darker in real life!):

  • Top panel and Dock in 37 35 35 0.8 like here and 0.9 when window is docking (smooth 1000ms transit)
  • Top panel box-shadow black 0.4 0px 2px 3px 0px
  • Font Ubuntu Regular weight 500, not bold anymore, no shadow
  • No icon shadows
  • Dock also with box-shadow and also inner box-shadow to nicely separate the top-panel from the Dock and so if necessary deactivate the top-panel shadow when max window.
  • The Dock will need more adjustment when icons are implemented… icons too big, more space for the orange dot, no round corners for the layer on the active window

Screenshot (20)

Thanks, Stefan


I’ve made some changes to the GTK3 theme, but nothing major, really. Just things that have been finalized (transparent dark headerbar that becomes opaque when a window is maximized, more traditional tabs etc.)

We’re working with Adwaita as the base for both the Shell and GTK2/3 themes.

There are some things that I’ve noticed seem hardcoded (like the color of the dots) but it looks like everything else can be styled like normal (except for the default icon size for the dock). We might just need to fork the Ubuntu Dock and then merge in whatever changes when the theme becomes final, but this would mainly be limited to the CSS.

For regular windows?

1 Like

We start from the Adwaita theme (upstream Gnome default). This will allow us to easily “sync” the communitheme with the upstream Adwaita theme. So when Gnome devs change an API, fix a bug or add a new feature, we just use their code to update the communitheme.

We don’t have a downstream repo yet, but you can easily install the icons from the upstream project:

For clarification, there are two themes: the gnome shell theme (top bar, dock, calendar widget etc…) and the GTK theme (windows, buttons, lists…). The GTK theme itself has two variants: gtk2 (for compatibility with older apps) gtk3 for most apps like the file manager.


1 Like

I don’t see your changes in the github repo. Have you pushed them?

Not yet. I’ll push them later after I update a couple things.

1 Like

Actually I didn’t know myself how to organize my work while designers are working on the proposals, so thank you for starting this discussion :slight_smile:
I tackled the GTK theme so far, starting from adwaita, trying to reproduce the proposals that I liked the most, but just as warm up, since I just started in developing gtk themes.


I see, but where is the GTK theme - because I tried to make changes to usr/share/themes/Ambiance (Ambiance is activated) and nothing is happening. This was quite easy for testing with the gnome-shell folder - I have a copy on the desktop and then I copy it back to usr/share/ and reload via terminal Alt+F2 “restart” and I see the changes.

I thought the usr/share/themes/Ambiance folder must be the right one, because there are also the window close/max/min icons… but noooo :frowning:

I just pushed my changes and committed a pull request. Would the ppa be coming soon? It’ll make testing easier.

I think the easiest option would probably be installing the communitheme. GTK, GNOME Shell. You can git pull whatever progress we make and edit as you like. The GTK stuff is in /usr/share/themes/Communitheme and the Shell stuff is in /usr/share/gnome-shell/theme/ubuntu-communitheme

Right now both themes are just plain Adwaita though, since the changes I made haven’t been merged yet.

So, icons are working, also the theme, but I think the shell stuff is not (not using the included icons for window close/max/min for example).
I’m new to git, but I cloned it and then I copied the folder communitheme into usr/share/gnome-shell/theme/ubuntu-communitheme like you said.
But maybe this is because I already made some changes because the top-panel is still like I configured it… maybe I need to reinstall Ubuntu

Edit: Or maybe because there are scss files instead of css…

1 Like

I was too, don’t worry, it’s super easy. Copying won’t work, you can run these commands to install the themes in the right place.


git clone 
cd gnome-shell-communitheme
meson build --prefix=/usr
cd build
sudo ninja install


git clone
cd gtk-communitheme
meson build --prefix=/usr
cd build
sudo ninja install

Now everything should be in place. The GTK2 and GTK3 files go into

And the shell files go into

You can edit the gtk.css and gnome-shell.css files that are in those folders, or you can edit the SCSS files inside the folder you cloned from GitHub. SCSS is simple enough to get the hang of if you already know CSS. You can go through this tutorial to learn more. After making your edits in the SCSS files, you can run sudo ninja install in the gnome-shell-communitheme/build folder for the Shell or the gtk-communitheme/build folder for GTK3/GTK2. That’ll do all the compiling and moving, then it’s just to Alt + F2 + r to see your changes.

To do some quick testing you can also use the GTK Inspector. To install it you can run sudo apt install libgtk-3-dev in a terminal and then gsettings set org.gtk.Settings.Debug enable-inspector-keybinding true to enable the shortcut to open it. Then you can open any program GTK3 program and press CTRL + Shift + D to bring up the inspector.

The most useful program to use with the inspector is the widget factory though. Which shows you basically every widget. Run sudo apt install gtk-3-examples, then run gtk3-widget-factory That will open the widget factory, then you can open the inspector with CTRL + Shift + D again.

Click the upper-left target button to select an object.

Screenshot from 2017-12-07 14-26-49

Select something like a button and you’ll see the following.

Screenshot from 2017-12-07 14-26-59

We don’t really care too much about that stuff so just click the dropdown button with “Miscellaneous” and select CSS nodes. Which shows you:

Screenshot from 2017-12-07 14-27-08

The element you selected will be highlighted within a list of all elements in the window. In the left pane you can see the name of the widget you clicked on (button) and its different CSS classes (.text-button .toggle). The right pane shows all the element’s CSS properties and values and where to find it in the gtk.css file.

Clicking the CSS tab will take you to a text entry window where you can type in CSS that will be applied.
Screenshot from 2017-12-07 14-27-26

Putting button { background-color: red; } will make all buttons have a red background. It’s exactly like the inspect element tool in a web browser.


Wow, thanks a lot for that description!

This is helping me a lot to get a better feeling for what is possible and so on. Still not getting everything like where are the icons or how to address some (not the same like in css I guess) in the inspector and so, but for now, this is great!

Everything seems to work, I guess I will wait for the open pull request to see what’s the actual status. Does @merlijn-sebrechts first have to confirm the pull?

And will the changes from my test already be implemented?

1 Like