@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