ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Seirdy_ has joined #wayland
Seirdy_ has quit []
Seirdy_ has joined #wayland
Seirdy has quit [Ping timeout: 480 seconds]
Seirdy_ has quit []
danvet has quit [Ping timeout: 480 seconds]
alan has joined #wayland
lucasmsoares96 has quit [Quit: Konversation terminated!]
Lucretia has quit []
pnowack has quit [Quit: pnowack]
Seirdy has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
boistordu_old has joined #wayland
leon-p_ has joined #wayland
leon-p has quit [Ping timeout: 480 seconds]
boistordu has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
alan has quit [Ping timeout: 480 seconds]
leon-p_ has quit []
lucasmsoares96 has joined #wayland
alan has joined #wayland
jgrulich has joined #wayland
hardening has joined #wayland
peeterm has joined #wayland
bittin has joined #wayland
alan has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
lucasmsoares96 has quit [Quit: Konversation terminated!]
lucasmsoares96 has joined #wayland
pnowack has joined #wayland
pnowack has quit [Remote host closed the connection]
pnowack has joined #wayland
alan has joined #wayland
d_ed has joined #wayland
AJ_Z0 has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
rasterman has quit [Remote host closed the connection]
rasterman has joined #wayland
<danvet>
daniels, just realized I didn't hit submit on the afrc thing
tzimmermann has joined #wayland
<MrCooper>
jadahl: FWIW, on iOS (and Android IIRC) one can switch between keyboard apps on the fly, same way as switching between languages with a single app
<jadahl>
MrCooper: maybe its intent based going through the system layer?
<MrCooper>
no idea how it works behind the scenes
<jadahl>
on the osk on my phone I have 5 or so keyboards, but they are all in the same "keyboard" (GBoard or whatever its called)
<jadahl>
so its just different views
<jadahl>
to select e.g. the built in HTC one, I have to go to language settings and switch from gboard to the HTC one
<emersion>
there's a quick-switch button you can enable
<jadahl>
i doubt its different input method "apps" trying to take things over
Lucretia has joined #wayland
<jadahl>
thats an interesting idea anyhow, to let input methods define their "variant" (e.g. qwerty / hand writing / cangjie / pinyin / zhuyin / ...) and then have the compositor select the righth one
lucasmsoares96 has quit [Quit: Konversation terminated!]
lucasmsoares96 has joined #wayland
hendursa1 has joined #wayland
<emersion>
allows to implement the per-app rules better
<emersion>
or per-workspace, or something else entirely
hendursa2 has joined #wayland
<jadahl>
if only there was a "hand writing" input method anyone could hook up :(
katp32 has joined #wayland
<emersion>
wouldn't be too hard to implement with the current protocols
<jadahl>
right, but I'm mostly complaining about the lack of the actual input method implementation
hendursaga has quit [Ping timeout: 480 seconds]
<jadahl>
that isn't e.g. an electron wrapper around some google web page
<emersion>
it would help to have a proper standard protocol :P
<jadahl>
maybe it'd motivate someone to stat implementing something
<jadahl>
*start
<emersion>
OTOH, do people really use hand writing IMEs?
hendursa1 has quit [Ping timeout: 480 seconds]
<emersion>
always felt like cool demos but not mucn more
<jadahl>
emersion: yes
<jadahl>
well
<emersion>
mayeb it's more common in note-taking apps
<emersion>
but these don't use IMEs
<jadahl>
people using CJK input methods often use hand writing on phones
<emersion>
ah, didn't know. always used the one with 9 buttons
<jadahl>
maybe its a generational thing
<jadahl>
(i.e. older generation using hand writing, younger generation use zhuyin/pinyin, I dunno)
<jadahl>
i managed to get that to work at some point, but it's far from what you get on any android device
<MrCooper>
I've never seen any Japanese person use hand writing, FWIW; traditionally they use kana buttons, or just write the romaji (latin alphabet) transliteration and get semi-auto conversion to kana/kanji
<jadahl>
MrCooper: fwiw all my "in laws" (one generation up) use hand writing (traditional chinese)
<MrCooper>
I could imagine rare cases where somebody remembers how to write a kanji but not its reading though
katp32 has quit [Quit: So long, and thanks for all the fish!]
lucasmsoares96 has quit [Ping timeout: 480 seconds]
<zubzub>
hmm the java/intellij menu popup misplacement seems to be because the menu is both OR & transient and expects the transient coordinates to be used to give the menu proper placement. I expect that to be the issue in Weston as well.
<pq>
zubzub, btw. Weston XWM does not handle changes between O-R and non-O-R at all while the window is mapped, IIRC.
<zubzub>
pq: I expect a lot of X11 clients doing a lot of violations and WM making up for it
<pq>
true
<zubzub>
what do you mean with 'handle changes' ?
<pq>
X11 client setting or unsetting a Window to be O-R
<pq>
...while the window is mapped
<zubzub>
I'm not sure if the popup menu chages while mapped, I'm also not sure if it's even possible to have a transient for set while being OR without changing your OR state
<zubzub>
anyway, it should be relatively easy fix
<pq>
isn't transient-for just another property on the window?
<zubzub>
it is
<pq>
then it can be set any time regardless of anything
<pq>
well, if the O-R status is not changing in flight, that eliminated one known problem
<zubzub>
ok then the fix is to simply interpret the OR x/y coordinates relative to it's transient for parent instead of the root
<pq>
I guess so
<zubzub>
man X is such a mess :p
<pq>
however, the WM is not touching O-R windows, and the X server does not know what transient-for means, so... something has to be bent
<zubzub>
it's easier to implement a wayland compositor than it is to write a spec complient X window manager :p
<pq>
with O-R, the X server won't even ask the WM to place the window
<zubzub>
pq: the WM can still configure a OR window no?
<pq>
the WM can still *fight* over the O-R window placement, yes :-P
<pq>
just that, how does it know when to do that?
<pq>
listen for property changes on the O-R window?
<pq>
can, but should not, unless tradition says it must O_o
<zubzub>
<o>
<pq>
all I can is speculate, ask someone who actually wrote a working WM :-D
<zubzub>
I expect there to be some in this channel no? :P
<emersion>
we don't mess with O-R window positions
<zubzub>
key part here is 'working'
<emersion>
and things work fine
<zubzub>
emersion: what WM?
<emersion>
wlroots
<emersion>
+ sway
<zubzub>
is it a reparenting WM?
<emersion>
no
<zubzub>
that's why it works
<emersion>
i see
<zubzub>
Java has ugly hacks to behave differently under reparenting WMs
<jadahl>
iirc doesn't mess with OR positions
<jadahl>
iirc *mutter*
<jadahl>
OR windows are not reparented
<jadahl>
they never get any decorations
<jadahl>
and iirc mutter doesn't reparent OR. I have a vague memory xfwm4 does. ofourdan might know
<zzag>
neither does kwin. the only reason it keeps track of OR windows is because of compositing
<pq>
Does weston re-parent O-R then?
<zubzub>
no
<zubzub>
neither do I
<pq>
did you actually check the X11 window tree that the O-R is really not reparented?
flibitijibibo has quit [Remote host closed the connection]
<pq>
hmm?
<emersion>
romangg: ^
flibitijibibo has joined #wayland
<emersion>
just some WIP MR so that we can have more concrete things to talk about
<zubzub>
pq: if the OR menu was reparented shouldnt it simply become part of the pixel content of the parent window in wayland terms
<zubzub>
because not it clearly lives in it's own surface (as it is drawn outside it's toplevel window)
<zubzub>
s/not/now
<pq>
zubzub, yes. Only the children of the root window become wl_surfaces, IIRC.
<pq>
reparenting means the WM creates a new Window, and makes that the app Window's parent, adjusting size so that the app window is completely visible.
xexaxo has joined #wayland
<zubzub>
yes I know, I wrote one in Java in a dark past ;)
<pq>
I'm not sure why you talk about parenting to the app main window then
<zubzub>
parenting on a WM protocol level
<pq>
what do you mean?
<zubzub>
a transient property has a parent window id which can be it's parent without it being an X window parent
<pq>
yes
<zubzub>
the menu popup has a transient property with a toplevel window id, but the menu popup has the root window as it's X window parent
<pq>
and that's something the WM must implement, since the X server does not. X server does only parenting, not transient-for.
<zubzub>
yes
<pq>
transient-for is not parenting
<zubzub>
not on a X11 protocol level indeed
<pq>
when talking about A and B, it helps to call them Bob and Alice, not Bob and Bob. ;-)
<pq>
*the other Bob
<zubzub>
:x
<pq>
so, I'm still puzzled on how O-R + transient-for is expected to work, since one says "WM does not touch" and the other is implementable only by the WM. :-)
<zubzub>
it might still be unrelated and it's still a mistery why menus are broken :(
<pq>
hence you'd need an old-timer X11 dev, not us :-D
<zubzub>
doesn't say anything about position, just to keep it above the transient_for window
<pq>
good, but no cigar
<zubzub>
:shrug_emoji:
<ofourdan>
zubzub: it's usually either O-R *or* transient-for, but noaadays with X11 window managers acting as compositors as well, those need to be aware of O-R windows
<ofourdan>
transient-for really is just an indication for window managers, it's an X11 property
<ofourdan>
and some window managers can just chose to ignore the transient relationship that the client specifies
<pq>
just like a Wayland compositor can choose to paint a clown face in place of a window? I.e. allowed, totally possible, but users won't like it. :-)
<ofourdan>
transient relationship can quickly turn quite complex if you add the concept of transient for groupm and also that transient windows can be transient for other transient windows, etc. - so not all window managers implement support for transients the same
<ofourdan>
most window managers will chose to stack transient windows with their "parent" (which is the confusing, because it;s not parent in the sense of X11, it;s the *logical* parent of the transient window)
<ofourdan>
so basically XReparentWindow is an X11 concept, putting an X11 window as a child of antoher X11 window in the X11 window hierarch, whereas transient for is a window manager concept, so that the window manager can keep windows together in the window stack of toplevel windows
<zubzub>
I'm beginning to think the transient trail is a dead end in my quest for working menu popup placement in jetbrains ides
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
luna_ has joined #wayland
alan has quit [Ping timeout: 480 seconds]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
luna_ has quit [Remote host closed the connection]