ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
RAOF has quit [Remote host closed the connection]
RAOF has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
Company has quit [Ping timeout: 480 seconds]
lanodan has quit [Quit: WeeChat 4.3.2]
lanodan has joined #wayland
Company has joined #wayland
kts has joined #wayland
whot1 has quit []
whot has joined #wayland
kts has quit [Quit: Leaving]
mxz__ has joined #wayland
mxz_ has quit [Ping timeout: 480 seconds]
mxz has quit [Ping timeout: 480 seconds]
mxz has joined #wayland
jmnemonic has joined #wayland
crazybyte has quit [Read error: Connection reset by peer]
crazybyte has joined #wayland
glennk has joined #wayland
rasterman has joined #wayland
coldfeet has joined #wayland
leon-anavi has joined #wayland
flokli has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
sima has joined #wayland
flokli has joined #wayland
<WhyNotHugo> 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?
<WhyNotHugo> Or rather, the zwp_virtual_keyboard_v1 protocol has no way for the compositor to inform "you should now show up".
<WhyNotHugo> This always needs to be done manually be the user?
<vyivel> zwp_text_input_v3.{enable,disable}?
<WhyNotHugo> 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.
<WhyNotHugo> 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.
<emersion> the virtaul keyboard protocol alone is not suitable for implementing OSKs
<emersion> virtual*
<emersion> there are discussions about input-method being the right protocol for implementing OSKs
<WhyNotHugo> If I use input-method to implement an on-screen-keyboard, then I can't use that keyboard with an input method.
<WhyNotHugo> E.g.: I want to use wvkbd as a virtual keyboard and fcitx as input method. They have entirely different roles
<WhyNotHugo> 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.
<wlb> 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
<wlb> 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)
<emersion> i don't think that can really work
<emersion> typically on android you have a different virtual keyboard for CJK
<emersion> virtual keyboard can have emoji keys, actions such as "paste" etc
<emersion> sorry, OSKs*
Lucretia has joined #wayland
<WhyNotHugo> Android doesn't use wayland, so that limitation doesn't really affect us.
<WhyNotHugo> A virtual keyboard that can type emoji CAN use the input method protocol
<WhyNotHugo> But a virtual keyboard that just allows inserting letters (or numbers) shouldn't need to implement an entire input method itself too.
<WhyNotHugo> 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.
<WhyNotHugo> 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.
<emersion> let me reword
<emersion> i think designing OSKs like physical keyboards has severe limitations that make that undesirable
<WhyNotHugo> 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.
<emersion> i would call this a better user experience :P
<emersion> OSKs and IMEs both provide UI to write, it's best if there is a single UI to do that instead of 2
<WhyNotHugo> In a world where a virtual keyboard needs to be an input method, how would you achieve the equivalent of wvkbd+fcitx?
eruditehermit has joined #wayland
<eruditehermit> Hi, is there an application like barrier that works with wayland?
<selckin> try lan-mouse input-leap
<ofourdan> 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)
<ofourdan> (and https://github.com/symless/synergy/discussions/7456 as some more information about Synergy support)
<eruditehermit> ofourdan: amazing
<eruditehermit> ofourdan: do you know if it supports kwin -> gnome shell?
<eruditehermit> or whatever kde's window manager is called these days
<ofourdan> I havent tried, but as long as the required portals are implemented, it /should/ work
<eruditehermit> what was the best way to install it as of now?
<ofourdan> that actually depends on your distribution
<ofourdan> I used to maintain a build of input-leap and libportal is a copr for Fedora but it's probably outdated now
<eruditehermit> I'm on ubuntu 24.04
<ofourdan> other distributions, I do not know…
<eruditehermit> I wonder if this won't work in a flatpak form because of deeper OS integration
<eruditehermit> really permissions
<ofourdan> it's using libei and portals, so I reckon it should be diable usign flatpak, at least it was the idea.
<ofourdan> (as long as the compositor has libei support, of course)
<ofourdan> s/diable/doable/
<eruditehermit> from the docs it seems you have to install from source and you need a newer libportal
<eruditehermit> wow this all seems new as in synergy made a release yesterday
<eruditehermit> I've been checking on this for 3 years
<ofourdan> it is new in synergy, yes, although it's been is input-leap for quite some time
<eruditehermit> ofourdan: did you build from source for input-leap and do you need libportal newer than the one 0.7.1?
<whot> eruditehermit: note that barrier is dead, input-leap is the replacement for it (all the maintainers moved)
<whot> eruditehermit: libportal 0.8 was released last weekend and that has all the bits needed
<ofourdan> yeah, I build fro msource myself, but it's a bit of work
<whot> i think you can build inputleap on F40 with what's in the repo and get everything but the client-side session restore
<llyyr> is there a simple client I can look at for text-input protocol implementation for pointers?
karolherbst_ has joined #wayland
<eruditehermit> whot: I started down the path of build deps and it is ballooning =P
<eruditehermit> probably better to do this in a VM
<eruditehermit> whot, ofourdan: do you knowo how difficult it'd be to build a flatpak package? Do you think it'd be welcomed?
<whot> 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
<whot> eruditehermit: nevermind it's already in dist/flatpak in the input-leap tree
* whot has to go
rgallaispou has quit [Read error: Connection reset by peer]
MrCooper_ is now known as MrCooper
coldfeet has quit [Remote host closed the connection]
<eruditehermit> darn I needed to ask whot how to use the flatpak build scripts
<eruditehermit> perhaps tomorrow
___nick___ has quit [Remote host closed the connection]
rgallaispou has joined #wayland
kts has joined #wayland
fmuellner has joined #wayland
kts has quit [Quit: Leaving]
kts has joined #wayland
<wlb> wayland Merge request !426 opened by () protocol: document surface synchronization requirements https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/426
Lucretia has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
nerdopolis has joined #wayland
Lucretia has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
feaneron has joined #wayland
eruditehermit has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
kts has joined #wayland
Lucretia has quit [Remote host closed the connection]
Lucretia has joined #wayland
Moprius has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
Moprius has quit [Quit: bye]
jmnemonic has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
jmnemonic has joined #wayland
jmnemonic has quit [Remote host closed the connection]
jmnemoni has joined #wayland
Lucretia has quit []
Lucretia has joined #wayland
kts has joined #wayland
FreeFull has quit []
agd5f has quit [Remote host closed the connection]
agd5f has joined #wayland
FreeFull has joined #wayland
Company has quit [Quit: Leaving]
agd5f has quit [Read error: No route to host]
agd5f has joined #wayland
rasterman has joined #wayland
leon-anavi has quit [Quit: Leaving]
kestrel has quit [Ping timeout: 480 seconds]
coldfeet has joined #wayland
avu has quit [Quit: avu]
avu has joined #wayland
Brainium has quit [Read error: Connection reset by peer]
kts has quit [Quit: Leaving]
eruditehermit has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
Lucretia has quit [Ping timeout: 480 seconds]
eruditehermit has quit [Ping timeout: 480 seconds]
Lucretia has joined #wayland
sima has quit [Ping timeout: 480 seconds]
kenny has quit [Ping timeout: 480 seconds]
gryffus_ has joined #wayland
Moprius has joined #wayland
Lucretia has quit [Ping timeout: 480 seconds]
eruditehermit has joined #wayland
rasterman has joined #wayland
Lucretia has joined #wayland
Brainium has joined #wayland
<eruditehermit> whot: hi, are you around?
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Quit: bye]
Brainium has joined #wayland
<eruditehermit> 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.
<whot> eruditehermit: around now (for a short while)
coldfeet has quit [Remote host closed the connection]
rv1sr has quit []
<eruditehermit> 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
<eruditehermit> I think that one is just disable for the tests flag
<eruditehermit> whot: are those roughly the steps I need to build the flatpak?
<whot> -Ddocumentation= -Dtests=disabled -Dliboeffis=disabled should do the trick
<whot> 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
<eruditehermit> -Ddocumentation can only be portal or api
<whot> nah, you can supply an empty array to build neither
<eruditehermit> -Dportal seems to be gone
<eruditehermit> from libei
<whot> yep
<eruditehermit> I'm new to this flatpak buildscript
agd5f has quit [Read error: No route to host]
<eruditehermit> 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
<wlb> wayland Merge request !423 closed (Draft: Atomic request sequences)
agd5f has joined #wayland
<whot> eruditehermit: you'll need to pip install those during the build but I'm not sure how that's done in flatpak
<eruditehermit> I'll look it up
<eruditehermit> whot: your script currently builds main of libei. Is there a version we should target instead?
<whot> whatever the most recent release is will do
<whot> 1.3.0, there's only one doc fix on top of that anyway
<eruditehermit> whot: it's currently pointing to your branch of inputpeap. Are things pushed upstream now?
<feaneron> eruditehermit: have you tried -Ddocumentation=[]
<feaneron> ?
<feaneron> eh nevermind, won't make a difference
<eruditehermit> feaneron: I set it to -Ddocumentation=
<eruditehermit> feaneron: do you know about flatpak builds?
<feaneron> not much
<feaneron> left a comment on the input leap pr
<whot> eruditehermit: everything is upstream now, input-leap, libportal and libei
<eruditehermit> feaneron: thanks, this might be helpful
<eruditehermit> whot: I'll change the ref to point to upstream input-leap then
rasterman has quit [Quit: Gettin' stinky!]
<eruditehermit> feaneron: what they did looks very complicated for what it does
<eruditehermit> =P
<eruditehermit> I'm trying it
<feaneron> python packages are often a pain in flatpak
<eruditehermit> feaneron: it worked and got a lot further
<eruditehermit> builds all the other deps, just fails on inputleap itself
<eruditehermit> this one I don't know about, it's some build system specific thing probably
<eruditehermit> it doesn't like submodules
<eruditehermit> which I personally don't like either
karolherbst_ is now known as karolherbst
<eruditehermit> why is it trying to use 'file' transport when the submodules are 'https'
Brainium_ has joined #wayland
Brainium_ has quit []
Brainium has quit [Ping timeout: 480 seconds]
andymandias_ has joined #wayland
andymandias has quit [Ping timeout: 480 seconds]
andymandias_ is now known as andymandias
lsd|2 has joined #wayland
lsd|2 has quit []
<whot> 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)
<eruditehermit> whot: it's not something you can control via the cmake options. It will clone the git submodules before the cmake runs.
bnason27 has joined #wayland
bnason2 has quit [Read error: Network is unreachable]
bnason27 is now known as bnason2
<eruditehermit> 1) clone the repo and submodules 2) run cmake with any flags to disable tests.
<whot> that seems... wrong? you can ship a flatpak-local patch that just patches this bit out
<whot> but if it tries to clone the test deps even when tests are disabled that would indicate a bug in the cmake script
<eruditehermit> not really
<eruditehermit> if my understanding is correct you have to have a repo cloned to be able to run cmake right?
<eruditehermit> first I clone inputleap, then only can I run cmake on the code, otherwise I don't have code to begin with
<eruditehermit> now if the git repo is setup with submodules in the config, I clone the submodules too
<eruditehermit> unless I don't use --recurse
<eruditehermit> but if I don't use that, it fails too
<eruditehermit> I'm trying without recursive cloning on the outside
<whot> 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)
nerdopolis has joined #wayland
<eruditehermit> whot: separately, can I use upstream libportal?
<eruditehermit> currently it's using your branch
<whot> yes, use 0.8.1
<whot> 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 :)
<eruditehermit> yeah I'm trying to fix things as I go along
<eruditehermit> would like to get to a testable flatpak
<eruditehermit> since it's probably easier than building every distro package
<eruditehermit> but I guess I could build the deb
<eruditehermit> flatpak manifest seems pretty flexible
lsd|2 has joined #wayland
<eruditehermit> whot: do you contribute to all these projects?
<eruditehermit> feaneron: seems like you contribute to libportal
Brainium has joined #wayland
FreeFull has quit []
Lucretia has quit [Ping timeout: 480 seconds]
<whot> eruditehermit: I think you might be better off with submodules false on input-leap and building the gulrak dependency as a separate one
<whot> actually - does it work if you just leave the ext/gtest parts out?
fmuellner has quit [Ping timeout: 480 seconds]
<eruditehermit> nope
<eruditehermit> I think flatpak is hijacking the submodule clone process
<eruditehermit> it should be using https but it say's it's using file://
caveman has quit [Remote host closed the connection]
<eruditehermit> there is this bug report but I didn't understand the resolution
caveman has joined #wayland
<eruditehermit> do you understand what they are saying?
<whot> eruditehermit:you know you can build locally?
<eruditehermit> whot: yeah but I thought I'd make a PR to help the project
<eruditehermit> if it's something that needs to be done anyway
<whot> 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
<whot> You'll get a much faster turnaround time for debugging/testing things that way instead of having to wait for the CI every time
<eruditehermit> sure
<eruditehermit> but the build is pretty fast so I was lazy
<eruditehermit> I can build it in docker
<eruditehermit> the other handy thing about the CI is it's easy to show people
<eruditehermit> you can see exactly where it fails more easily
glennk has quit [Ping timeout: 480 seconds]
<eruditehermit> ok I made progress
<eruditehermit> this is your script I believe
<eruditehermit> not sure what the intention is here