07:10WhyNotHugo: There is no mechanism for clients to inform the compositor that a text-field is active and a zwp_virtual_keyboard_v1 needs to be shown right?
07:10WhyNotHugo: Or rather, the zwp_virtual_keyboard_v1 protocol has no way for the compositor to inform "you should now show up".
07:11WhyNotHugo: This always needs to be done manually be the user?
07:13vyivel: zwp_text_input_v3.{enable,disable}?
07:14WhyNotHugo: Right, client can inform the compositor that a text field is active, and the compositro can inform the input method, but the virtual keyboard receives no event.
07:14WhyNotHugo: The input method can inform the virtual keyboard out-of-band, but that doesn't seem ideal; the compositor should inform the virtual keyboard too.
07:21emersion: the virtaul keyboard protocol alone is not suitable for implementing OSKs
07:21emersion: virtual*
07:22emersion: there are discussions about input-method being the right protocol for implementing OSKs
07:25WhyNotHugo: If I use input-method to implement an on-screen-keyboard, then I can't use that keyboard with an input method.
07:26WhyNotHugo: E.g.: I want to use wvkbd as a virtual keyboard and fcitx as input method. They have entirely different roles
07:29WhyNotHugo: Another use case is using a T9-like input method with a physical numeric keyboard. This input method should also be usable with a virtual numeric keyboard.
07:39wlb: wayland/main: Julian Orth * protocol: clients should not emulate key-press events on enter https://gitlab.freedesktop.org/wayland/wayland/commit/7c6259e9ad75 protocol/wayland.xml
07:39wlb: wayland Merge request !424 merged \o/ (protocol: clients should not emulate key-press events on enter https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/424)
07:39emersion: i don't think that can really work
07:40emersion: typically on android you have a different virtual keyboard for CJK
07:41emersion: virtual keyboard can have emoji keys, actions such as "paste" etc
07:41emersion: sorry, OSKs*
07:44WhyNotHugo: Android doesn't use wayland, so that limitation doesn't really affect us.
07:44WhyNotHugo: A virtual keyboard that can type emoji CAN use the input method protocol
07:45WhyNotHugo: But a virtual keyboard that just allows inserting letters (or numbers) shouldn't need to implement an entire input method itself too.
07:47WhyNotHugo: If I use an input method with a phyisical keyboard, I want to use that with a virtual keyboard too. I don't think that the virtual keyboard author should have to reimplement the input method itself.
07:51WhyNotHugo: emersion: i don't think that can really work <-- it can work, and it does work, the exampe of wvkbd+fcitx is not theoretical. I have used it to write CJK.
07:51emersion: let me reword
07:52emersion: i think designing OSKs like physical keyboards has severe limitations that make that undesirable
07:57WhyNotHugo: I don't disagree on that, but forcing virtual-keyboards to use input-method means one can't combine different keybords with different input methods, which is also a severe limitation.
07:58emersion: i would call this a better user experience :P
07:58emersion: OSKs and IMEs both provide UI to write, it's best if there is a single UI to do that instead of 2
07:58WhyNotHugo: In a world where a virtual keyboard needs to be an input method, how would you achieve the equivalent of wvkbd+fcitx?
08:08eruditehermit: Hi, is there an application like barrier that works with wayland?
08:10selckin: try lan-mouse input-leap
08:11ofourdan: eruditehermit: there's input-leap (https://github.com/input-leap/input-leap) and it's being added to the forthcoming synergy 1.16.0 as well (https://github.com/symless/synergy/discussions/7491) but it relies on portals so it doesn't work with all Wayland compositors (I tested only with GNOME Shell myself)
08:13ofourdan: (and https://github.com/symless/synergy/discussions/7456 as some more information about Synergy support)
08:13eruditehermit: ofourdan: amazing
08:14eruditehermit: ofourdan: do you know if it supports kwin -> gnome shell?
08:14eruditehermit: or whatever kde's window manager is called these days
08:15ofourdan: I havent tried, but as long as the required portals are implemented, it /should/ work
08:16eruditehermit: what was the best way to install it as of now?
08:16ofourdan: that actually depends on your distribution
08:17ofourdan: I used to maintain a build of input-leap and libportal is a copr for Fedora but it's probably outdated now
08:18eruditehermit: I'm on ubuntu 24.04
08:18ofourdan: other distributions, I do not know…
08:18eruditehermit: I wonder if this won't work in a flatpak form because of deeper OS integration
08:18eruditehermit: really permissions
08:19ofourdan: it's using libei and portals, so I reckon it should be diable usign flatpak, at least it was the idea.
08:19ofourdan: (as long as the compositor has libei support, of course)
08:20ofourdan: s/diable/doable/
08:21eruditehermit: from the docs it seems you have to install from source and you need a newer libportal
08:23eruditehermit: wow this all seems new as in synergy made a release yesterday
08:23eruditehermit: I've been checking on this for 3 years
08:23ofourdan: it is new in synergy, yes, although it's been is input-leap for quite some time
08:27eruditehermit: ofourdan: did you build from source for input-leap and do you need libportal newer than the one 0.7.1?
08:27whot: eruditehermit: note that barrier is dead, input-leap is the replacement for it (all the maintainers moved)
08:27whot: eruditehermit: libportal 0.8 was released last weekend and that has all the bits needed
08:27ofourdan: yeah, I build fro msource myself, but it's a bit of work
08:28whot: i think you can build inputleap on F40 with what's in the repo and get everything but the client-side session restore
08:30llyyr: is there a simple client I can look at for text-input protocol implementation for pointers?
08:34eruditehermit: whot: I started down the path of build deps and it is ballooning =P
08:34eruditehermit: probably better to do this in a VM
08:38eruditehermit: whot, ofourdan: do you knowo how difficult it'd be to build a flatpak package? Do you think it'd be welcomed?
08:39whot: eruditehermit: I had one at some point, it's not that hard. they've ben considering it upstream but suffering from lack of maintainer time
08:40whot: eruditehermit: nevermind it's already in dist/flatpak in the input-leap tree
08:41whot:has to go
09:06eruditehermit: darn I needed to ask whot how to use the flatpak build scripts
09:06eruditehermit: perhaps tomorrow
10:38wlb: wayland Merge request !426 opened by () protocol: document surface synchronization requirements https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/426
20:19eruditehermit: whot: hi, are you around?
20:45eruditehermit: whot: I'm trying to build the flatpak using your buildscript on CI. It's failing building libei but it'd be great to get your input on it.
20:51whot: eruditehermit: around now (for a short while)
20:55eruditehermit: whot: I think the buildscript is old and I am working through fixing it. I am figuring out the options for libei. https://github.com/rohitpid/input-leap/actions/runs/10800392018/job/29958284478
20:56eruditehermit: I think that one is just disable for the tests flag
20:56eruditehermit: whot: are those roughly the steps I need to build the flatpak?
20:57whot: -Ddocumentation= -Dtests=disabled -Dliboeffis=disabled should do the trick
20:57whot: you don't need docs or tests for the flatpak and input-leap doesn't use liboeffis so you don't need that one either
20:58eruditehermit: -Ddocumentation can only be portal or api
20:59whot: nah, you can supply an empty array to build neither
20:59eruditehermit: -Dportal seems to be gone
20:59eruditehermit: from libei
20:59whot: yep
21:01eruditehermit: whot: https://github.com/rohitpid/input-leap/actions/runs/10800494498/job/29958639958
21:01eruditehermit: I'm new to this flatpak buildscript
21:02eruditehermit: for this error, is it enough to install the python packages in the outer environment or do I need to do it through the buildscript for flatpaks
21:02wlb: wayland Merge request !423 closed (Draft: Atomic request sequences)
21:08whot: eruditehermit: you'll need to pip install those during the build but I'm not sure how that's done in flatpak
21:09eruditehermit: I'll look it up
21:10eruditehermit: whot: your script currently builds main of libei. Is there a version we should target instead?
21:12whot: whatever the most recent release is will do
21:12whot: 1.3.0, there's only one doc fix on top of that anyway
21:23eruditehermit: whot: it's currently pointing to your branch of inputpeap. Are things pushed upstream now?
21:30feaneron: eruditehermit: have you tried -Ddocumentation=[]
21:30feaneron: ?
21:30feaneron: eh nevermind, won't make a difference
21:31eruditehermit: feaneron: I set it to -Ddocumentation=
21:32eruditehermit: feaneron: do you know about flatpak builds?
21:34feaneron: not much
21:37feaneron: left a comment on the input leap pr
21:38whot: eruditehermit: everything is upstream now, input-leap, libportal and libei
21:39eruditehermit: feaneron: thanks, this might be helpful
21:39eruditehermit: whot: I'll change the ref to point to upstream input-leap then
21:44eruditehermit: feaneron: what they did looks very complicated for what it does
21:44eruditehermit: =P
21:44eruditehermit: I'm trying it
21:50feaneron: python packages are often a pain in flatpak
21:51eruditehermit: feaneron: it worked and got a lot further
21:51eruditehermit: https://github.com/rohitpid/input-leap/actions/runs/10801070560/job/29960432658
21:51eruditehermit: builds all the other deps, just fails on inputleap itself
21:52eruditehermit: this one I don't know about, it's some build system specific thing probably
21:54eruditehermit: it doesn't like submodules
21:54eruditehermit: which I personally don't like either
22:01eruditehermit: why is it trying to use 'file' transport when the submodules are 'https'
22:37whot: eruditehermit: looks like you're trying to dl googletest which is not something you need in the flatpak, use the cmake option in input-leap to disable tests (however that one is called)
22:44eruditehermit: whot: it's not something you can control via the cmake options. It will clone the git submodules before the cmake runs.
22:45eruditehermit: 1) clone the repo and submodules 2) run cmake with any flags to disable tests.
22:45whot: that seems... wrong? you can ship a flatpak-local patch that just patches this bit out
22:45whot: but if it tries to clone the test deps even when tests are disabled that would indicate a bug in the cmake script
22:46eruditehermit: not really
22:47eruditehermit: if my understanding is correct you have to have a repo cloned to be able to run cmake right?
22:47eruditehermit: first I clone inputleap, then only can I run cmake on the code, otherwise I don't have code to begin with
22:47eruditehermit: now if the git repo is setup with submodules in the config, I clone the submodules too
22:47eruditehermit: unless I don't use --recurse
22:48eruditehermit: but if I don't use that, it fails too
22:49eruditehermit: I'm trying without recursive cloning on the outside
22:53eruditehermit: whot: this is my current state: https://github.com/rohitpid/input-leap/blob/rp-feat-flatpak-ci/dist/flatpak/com.github.input-leap.input-leaps.yml
22:53whot: i think you can just git submodule init specific submodules, so just skip the gtest one (and patch cmake if need be so it doesn't heck for it)
22:57eruditehermit: whot: separately, can I use upstream libportal?
22:57eruditehermit: currently it's using your branch
22:57whot: yes, use 0.8.1
22:57whot: none of my branches have been updated since all this has been merged, so if you see whot in an url somewhere, you're using the wrong branch :)
22:58eruditehermit: yeah I'm trying to fix things as I go along
22:59eruditehermit: would like to get to a testable flatpak
22:59eruditehermit: since it's probably easier than building every distro package
22:59eruditehermit: but I guess I could build the deb
22:59eruditehermit: flatpak manifest seems pretty flexible
23:00eruditehermit: whot: do you contribute to all these projects?
23:01eruditehermit: feaneron: seems like you contribute to libportal
23:06eruditehermit: whot: still the same issue: https://github.com/rohitpid/input-leap/actions/runs/10801896501/job/29962942894 with this: https://github.com/rohitpid/input-leap/blob/rp-feat-flatpak-ci/dist/flatpak/com.github.input-leap.input-leaps.yml
23:33whot: eruditehermit: I think you might be better off with submodules false on input-leap and building the gulrak dependency as a separate one
23:34whot: actually - does it work if you just leave the ext/gtest parts out?
23:43eruditehermit: nope
23:44eruditehermit: I think flatpak is hijacking the submodule clone process
23:44eruditehermit: it should be using https but it say's it's using file://
23:44eruditehermit: there is this bug report but I didn't understand the resolution
23:45eruditehermit: whot: https://github.com/flatpak/flatpak-builder/issues/495
23:45eruditehermit: do you understand what they are saying?
23:45whot: eruditehermit:you know you can build locally?
23:45eruditehermit: whot: yeah but I thought I'd make a PR to help the project
23:46eruditehermit: if it's something that needs to be done anyway
23:46whot: eruditehermit: instead of forcing throug github for everything, you can create a podman container locally, then run flatpak-builder in that and once it succeeds, the github CI one should too
23:46whot: You'll get a much faster turnaround time for debugging/testing things that way instead of having to wait for the CI every time
23:46eruditehermit: sure
23:47eruditehermit: but the build is pretty fast so I was lazy
23:47eruditehermit: I can build it in docker
23:48eruditehermit: the other handy thing about the CI is it's easy to show people
23:48eruditehermit: you can see exactly where it fails more easily
23:57eruditehermit: ok I made progress
23:57eruditehermit: whot: https://github.com/rohitpid/input-leap/actions/runs/10802386720/job/29964335652
23:58eruditehermit: this is your script I believe
23:58eruditehermit: not sure what the intention is here