=== xv8 is now known as XV8 [05:47] goood morning desktopers [05:48] Morning seb128 [05:48] duflu, hey, how are you today? [05:48] seb128, better but not fully better. How are you? [05:49] I'm alright! [05:53] good morning desktoppers [05:54] Hi oSoMoN [05:54] hey duflu [05:56] lut oSoMoN, en forme ? [06:01] salut seb128, ça va bien, et toi? [06:05] ça va :) [06:10] good morning [06:12] salut didrocks [06:14] hey oSoMoN [06:20] lut didrocks [06:20] hey ricotz [06:21] salut seb128 [06:26] Salut didrocks [06:27] bonsoir duflu :) [06:27] 2:27 PM :) [06:28] bon après-m! donc :) [07:22] hello desktopers [07:27] hey ricotz [07:29] didrocks, hi [07:40] Hi ricotz [07:48] hello ricotz === alan_g_ is now known as alan_g [10:14] oSoMoN: should I set 1967963 as a duplicate of 1970594 considering the latter is where we have the fix [10:14] #1967963 #1970594 [10:15] bah bot! [10:15] LP: #1967963 LP: #1970594 [10:15] Launchpad bug 1967963 in firefox (Ubuntu) "Firefox snap cannot be set as default browser under KDE" [Low, Incomplete] https://launchpad.net/bugs/1967963 [10:15] Launchpad bug 1970594 in xdg-utils (Ubuntu) "'xdg-settings check default-web-browser something.desktop' fails in Kubuntu 22.04: Bad substitution" [Medium, In Progress] https://launchpad.net/bugs/1970594 [10:16] diddledani, that looks like a different problem, where the reporter couldn't set the default browser in the KDE settings app [10:16] oh I thought it was the same issue - both seemed related [10:16] hence the request for more info and the incomplete status [10:18] in that case then, rereading it, it does look separate. Ignore me ;-p [10:19] * diddledani pets her rubber duck (oSoMoN ) [10:27] I am no rubber duck! [10:35] then how did I just do rubber duck decision making?! ;-p [10:37] oSoMoN, we had many people complain in #ubuntu that you can not run chroimum with native wayland support (i think there is even a bug open) ... i wonder if we couldn't change the desktop helpers a bit to allow overriding "DISABLE_WAYLAN😧 1" from the user side somehow (env will obviously not work since snapcraft sets it after start, but probably an extra cmdline option or so) [10:57] ogra, I think DISABLE_WAYLAND is intended for applications which are known not to support wayland natively, so if chromium is supposed to work well with wayland these days (I haven't checked recently but I will do that again), we should simply not set it in the snap [10:58] oSoMoN, well, to run chromium with wayland you need to add some cmdline switches, it works fine in my electron snaps, but DISABLE_WAYLAND will make the desktop-launcher force it into XWayland so it does not even find a socket [10:59] our launcher setup makes it impossible for people to test it in that context (i dont want to move chromium to wayland permanently, i just want us to have a way to not make the launcher be so strict) [11:00] oSoMoN, https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1897454 was the bug [11:00] Launchpad bug 1897454 in chromium-browser (Ubuntu) "[snap] Chromium has Wayland support disabled" [Low, Confirmed] [11:02] ... the launcher picks up the snapcraft.yaml env variable and we can not override this from the user side [11:04] testing now whether a repacked chromium snap without that env var works as expected [11:05] FORCE_WAYLAND=1 chromium --enable-features=UseOzonePlatform --ozone-platform=wayland ... if something like that would simply make the launcher "export DISABLE_WAYLAND=0" at the very top, users could force-override the hardcoded default [11:05] (or "unset DISABLE_WAYLAND") [11:06] if it does I'll remove the var (from what I read chromium still defaults to xwayland unless explicitly instructed otherwise) [11:07] right, i dont want the default changed ... just an option for users wanting to "explicitly instruct it otherwise" 😉 [11:07] i.e. not a chromium change, but added launcher flexibility [11:10] ogra: oSoMoN : I forget whether this is true, but you might find traction with a change to the `environment` declaration - use a posix shell "if this is not currently defined" variable expansion the way that the desktop runtime extensions add to `build-environment` to allow for augmenting pre-existing vars like LD_LIBRARY_PATH [11:10] in this case though I think the chromium change is the most sensible option (provided my testing validates it): chromium will still default to xwayland, but it does support native wayland, at least experimentally [11:10] i just assume that chromium is not the only app that would benefit from a little less strictness [11:11] here the use of DISABLE_WAYLAND is clearly not correct (any longer) [11:12] sure, but I argue that the packagers of these apps should decide whether DISABLE_WAYLAND is (still) relevant to the app they package [11:12] especially in the light that likely more and more apps will slowly switch to native wayland, so you could optionally try running them in that context and help devs identify bugs etc [11:12] but it wouldn't hurt to allow overriding it, I guess [11:14] diddledani, i'm not sure there is a way to have the snapcraft wrapper pick it up in such a way ... but yeah, it might make more sense overriding it there than in the desktop launcher if such things work there [11:16] though i think that requires a bigger change in snapcraft itself [11:17] diddledani, ogra: in fact I did exactly this in the firefox snap two days ago: https://git.launchpad.net/~mozilla-snaps/+git/firefox-snap/commit/?id=21aad6e1944b72b359305ad22d665802ce4df6ed [11:17] Commit 21aad6e in ~mozilla-snaps/+git/firefox-snap "Default to XWayland, but allow users to force native Wayland support by passing MOZ_ENABLE_WAYLAND=1stable" [11:17] hah ! [11:18] what I was thinking is the user can export DISABLE_WAYLAND=0 somehow which based on using an environment block like `environment: { DISABLE_WAYLAND: ${DISABLE_WAYLAND:-1} }` [11:18] diddledani, not sure the yaml parser would permit that syntax [11:19] yeah, I don't think so [11:19] (would be awesome if it did though) [11:19] well it supports this: https://github.com/snapcore/snapcraft/blob/8062dfd03ddd4ba8ca3445a46b8bd0e89391fb35/snapcraft/internal/project_loader/_extensions/gnome_3_38.py#L140 [11:20] might need quotes [11:20] other than that I think it'll work [11:21] DISABLE_WAYLAN😧 ${DISABLE_WAYLAN😧-1} [11:21] bah [11:21] EMOJI INVASION! [11:21] it works without the outer curly brackets here [11:21] no idea if it functions as expected though [11:21] you need the curlies because it's a posix shell expansion [11:22] the curlies around environment: {} are a yaml syntax thing [11:23] the curlies on ${DISABLE_WAYLAND:-1} are a posix shell expansion === XV8 is now known as xv8 [11:24] the equivalent yaml could be: https://www.irccloud.com/pastebin/ExaSY2XG/ [11:24] that's identical to the line I put above [11:25] these are both identical https://www.irccloud.com/pastebin/dYYwSOqB/ [11:26] gtk4 tags 133c584 Simon McVittie upstream/4.6.3+ds1 * Upstream version 4.6.3+ds1 * https://deb.li/3p8dg [11:26] gtk4 pristine-tar 28e4bbd Simon McVittie gtk4_4.6.3+ds1.orig.tar.xz.delta gtk4_4.6.3+ds1.orig.tar.xz.id * pristine-tar data for gtk4_4.6.3+ds1.orig.tar.xz * https://deb.li/xJHh [11:39] it'd be interesting to have stats on how many snaps set DISABLE_WAYLAND in their environment === xv8 is now known as XV8 === XV8 is now known as xv8 === xv8 is now known as XV8 === XV8 is now known as xv8 === xv8 is now known as XV8 === tomreyn_ is now known as tomreyn