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