[00:52] <jbicha> fossfreedom: uploaded. I didn't see the bug until now
[00:54] <jbicha> I'm not completely gone. I just need to use more of my time to focus on other priorities these days
[00:57] <jbicha> feel free to ping or email if you want to get my attention
[06:07] <didrocks> good morning
[06:12] <tsimonq2> Hey didrocks, how are you?
[06:13] <oSoMoN> good morning desktoppers!
[06:13] <tsimonq2> Hey oSoMoN :)
[06:13] <oSoMoN> hey tsimonq2, hey didrocks
[06:14] <didrocks> hey tsimonq2, good! yourself?
[06:14] <didrocks> salut oSoMoN
[06:14] <didrocks> tu arrives à dormir? pas trop crevé ?
[06:16] <tsimonq2> didrocks: Pretty good :)
[06:19] <oSoMoN> didrocks, pas assez, je suis fatigué, heureusement le week-end arrive
[06:20] <oSoMoN> je vais pouvoir faire des siestes \o/
[06:23] <duflu> Morning didrocks, tsimonq2, oSoMoN
[06:23] <duflu> et tout le monde
[06:23] <tsimonq2> Hey duflu :)
[06:23] <duflu> Well, Europe anyway
[06:25] <oSoMoN> hey duflu
[06:28] <didrocks> oSoMoN: bon courage :)
[06:28] <didrocks> hey duflu
[06:28] <didrocks> small patch of the morning: https://github.com/ubuntu/communitheme/pull/639/files
[06:28] <gitlab-bot> ubuntu issue (Pull request) 639 in communitheme "Install override file for ubuntu-dock style" (comments: 2) [Open]
[06:29] <didrocks> people developping the theme were hacking away with a mix of the snap session and manually installed things in /usr :p
[06:29] <didrocks> so yeah, ofc, there are some leftovers when reshaping for them a proper build system
[06:37] <duflu> Also good morning Africa
[10:08] <Trevinho> Morning
[10:10] <tsimonq2> Heya Trevinho :)
[10:11] <Trevinho> Hi tsimonq2
[10:14] <duflu> Hi Trevinho
[10:14] <duflu> And good night, bon-weekend
[10:55] <doko> Trevinho: fyi, mutter ftbfs on i386
[12:26] <willcooke> Happy Friday!
[12:27] <didrocks> hey willcooke
[12:44] <doko> didrocks: fyi, ubuntu-settings ftbfs
[12:45] <didrocks> doko: I know, it's a meson regression
[12:45] <didrocks> debugged, filed a bug upstream, tagged as a regression, will be fixed in the next release
[12:47] <c-lobrano> hi all!
[12:47] <didrocks> hey c-lobrano
[12:48] <c-lobrano> didrocks: I'm working on 465, gnome-software ships with it's own gtk-style.css as gresource which seems loaded after ours, so that we cannot modify some properties
[12:48] <c-lobrano> eh, sorry hi didrocks! :D
[12:50] <c-lobrano> is the above due to the mechanism we use to load css in snap?
[12:51] <didrocks> c-lobrano: nothing to be done with the loading mechanism, it's just that the css loaded by the app will always have priorities over the general theme one
[12:52] <c-lobrano> didrocks: I feared this :(
[12:52] <didrocks> c-lobrano: however, you can have an apps/ directory
[12:52] <didrocks> like we have /usr/share/themes/Radiance/gtk-3.20/apps/gnome-panel.css for instance
[12:53] <didrocks> I wonder if that would work with the snap, worth a try
[12:53] <didrocks> at worse, for testing, you can symlink
[12:53] <c-lobrano> didrocks: great, I can see if that work, thanks
[12:54] <didrocks> c-lobrano: keep me posted :)
[12:54] <c-lobrano> ;)
[13:09] <c-lobrano> didrocks: I assume the filename is the same as software executable (i.e. gnome-software.css)
[13:11] <didrocks> c-lobrano: exactly
[13:12] <c-lobrano> didrocks: if this is the only requirement, it does not seem to work :(
[13:12] <c-lobrano> I mkdir apps in /usr/share/Communitheme/gtk-3.0 and copied the simplest css there
[13:13] <didrocks> c-lobrano: interesting, Trevinho would know maybe? ^
[13:14] <didrocks> c-lobrano: I assumed you tried /usr/share/*themes*/Communitheme…
[13:14] <didrocks> (and that it was just a typo?
[13:14] <c-lobrano> didrocks: yes, typo here, but right on the system :D
[13:15] <didrocks> ok, let's see what Trevinho tells…
[13:15] <c-lobrano> alright (y)
[13:40] <muktupavels> didrocks, c-lobrano: what are you trying to do? GTK+ does not automatically load app specific css files.
[13:40] <muktupavels> in Ambiance it is imported - https://bazaar.launchpad.net/~ubuntu-art-pkg/ubuntu-themes/trunk/view/head:/Ambiance/gtk-3.20/gtk-main.css#L67
[13:40] <Trevinho> mh let me see
[13:41] <c-lobrano> muktupavels: oh I see. I am not importing this css from the main one
[13:41] <c-lobrano> muktupavels: so is it just a css organization style (apps specific css)? Does not have any effect on gtk+?
[13:42] <muktupavels> no it does not have any effect...
[13:42] <muktupavels> https://gitlab.gnome.org/GNOME/gnome-software/blob/master/src/gs-application.c#L271
[13:42] <muktupavels> gnome-software loads it with app priority... so I think there is nothing you can do from theme.
[13:42] <c-lobrano> muktupavels: pity, so it is the same we do already with _apps.scss. Does that mean that g-s gtk-style.css will always have priority over our css?
[13:43] <muktupavels> yes.
[13:43] <c-lobrano> :(
[13:43] <Trevinho> c-lobrano: so... you want to include some custom css for an app only, righ?
[13:43] <Trevinho> so, yeah.., as muktupavels said, no way
[13:43] <c-lobrano> Trevinho: yes, we would :D
[13:44] <c-lobrano> I mean, I didn't expect this was g-s specific
[13:44] <Trevinho> c-lobrano: there was some discussion at GUADEC also about theming, and some apps want just to be right.... So someone provide inside their codebase exception for theming
[13:44] <Trevinho> I can't remember examples, but indeed there are
[13:44] <Trevinho> while forcing otherwise
[13:44] <muktupavels> Maybe gnome-software can load it as fallback? Not sure it that will work correctly...
[13:45] <muktupavels> https://developer.gnome.org/gtk3/stable/GtkStyleProvider.html#GTK-STYLE-PROVIDER-PRIORITY-FALLBACK:CAPS
[13:45] <c-lobrano> Trevinho, muktupavels: it is weird though. The same icon is blue under adwaita and orange in communitheme
[13:46] <muktupavels> what icon?
[13:47] <c-lobrano> installed apps have a circular badge
[13:47] <c-lobrano> https://usercontent.irccloud-cdn.com/file/1o3vafvF/image.png
[13:47] <muktupavels> https://gitlab.gnome.org/GNOME/gnome-software/blob/master/src/gtk-style.css#L13
[13:47] <muktupavels> it probably just recolors based on color!?
[13:47] <c-lobrano> the badge is an image with .installed-icon class
[13:48] <didrocks> c-lobrano: as muktupavels pointed out, do you set theme_selected_bg_color?
[13:49] <c-lobrano> oh, yes we do
[13:49] <c-lobrano> found it now
[13:49] <didrocks> and so, it's not picked?
[13:50] <muktupavels> Why is that problem that Adwaita has blue and communitheme orange?
[13:50] <c-lobrano> for sure, adwaita set this theme_selected_bg_color to blue
[13:50] <c-lobrano> *sets
[13:50] <c-lobrano> we use our selection color, which is orange
[13:51] <didrocks> weird…
[13:51] <didrocks> I don't think we do any magic in Ambiance/Radiance, Trevinho ^
[13:52] <Trevinho> c-lobrano: as for including extra css files it should work, if you use the classic @import url...
[13:52] <didrocks> Trevinho: look at the discussion above with gnome-software color
[13:52] <c-lobrano> Trevinho: yes, that is working indeed
[13:52] <didrocks> sounds like it's picking from theme_selected_bg_color
[13:52] <Trevinho> didrocks: yeah, that message was sent while i got disconnected :-D
[13:53] <Trevinho> so the delay
[13:53] <Trevinho> anyway...
[13:53] <didrocks> Trevinho: ahah ;)
[13:53] <c-lobrano> the problem is that g-s is using a very generic color :D
[13:53] <c-lobrano> ;)
[13:53] <c-lobrano> not sure I can change that without affecting other elements, but this is a different problem
[13:53] <Trevinho> those colors are set in ambiance of course... But yeah, they can be for many things
[13:54] <c-lobrano> I assume that changing this define before setting the property and then change it back again, would not work, right? :D
[13:54] <Trevinho> eh, nope
[13:54]  * c-lobrano already is thinking some dirty tricks
[13:54] <c-lobrano> :)
[13:55] <muktupavels> oh, does gtk support !important?
[13:55] <Trevinho> c-lobrano: it's probably better to ask upstream to make possible this theming
[13:55] <muktupavels> if so then it might work..
[13:55] <muktupavels> .installed-icon { color: red !important; }
[13:55] <c-lobrano> muktupavels: not sure, g-s complains when I tried
[13:55] <didrocks> Trevinho: but, it is overridable
[13:56] <didrocks> look at https://gitlab.gnome.org/GNOME/gnome-software/blob/master/src/gtk-style.css#L13
[13:56] <didrocks> so, it should pick theme_selected_bg_color
[13:56] <didrocks> and c-lobrano told that it was set to orange
[13:56] <didrocks> which isn't what he sees from what I understand?
[13:56] <Trevinho> yes, so should happen
[13:56] <c-lobrano> didrocks: yes it is orange
[13:56] <didrocks> ahhhh
[13:56] <c-lobrano> it's working as expected
[13:56] <didrocks> so, all good? I'm unsure
[13:56] <didrocks> about your question :p
[13:56] <didrocks> you mentioned about blueish marks
[13:57] <c-lobrano> :D, since it is more an "indication" than a selection, we didn't want it orange
[13:57] <didrocks> ahhhh
[13:57] <c-lobrano> yes, sorry, I was talking about adwaita
[13:57] <Trevinho> ambiance define all the colors I guess, so these should be redefined by all the themes in general
[13:57] <didrocks> !important isn't supported in the Shell, I don't know for gtk
[13:57] <Trevinho> shell has different code for css parsing
[13:58] <Trevinho> well using same low-level library, but then different
[13:58] <didrocks> yep, that's not what I was asking for :)
[13:58] <didrocks> just if GTK has !important support ;)
[13:58] <Trevinho> has...
[13:59] <didrocks> ok, so I think c-lobrano can override it then, if desired, unsure about the fact to not use the theme color as other apps
[13:59] <muktupavels> gtk inspector does not like !important...
[13:59] <c-lobrano> when I use !important, g-s complains "junk at the end of colors"
[13:59] <Trevinho> at least, in the source code is ised in various places like when loading symbolic svgs...
[13:59] <c-lobrano> *junk at the end of value for color
[14:00] <didrocks> c-lobrano: yeah, forget about the Shell, you are in a GTK use case here anyway and we know it doesn't support it
[14:00] <c-lobrano> muktupavels: gtkinspector can do the trick, because it's css is loaded even after g-s one :D
[14:01] <didrocks> ah g-s -> gnome software, not the shell
[14:01] <c-lobrano> oops, yes
[14:01]  * didrocks got it now :)
[14:01] <didrocks> that's why there was my previous remark :p
[14:01] <c-lobrano> sorry for the misunderstanding
[14:01] <c-lobrano> :D
[14:01] <didrocks> could have been gnome session as well :p
[14:01] <c-lobrano> right
[14:02] <didrocks> annoying it doesn't like it :/
[14:02]  * c-lobrano is removing this todo from the list
[14:02] <didrocks> "done" ECANTDO :)
[14:03] <c-lobrano> but Trevinho is right, I can ask upstream
[14:03] <c-lobrano> and then provide the fix upstream if I can :D
[14:03] <muktupavels> well gnome-software could load extra css as fallback that has @define-color gs_installed_icon_color @theme_selected_bg_color and then in communitheme you could set your own color.
[14:03] <c-lobrano> didrocks: I like that label! ECANTDO
[14:03] <Trevinho> yeah, that could be a good way to do it...
[14:03] <didrocks> c-lobrano: hehe, works in a lot of cases :)
[14:04] <didrocks> but yeah muktupavels is right, unsure if they will want to extend it that way though…
[14:04] <Trevinho> like using a define color pointing as default to the current one
[14:04] <Trevinho> allowing overriding
[14:04]  * didrocks would like that being a gtk feature
[14:04] <Trevinho> upstream should be fine on this
[14:04] <Trevinho> eh... app devs maybe not :-D
[14:04] <c-lobrano> better than mine, was using wontdo, which is way too personal ;)
[14:04] <didrocks> heh
[14:04] <c-lobrano> I can ask for !important
[14:05] <didrocks> or set_color($specific_color,$fallback_color)
[14:05] <didrocks> if first isn't set, fallback to second
[14:05] <didrocks> I guess that's what Trevinho was elluding to
[14:08] <c-lobrano> I see
[14:10] <Trevinho> yeah, like a define... see what upstream prefers
[14:11] <Trevinho> anyone has time for sponsoring my nautilus update?
[14:12] <Trevinho> Seb appartently didn't had time this morning
[14:12] <didrocks> if it doesn't involve git-workflow discussion… :p
[14:12] <Trevinho> didrocks: doesn't
[14:12] <didrocks> can have a look, cosmic?
[14:13] <Trevinho> didrocks: see https://code.launchpad.net/~3v1n0/ubuntu/+source/nautilus/+git/nautilus there are MP for both cosmic and bionic
[14:13] <Trevinho> didrocks: you've write access to salsa also?=
[14:14] <didrocks> Trevinho: I don't
[14:14] <Trevinho> ah branches are *-3-26-4
[14:14] <Trevinho> ah ok
[14:14] <didrocks> links to the MP?
[14:14] <didrocks> that will be easier
[14:14] <Trevinho> https://code.launchpad.net/~3v1n0/ubuntu/+source/nautilus/+git/nautilus/+merge/350170
[14:14] <Trevinho> https://code.launchpad.net/~3v1n0/ubuntu/+source/nautilus/+git/nautilus/+merge/350174
[14:15] <Trevinho> I didn't finalize the changelog + tag though, but I can do if you don't want to do it as the sponsor
[14:15] <didrocks> I can do it
[14:15] <didrocks> however, I'll only do cosmic today
[14:15] <didrocks> but the whole pristine-tar worflow sucks, we have to pull/push for MP with new version
[14:15] <Trevinho> yep
[14:15] <didrocks> I wonder how much we are complicating ourself for no good reason (what's the point to have tarballs now with meson?)
[14:16] <Trevinho> I've proposed pristine-tar + upstream/3.26.x branches to salsa too
[14:16] <didrocks> great! :)
[14:16] <Trevinho> no point.. also because gbp can build one quickly
[14:17] <didrocks> but yeah, I think we should discuss about using upstream git only + packaging branch
[14:17] <didrocks> and a good versionning so that a cherry-pick is really a cherry-pick
[14:17] <didrocks> food for thoughts :)
[14:17] <didrocks> Revert "Revert "files-view: Remove new empty folder name
[14:17] <didrocks> ;)
[14:18] <Trevinho> yeah... :D I wanted to revert it 10 times to make reviewing funnier
[14:19] <didrocks> heh, a diff in a diff in a diff generating a new diff could be fun
[14:21] <didrocks> Trevinho: hum, I can't pull upstream/3.26.x in upstream/latest
[14:21] <didrocks> there are conflicts
[14:21] <didrocks> I was expected your branch to be descendant of it
[14:22] <didrocks> (and still use upstream/latest until we don't diverge on version between bionic and cosmic)
[14:22] <Trevinho> ah... well upstream/latest is not used here since in debian it points to .28 so I thought we should use that
[14:23] <Trevinho> that 3.26.x is just debian salsa + this release
[14:23] <Trevinho> upstream/latest.. not touched
[14:27] <didrocks> Trevinho: ah, yeah, you're right then. But you need gbp.conf to point to the new branch (see instructions)
[14:27] <didrocks> Trevinho: I wonder how your branch could have built then?
[14:27] <Trevinho> isn't that already the case?
[14:27] <Trevinho> I've `upstream-branch=upstream/3.26.x`
[14:28] <didrocks> ah, so an update with this was already done
[14:28] <didrocks> ok, but as gbp didn't download the branch…
[14:28] <didrocks> really, there is something we are getting wrong with that whole workflow IMHO…
[14:28] <Trevinho> mnhmh, why it doesn't how can we make it point to it?
[14:29] <didrocks> Trevinho: so, changes look good, let me testbuild
[14:29] <didrocks> yeah, gbp should be smart enough for this IMHO
[14:29] <Trevinho> like after cloning, check the conf and see what's missing...
[14:29] <didrocks> right
[14:32] <Trevinho> but overriding latest would have been worse here to have debian to work later
[14:38] <didrocks> agreed
[14:38] <didrocks> in that case, it's legit IMHO
[14:38] <didrocks> Trevinho: builds fine and works well to me, sponsoring cosmic :)
[14:39]  * didrocks needs to remember to not use debcommit -r
[14:41] <didrocks> Trevinho: all done, and branches pushed
[14:41] <Trevinho> didrocks: thanks
[14:41] <didrocks> thanks to you!
[14:41] <didrocks> let's see once it's in for nautilus
[14:41] <didrocks> on bionic
[14:47] <Trevinho> it's basically the same
[14:47] <Trevinho> git diff ubuntu/master-3-26-4 on bionic will tell you :)
[15:12] <sdeziel> Could someone tell me where to report a bug with gnome-calculator's snap?
[15:17] <didrocks> kenvandine[m]: do we have somewhere dedicated for our snaps? ^
[15:19] <sdeziel> having a way to pull the sources of said snap would be nice too :)
[15:25] <didrocks> sdeziel: something to request the snapd team on the forum, I think there are already some threads on it
[15:28] <sdeziel> didrocks: OK, thanks
[17:16] <oSoMoN> time to call it a week
[17:17] <oSoMoN> have a great week-end everyone