/srv/irclogs.ubuntu.com/2022/05/04/#ubuntu-desktop.txt

=== xv8 is now known as XV8
seb128goood morning desktopers05:47
dufluMorning seb128 05:48
seb128duflu, hey, how are you today?05:48
dufluseb128, better but not fully better. How are you?05:48
seb128I'm alright!05:49
oSoMoNgood morning desktoppers05:53
dufluHi oSoMoN 05:54
oSoMoNhey duflu 05:54
seb128lut oSoMoN, en forme ?05:56
oSoMoNsalut seb128, ça va bien, et toi?06:01
seb128ça va :)06:05
didrocksgood morning06:10
oSoMoNsalut didrocks 06:12
didrockshey oSoMoN 06:14
seb128lut didrocks 06:20
seb128hey ricotz 06:20
didrockssalut seb128 06:21
dufluSalut didrocks 06:26
didrocksbonsoir duflu :)06:27
duflu2:27 PM :)06:27
didrocksbon après-m! donc :)06:28
ricotzhello desktopers07:22
didrockshey ricotz 07:27
ricotzdidrocks, hi07:29
dufluHi ricotz 07:40
oSoMoNhello ricotz 07:48
=== alan_g_ is now known as alan_g
diddledanioSoMoN: should I set 1967963 as a duplicate of 1970594 considering the latter is where we have the fix10:14
diddledani#1967963 #197059410:14
diddledanibah bot!10:15
diddledaniLP: #1967963 LP: #197059410:15
ubottuLaunchpad bug 1967963 in firefox (Ubuntu) "Firefox snap cannot be set as default browser under KDE" [Low, Incomplete] https://launchpad.net/bugs/196796310:15
ubottuLaunchpad 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/197059410:15
oSoMoNdiddledani, that looks like a different problem, where the reporter couldn't set the default browser in the KDE settings app10:16
diddledanioh I thought it was the same issue - both seemed related10:16
oSoMoNhence the request for more info and the incomplete status10:16
diddledaniin that case then, rereading it, it does look separate. Ignore me ;-p10:18
* diddledani pets her rubber duck (oSoMoN )10:19
oSoMoNI am no rubber duck!10:27
diddledanithen how did I just do rubber duck decision making?! ;-p10:35
ograoSoMoN, 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:37
oSoMoNogra, 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 snap10:57
ograoSoMoN, 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:58
ograour 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)10:59
ograoSoMoN, https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1897454 was the bug 11:00
ubottuLaunchpad bug 1897454 in chromium-browser (Ubuntu) "[snap] Chromium has Wayland support disabled" [Low, Confirmed]11:00
ogra... the launcher picks up the snapcraft.yaml env variable and we can not override this from the user side 11:02
oSoMoNtesting now whether a repacked chromium snap without that env var works as expected11:04
ograFORCE_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
ogra(or "unset DISABLE_WAYLAND")11:05
oSoMoNif it does I'll remove the var (from what I read chromium still defaults to xwayland unless explicitly instructed otherwise)11:06
ograright, i dont want the default changed ... just an option for users wanting to "explicitly instruct it otherwise" 😉11:07
ograi.e. not a chromium change, but added launcher flexibility 11:07
diddledaniogra: 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_PATH11:10
oSoMoNin 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 experimentally11:10
ograi just assume that chromium is not the only app that would benefit from a little less strictness 11:10
oSoMoNhere the use of DISABLE_WAYLAND is clearly not correct (any longer)11:11
oSoMoNsure, but I argue that the packagers of these apps should decide whether DISABLE_WAYLAND is (still) relevant to the app they package11:12
ograespecially 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
oSoMoNbut it wouldn't hurt to allow overriding it, I guess11:12
ogradiddledani, 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:14
ograthough i think that requires a bigger change in snapcraft itself 11:16
oSoMoNdiddledani, 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=21aad6e1944b72b359305ad22d665802ce4df6ed11:17
ubottuCommit 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
ograhah !11:17
diddledaniwhat 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
ogradiddledani, not sure the yaml parser would permit that syntax11:18
oSoMoNyeah, I don't think so11:19
ogra(would be awesome if it did though)11:19
diddledaniwell it supports this: https://github.com/snapcore/snapcraft/blob/8062dfd03ddd4ba8ca3445a46b8bd0e89391fb35/snapcraft/internal/project_loader/_extensions/gnome_3_38.py#L14011:19
diddledanimight need quotes11:20
diddledaniother than that I think it'll work11:20
ograDISABLE_WAYLAN😧 ${DISABLE_WAYLAN😧-1}11:21
ograbah 11:21
diddledaniEMOJI INVASION!11:21
ograit works without the outer curly brackets here 11:21
ograno idea if it functions as expected though 11:21
diddledaniyou need the curlies because it's a posix shell expansion11:21
diddledanithe curlies around environment: {} are a yaml syntax thing11:22
diddledanithe curlies on ${DISABLE_WAYLAND:-1} are a posix shell expansion11:23
=== XV8 is now known as xv8
diddledanithe equivalent yaml could be: https://www.irccloud.com/pastebin/ExaSY2XG/11:24
diddledanithat's identical to the line I put above11:24
diddledanithese are both identical https://www.irccloud.com/pastebin/dYYwSOqB/11:25
KGB-0gtk4 tags 133c584 Simon McVittie upstream/4.6.3+ds1 * Upstream version 4.6.3+ds1 * https://deb.li/3p8dg11:26
KGB-2gtk4 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/xJHh11:26
oSoMoNit'd be interesting to have stats on how many snaps set DISABLE_WAYLAND in their environment11:39
=== 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

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!