Theme for Gnome applications

snapcraft
1

Please give me advice. The program looks ugly only in the Gnome3.

I found this bug - Graphical snaps don’t follow the window theme

What should I do right now?

My snapcraft.yaml contains

apps:
   myapp:
     command: usr/bin/run.sh
     plugs: [network, x11, home, unity7, gsettings]

parts:
   integration:
    plugin: nil
    stage-packages:
     - locales-all
     - libgdk-pixbuf2.0-0
     - libcanberra-gtk-module
     - libxkbcommon0
     - ttf-ubuntu-font-family
     - dmz-cursor-theme
     - light-themes
     - shared-mime-info
     - libgtk-3-0
     - libglib2.0-bin
     - libgtk-3-bin
    after: [desktop-qt5]
2

@willcooke, @robert.ancell, any progress on the themeing aspect?

3

Hey Gustavo,

That’s a topic that has been covered in other reports already, some pointers to other discussions with some details

https://irclogs.ubuntu.com/2017/06/01/%23snappy.html#t10:31

Basically what we want to do is to have theme-snaps which get their content bind-mounted in the application.

One of the blockers for that work is for snappy to allow us using the content-interface more than once (we already use it to mount the framework snap so we can’t mount a theme snap as well), do you know what’s the status of that feature on the snappy team roadmap/backlog?

4

I don’t think there’s any constraint in terms of using the content interfaces more than once. In terms of the roadmap, since we’re not aware of what is blocking you, there’s of course no way for us to have scheduled anything at this point.

I’ve looked through these discussions, and I don’t really see any limitations on our end as blockers. They all feel like pretty shallow conversations.

@willcooke We need someone to actually dig down and get something working.

5

Indeed, if there are problems using content multiple times, is probably to do either with not using the “content” attribute properly or some bug that should have been fixed since

6

It’s reported there

But indeed it looks like nobody from the snappy team looked at
it/triaged/replied since it has been reported in october so maybe it
just got lost in your untriaged backlog?

7

This isn’t about multiple content interface, but about multiple slots connecting to a single plug. I don’t see how that’s the problem you have?

In either case, we need someone to engage in the problem and address it. It doesn’t feel like we have anyone really interested in solving those issues right now.

8

We need someone to actually dig down and get something working.

(Replying to the wrong message but it seems like the forum list mode is not forwarding all the replies to the list for me…)

In either case, we need someone to engage in the problem and address it. It doesn’t feel like we have anyone /really/ interested in solving those issues right now.

Indeed, and we did engage, in fact and zyga replied/is interested in solving that issue, see https://irclogs.ubuntu.com/2017/06/01/%23snappy.html#t10:24

“zyga yes, I agree zyga and I have some ideas on how to do them already zyga but insufficient time to experiment and prototype”

So I guess we just need to wait a bit for zyga to get enough free slot to do that work!

1 Like
9

No, @zyga-snapd has dozens of things to care about and cannot look into this. Also, it’s not even clear what “this” is.

We need someone that wants to get themes working to dig in and fix the problem. The content interface should work just fine with multiple plugs and a single slot, which is the case of themes as I understand it, and if it doesn’t, we need someone that is interested in making it work to dig in, figure exactly what is wrong, and then propose a fix or at least a very well defined change that needs to take place for this to work.

As it is, we have pretty vague conversations in multiple places and nobody working on it.

10

Hey again there,

The previous post somewhat drifted from the original question/bug, so
let’s try to go back on track and summarize what is the situation at the
moment.

Today common themes are already working out of the box for snaps using
the gnome-platform or the desktop launcher.

It means that any GNOME or Unity user installing a gtk-based snap is
going to have it looking integrated to the desktop/theme he’s currently
using as long as he’s using one of the standard themes (Adwaita, Ubuntu
light or dark). The GNOME theme (Adwaita) allows using a dark variant,
that’s a less standard option which is available under GNOME tweak tools
and we had a bug in that special case, which has been fixed in snapd git
now and is waiting for the next release to be out.

For those looking to an example snapcraft.yaml that’s a simple one for
gtk3-demo

A snap build as been pushed to the store as gtk-3-demo for those who
want to give it a try. You can change the theme from
unity-control-center or by settings the org.gnome.desktop.interface
gtk-theme gsettings key. I’m attaching some screenshot for the headerbar
section of the demo, they show the look being right for each of the
selected themes.

We believe that the current situation should give a good experience to
most of our desktop users but we also know that more work is needed to
handle for example third party themes.

You are right Gustavo that the previous posts here were not specific
enough and probably off topic for bug described here. The content
interface limitations mentioned are problems we discussed previously on
IRC and with members of the snappy team but that might not have been
documented well enough on launchpad or raised to the right people.

We are going to create a new topic to discuss more the details of the
work we think is needed to create “theme snaps”, which would allow users
to install any theme they want and have those available to any snap
installed, and describe in details (with examples) the issues we are
currently
having with the content interface.

Cheers,

2 Likes