Branches and code hosting

This topic is for mostly all developers: @godlyranchdressing, @c-lobrano, @Merk42, @isantop and I think @merlijn-sebrechts volunteered to do the CI/preparation part :slight_smile:

As stated in the original topic, we want to start afresh, from Adwaita for GTK theme and the Shell sass files.
This enables to track better changes, ensuring the whole part of the theming styles and classes are supported (see what happened with suggested-action last cycle when I blogged about it for instance: https://didrocks.fr/2017/10/16/ubuntu-gnome-shell-in-artful-day-15/)

  • Question number 0 (as not really a question): I think, as I saw you mostly all have github accounts and seem to be familiar with it that we use git :slight_smile: Please shout if you have any issue with it.
  • First question: Where do you prefer the code to be hosted? We can use https://github.com/ubuntu/ to get better visibility and external contributions or we can use launchpad.
  • Second question: I think it makes sense to have 3 projects: one for GTK2/3, one for the Shell and one for the icon set (which, for this latter, may just be Sam’s branch icon).

While you are answering those questions, @merlijn-sebrechts, do you mind preparing those branches (I think start with GTK theme, and then the Shell), make a build system around it (I suggest meson/ninja combo, as it’s what more and more upstream are using) and propose something for importing regularly the SASS files from the ubuntu packages to the branch?
I think we need to do a 3-way merge so that we can compare: old-upstream-sass/new-upstream-sass and old-upstream-sass/our-ubuntu-changes.
For instance, then, with meld, we can do: meld <old-upstream-version.scss> <new-upstream-version.scss> <ubuntu-modified-version.scss>. New changes are visible between the 2 first columns and can be injected and adapted appropriately into the 3rd.
I think a tool automating this to get the manual 3 way merged process would be great. The thing is that it’s not only one but multiple files that needs to be reviewed when this tool is ran. Then, the merges are manual and it will get via a normal PR proposed against master.
One last thing: it needs to import the scss version from the distribution itself, and not upstream repository. Indeed, we may have a version of GTK or Shell different than upstream, and so, it’s better to be in sync with the distro than anything else. Providing a manual path for new upstream version (like merging before upload a new version of the Shell having a theme breakage) would be sweet as well.

I’m happy to help if things are unclear and do the first merges ofc :wink:

Sounds good to everyone?

First question: Where do you prefer the code to be hosted? We can use https://github.com/ubuntu/ to get better visibility and external contributions or we can use launchpad.

My vote goes to Github. I agree that is gives us better visibility and encourages external contributions.

While you are answering those questions, @merlijn-sebrechts, do you mind preparing those branches (I think start with GTK theme, and then the Shell), make a build system around it (I suggest meson/ninja combo, as it’s what more and more upstream are using) and propose something for importing regularly the SASS files from the ubuntu packages to the branch?

I’ll start hacking at it this evening, I’ll keep you guys updated in this thread.

4 Likes

I also agree on GitHub, it has what we need and it’s mostly set up already, and with the project organization. I will start asap to play with Adwaita :slight_smile:

+1 for Github. Browsing git code on launchpad can be a bit more obtuse than there.

3 Likes

@didrocks, I’m a bit lost as to which sources we need to base on exactly. The Gnome upstreams are clear, but Launchpad is just such a maze…

Heh, no worry, I know it can be complex at first :slight_smile:

I started with explaining how the packages are layed out in launchpad, before realizing that was too complex for this project. Let’s start simple and easy. I asked to get the 3 desired projects to be imported automatically in our beta git package repo…
You have right now: https://code.launchpad.net/~usd-import-team/ubuntu/+source/gnome-themes-standard/+git/gnome-themes-standard for instance. This is the whole upstream/debian/ubuntu imports of every commits and package version for this project.
Similarly, for GNOME Shell: https://code.launchpad.net/~usd-import-team/ubuntu/+source/gnome-shell/+git/gnome-shell/+ref/ubuntu/bionic-devel
The GTK+3.0 import is under way. It will be available at https://code.launchpad.net/~usd-import-team/ubuntu/+source/gtk+3.0/+git/gtk+3.0/ once imported :slight_smile:

After giving it some thoughts (this is why I didn’t answer on it right away), I think the tool shouldn’t bother with a git repo or anything and go simple (maybe later, it can warn if there is a new version available during package build, but let’s be practical). I would just import whatever is new given a directory. It will import this directory and the subdirectory contents.
The fact to only import directories enable as well, doing let’s say a new GNOME Shell release (not uploaded yet) adding new CSS properties, to prepare the theme at the same time before it’s pushed to ubuntu, so that both can be tested on developer’s machine.

If I may suggest a layout for the 3 way merge diff:

  • The tool would take a directory which is the “new version”
  • We have stored the old upstream unpatched version in an upstream/ directory in the repo
  • Then, it will make the diff, file by file between the new version, the upstream/ directory content, noticing files added, files removed, files changed (let people choose their own diff tool). We use the 3 way merge diff as stated above. This is where when the developer update the new theme based on the changes he sees.
  • Then, the upstream directory is rm and the input directory is copied over and git add over the new upstream/ directory.

That enables to keep the current “upstream” version around for future updates and updating our theme knowing what upstream has changed.

Does it make sense? I suggest if you haven’t already that you play with meld with those 3 files on the command I gave previously so that you can get a feeling on what it’s like, that will even maybe trigger new and better ideas!

Of course, the build system will completeliy ignore the upstream/ directory from the repo, it’s just here for reference.

I think the easiest may be to start with GNOME Shell itself, imagining we import the data/theme directory: https://git.launchpad.net/~usd-import-team/ubuntu/+source/gnome-shell/tree/data/theme?h=ubuntu/bionic-devel.
I has of course some files you need to ignore like the meson.build one and the generated gnome-shell*.css ones corresponding to gnome-shell*.scss source. But is has assets we want to copy (and modify) like the svg, and of course, the sass files in the subdirectory gnome-shell-sass/.

Keep me posted if you need any help!

@merlijn-sebrechts: do you get anything working, do you need any help?

I think getting the branch ready (at least one of them, like GNOME Shell) will get us a little bit further so that everyone can start getting familiar with the project. If you feel block, do not hesitate and I can bootstrap a first branch to get things cracking :wink:

Sorry, I haven’t had time to look at it again. Your proposal makes sense, though. I’m thinking maybe submodules can help here, we could make the upstream folder a submodule that points to the latest merged upstream, and maybe use git to setup the three-way-merge? I’ll first set it up with a simple directory to get a feel of it.

PS: and I am interested in how the packages are laid out in Launchpad, if you ever get to writing that down somewhere… :slight_smile:

@didrocks, I think it’s best if you bootstrap a first branch, this will take me a while to get familiar with, and I don’t want to be blocking the team. :slightly_smiling_face:

And here we go! https://github.com/ubuntu/gnome-shell-communitheme.
It uses meson, and have instructions on how to use it, providing a dedicated session for people to use. I also made an initial packaging, changing the GDM theming as well.

Right now, the content is just upstream GNOME Shell with Adwaita, but with ubuntu enabled extensions (dock and appindicator + patches).

I didn’t build the 3-way merge rebasing system yet, but that’s not important until we rebase to newer GNOME Shell and won’t be used by everyone :slight_smile:

Give me your github handle so that I can give you write access to that branch.

@merlijn-sebrechts: is that ok for you to start building CI, like providing a ppa with automated builds, maybe even building custom branches in PR? Also, I hope this is a good base for you to do the GTK and suru icon branches :wink:

3 Likes

Awesome! I’m galgalesh on github.

Team created with correct right on the single branch (for now ;)) and invited you!

1 Like

Hi @didrocks,

I tried the “how to” in HACKING file, but I couldn’t make it work, I guess I’m doing something wrong.

This is what I did:
1. meson build and ninja install: this should be OK, since later I found communitheme session at login
2. made a simple change (button hover’s color from white to green in communitheme/gnome-shell-sass/_drawing.scss) just to test the workflow
3. again in <project-dir>/build run sudo ninja install (some file have been actually re-generated)
4. refreshed theme ALT-F2, rt, enter, but nothing changed

Hey @c-lobrano I just gave it a retry and this works for me. After your sudo ninja install, can you check that /usr/share/gnome-shell/theme/ubuntu-communitheme/gnome-shell.css is indeed regenerated?

Here is a simple example I made:

  1. after a first sudo ninja install, going to the communitheme session, getting upstream GNOME Shell look with Ambiance GTK theme (if you installed the package, you will get Adwaita theme until the community GTK theme exists).
  2. then I changed communitheme/gnome-shell-sass/_colors.scss from:
    -$bg_color: if($variant ==‘light’, #ededed, #393f3f);
    +$bg_color: if($variant ==‘light’, #ededed, red);
  3. in the build directory, sudo ninja install, Alt-F2, rt, enter, and clicking on the calendar for instance bring a magnifiscent red background to any popup menu :wink:

Does this work for you? (Also, mind confirming your github account so that I can share access with you in the branch?
I’m pushing a couple of additional explanations for changing the GDM theme as well manually, when not installing the package.

Hey @didrocks

Also, mind confirming your github account so that I can share access with you in the branch?

Sorry, I though it was only for @merlijn-sebrechts. My github account is clobrano :wink:

Back to the problem, I should have mentioned that I couldn’t install the package from repository (even after apt update)

sudo apt install ubuntu-communitheme-session
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package ubuntu-communitheme-session

and, probably because of that, I cannot have the upstream GNOME Shell look selecting Ambiance Theme

Indeed, there is no ppa yet (wanting on @merlijn-sebrechts to do that part of the automation as he volunteered).
However, the local ninja install is enough even without the package, once you are in the correct session and do refresh, are you sure you selected the correct one?

on Github: invited!

@didrocks

Some questions

Indeed, there is no ppa yet (wanting on @merlijn-sebrechts to do that part of the automation as he volunteered).

So I got this one right at least :smiley:

However, the local ninja install is enough even without the package, once you are in the correct session and do refresh, are you sure you selected the correct one?

No luck with that. I’m sure I selected the correct session, and $DESKTOP_SESSION seems correct

echo $DESKTOP_SESSION 
ubuntu-communitheme

however from gnome-tweaks Ambiance theme is still the ubuntu one

Moreover I just tried the simple change you suggested; gnome-shell.css has been updated (see date and time)

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

but calendar’s popups are still grey

Done for the team :slight_smile:

Ok, let’s do it more easily, on your 17.10 system:

  1. enable source repository, either directly on sources.list or via the upgrade manager.
  2. apt update
  3. apt source <source_package_name> (the 2 for GTK2 adwaita theme and GTK3 ones we mentioned before)
    -> this will get your the source of the current package in ubuntu, with our distro patches attached. You can copy the theme directory content to upstream/.

Sounds good to me!

I’m a little bit puzzled that it doesn’t work for you, as you have the correct session variable and it’s telling you that the css is installed at the correct place, you clearly used --prefix=/usr. The theme being Ambiance it’s normal: contrary to the package (which you can build from that branch, but it’s more involved), there is no override and the GTK current theme needs to be set manually once available. Can someone else try those instructions to double confirm? Can you check as well that build/communitheme/gnome-shell.css is updated after your second ninja install?