@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
@merlijn-sebrechts: nice work and thanks for testing as well! Please find below my answers…
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 (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
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
1003
So, quite a lot, even if all those are not applications