So, hello. I am going to complain about where land and about input methods. Yeah,
complain about wayland and this is kind of graphic room. Graphics room, but I'm not going
to go to talk about graphics. Graphics is the output. I'm more interested in input. Input
methods. Who of you has ever used an input method to hands up? How the crap? I was like
trying to make a point. No more questions. Who is using it regularly? Okay, that's a bit better.
I'm still impressed. Even better impressed with what I will sell later. Back then, we had x
got replaced by wayland and with wayland came some changes. We still wanted to support input
methods, but we had to use different mechanisms. Then, with x so, you had to build it up from scratch.
And someone did it, like there was an institutional implementation. The initial implementation was
not great. Well, it was not perfect. It was not perfect, but it had some problems, some imperfections,
it had some missing features. I'm not going to go into details, but someone pointed out those
issues. Hey, maybe we can do better. And the people who did that, some of them were,
without the necessary experience, maybe incompetence. There's out of that, where three protocols,
texting put V3, input method V2 and virtual keyboard. That didn't solve the problem. The
protocols still had broken features, like with the edge cases that don't work. Some of the
features were kind of bad, but you could work around them and some of nice things. They were just
not there. And I come in and I asked, and let's could you please fund my work? Maybe I can make it
better? And then let's say yes, and I'm here now. That was almost a year ago. So, I started fixing things.
One of the things that I tried to fix was deleting text. The deleting text had a problem. In the
protocols, if existing protocols, if it was even specified, it was deleting text by bytes.
Before bytes, how many before the cursor to delete and how many after the cursor to delete. And this
leads to problems. In the heavy path, it's time. In the heavy path, you have a text, the application
tells the input method. This is the current text that I have. The input method is free to delete
one by turn of text. What happens? What happens? Something gets deleted. So, we have one character
less. That's good. But the way land is distributed protocol is asynchronous. Something can happen
while something else is happening. So, when the input method gets a, get the notification of the
text, maybe the text is already different for some other reason. Maybe it came out like a backspace,
the backspace from the keyboard. The evil keyboard messes up our deletion because the update
doesn't reach the input method in time. And the message tries to delete something. What happens
here? Anyone can anyone see the problem? Hands up if you see the problem. Thank you. See,
it's a UTF. It's not an ASCII character. It takes up two bytes. So, you're going to try to delete
one byte. And this is where things blow up because if you try to delete one byte over two byte
character, you end up in an invalid UTFH string and game over. So, this is like one corner case.
I decided this cannot be. So, instead, let's, it's not void. So, let's just delete entire
characters or something. So, that was that synchronization. It's kind of similar to the issue
where things happen at the same time. You want to synchronize it. I tried to find solutions. I tried
to do like retransmission stuff. It was so complicated. I had my Zen moment. The best code is code that
is not written at all. And I decided to just say ignore it. No, no problem. It's going to be a
problem of the user if something comes out wrong. And I think that might actually work. It took
three attempts until I reached enlightenment. So, kind of that's pop up. That wasn't really
amazing. The pop up couldn't be positioned with the previous implementations. So, I fixed it.
It took another two attempts. Whoa, what did I do? Whoa. That went too far. Anyway, keyboard filtering.
If you are typing your text in Chinese or Japanese or Korean, you don't want that text to end up
in your input field immediately. You want the text to be held up by the input method. Like here,
you type into the input method and it just presents the suggestion to the application. So, I had to
it actually sounds a lot simpler than it is. It took three attempts with two complete implementations.
And focusing. This is a screenshot from my phone. There is like a suggestion where some of the text
is in so-called pre-edits mode. It's a candidate of what might be input. And in this case,
what happens if I try to unfocus it? I try to like switch the next text field. So, the applications
are, I'm going to just throw it because you didn't confirm it. This is not what Korean users expect.
Korean users want to input their text. And what they have right now, if they change focus,
the applications should keep it. It's all in under control of the applications. So, you need to tell
the application how to deal with it. This also needs to be implemented as a wayland protocol.
When on protocols is a repository and free desktop, which takes care of gathering things,
where all the protocols, the input method protocols existing are. And this is where the fixes go.
So, well and protocols has this very smart way of dealing with things. If the works,
don't break it. So, modifications are kind of conservative. It has its downsides because if we want,
if you know that the protocols are already broken, it takes a very long time to do something about it.
This is a screenshot from yesterday. There wasn't times two, there isn't a time two,
fixed the protocols. But it has not been merged despite being there for two years. And those are the
things that everyone is supposed to be agreeing on. The conservativeness is maybe not so great.
But, well and protocols, the maintainers, they agree that maybe sometimes they are a little slow.
So, they opened a new experimental path. It is better in the way that it allows
expectations, which you can have your protocol upstream two weeks after submitting, which is great.
The protocol doesn't have to be super backwards compatible. But, if you don't do anything with
the protocol after 13 months, we can just delete it. I managed to use this path to merge three
protocols. So, it actually kind of works. But, how do I do it? So, I don't just ask to merge
a draft. That would be kind of rude because, yeah, how do I, how do I prove that it is a good thing?
So, first I draft, then I collect feedback. Then I try to implement a demo. And in the process,
I usually find out that something will run with a draft. So, I dated draft and I tried to
implement it, then I collect approval. And I asked to merge this protocol. And I lied a little
bit here. One of those points doesn't happen, which one? Hands up for the number.
Most of you guessed correctly. I said to say, but I haven't heard, I don't recall hearing one
example of, yes, please merge it. This doesn't happen. So, I have my suspicion that people
don't care that much about my work. And looking at this, I think people don't care about input
methods in general. It takes two years to merge things that everyone is on board with. I don't know.
Let's check it out. This is a timeline of the protocol. Initially in 2018, the fixing effort
started. It was implemented in Weroots in GTK upstream. In 2024, that proposal that I just showed you appeared.
2026, well, it took six years to fix a broken protocol. And it takes two years to implement the things.
There's also the side of how are people implementing this in actual products. In Chromium, 2021,
first Apache appeared. The Apache got merged in 2025, partially because everyone knew that it was
broken and they were reluctant to merge it. So, maybe there's something missing. Maybe the
right people are not working on it. The right person would have user experience. They would actually
know what the user needs. And maybe they are going to need some skill to actually pull it off.
Right away, I'm protocol, right implementations, and they also need interest. Maybe I've
fixed them personally. Maybe they're getting paid by LLET. Or maybe they feel guilty about
sucking it up in the first place because that that was me kind of. Not even enough. This all has
to come at the same time. One person is not enough. One person who's like great is not going to
pull it off if the protocol affects the entire ecosystem. So, you need multiple people at the same
time who have all those skills to build a trust. This protocol is going to work. This is actually
not going to break things worse. Those are all the necessary checks that need some political
capital to pass. They are necessary. But it also means that it's hard to do something as a one
person. I'm not seeing a lot of people that are working on this at the same time. I am seeing people
which have user experience. They are using the input methods every day and have to skill
but they are doing something else. I know people who have like who leaves like enthusiastic
comments on the B-shoot tracker, but they don't like any sense at all. They have no skill.
And there's me. I have the interest. I have the skill. I don't even use any of the methods.
I like this is what you get people. I'm sorry. I'm the worst person to do it, but this is all you
have right now. Yeah, and I'm making, makes me wonder, like where are all the people? This is
affecting a billion people in China. I'm sure that some of them have all three qualities. Where
are they? And my suspicion is maybe maybe we're developing this in a Western context. And this is
like a barrier that we can't cross. Maybe they're different culture approaches do that. Maybe there
is maybe they're all stuck in on the X11 that they are happy with it. I don't know. It's
happening behind the great firewall because it's difficult to talk to those people. I don't know
any Chinese. And maybe there's a language barrier. And what about Linux Mobile? There should be a
bunch of people who have the skill. Maybe they just don't have interest. Maybe that just works.
Well, I don't know. Please, please help me. Anyway, all right, the kid, the kid is me and the
other kid that I presented earlier, they won about incompetence. And yeah, incompetence and
lack of experience, that was also me. I fucked this up. Just full disclosure. I'm,
I'm responsible for this. But like implementations, I see like a very similar thing with implementations.
But first off, how does it look like? You need the input method, you need applications, and you need
the composer to let them talk together. The basic I already told you, well, I'm protocols.
Rust bindings. So back in 2019, when I implemented this first, I used to see, because that was
the language for GTK and for dev downloads. And people were finding bugs half a year after I was finished.
Then I decided, I am too stupid to write C. Now I wrote everything in Rust. So, full disclosure.
I wrote an input method in Rust. I used the flow in library for application, like just a demo to
test things with, and I used and will as the composer. So those are the layers. There's a lot
of the quite a lot. What's in between the middle where there is a, okay, that's count. One, two, three,
four, five, six projects that I had to contribute to to get anything working. That is kind of a lot.
And yeah, how did it go? Under one year, I merged three experimental protocols. I made 53 changes.
Some of that didn't go through. Some of them were 36 of them were upstream. I opened seven
issues and I was across six projects. I think it's not bad, but it is not enough. It is not enough
to let people try this out. It's not enough for you to build it without spending a lot of effort
trying to build all this crap. And there is a problem. I mean, yes, those are the protocols,
those are the efforts, but there's a chicken and egg problem. People say, yes, we are going to
start implementing this. Once it is tested a bit more. Once we know that this is the right thing,
but people are not going to be testing this in everyday life until it's implemented. So I don't
know. I think we should as developers try to implement, please implement my crap. This is,
this is me crying. Please implement this. Please implement this because it's a group effort.
We need to implement this in order for this to take off. Those are experimental protocols.
You can implement them alongside existing ones. So it doesn't necessarily break the existing stuff.
We just have to do it. We have to give the user slags. We have to give the user a quick ability
to test this out. I don't count on cute or gdk to implement it now, but like smaller libraries,
maybe we can try and test it. I didn't have the time to make all implementations,
but with some, I had better success with some, I had less success.
Yeah, so I'm going to clean this up. Honestly, I'm tired of this and I need to hold it.
Yeah, it's not really finished, but I need the rest of the community to step up and help me
finish this up. I will be able to like, get feedback, but I'm not going to spend a huge amount
of time coding anymore. And it doesn't catch up. You remember, well, I'm protocols had three months
timeout for protocols. If there is no activity, well, there's just going to clean it up,
and the effort is going to be wasted, which would be a shame. But thankfully,
the analytics grant is not over yet. It goes until June. And I can include you in background.
I can like kind of hire you or something. There is still a bunch of money for upstreaming.
Like, I took care of most of drafting, but upstreaming, please come into me, speak to me.
We can find something out. If you know Rust, if you will, maybe you're willing to learn Rust, I don't know.
If you know Wayland, this could be upstream. It could be like, I could use some negotiation
with other people. If you are a user, you could maybe try to be nice and not overly enthusiastic,
and comment on the issue tracker. Yes, I would like it for this way or that way. I don't know.
So yeah, that was basically the status before I try to push the project away and work
on something else. Thank you.
There's a question. So you spoke last year, right?
I believe I did speak last year.
Can you say that? That was it?
I promise, I did say that this was the end. I promise this time it's not, it is actually the end,
like soft end, but it is the end. So I don't want to be enthusiastic. Thank you very much for working with us.
Thank you for thanking me.
Thank you.
Do you see a lot of improvements in feedback or upstreaming or whatever as well
it gets more and more used for people?
Is there improvement in feedback or upstreaming?
I don't know. I think it would be pretty similar to 2019, but it would be people who were
more enthusiastic back then because they didn't realize that I am very good at hacking things up.
I'm not sure. Because like you say wayland is being used more now,
I am not really observing that. Maybe that makes people more careful because they don't want
a broken protocol to make people unhappy. They don't want to make a broken protocol
make customers unhappy. This was the conversation I had today with the PopOS developer.
The people, if we start breaking things, if you start adding experimental things,
we are going to have more complaints for the customers and that is actually a negative thing
for trying to make big changes.
What kind of feedback would be useful to me from users?
Ideally, some kind of user would come to me and ask me how do I build this to test it out?
That would be pretty much the best feedback. The problem is, in order to work with this,
you also need an input method. I try to build my own demo and the input method is not really
usable. It's so slow because I'm not an expert in this on like graphical building a graphic
application from scratch. The users can't really give me great feedback in terms of testing things
and testing things would be the best feedback. I would need to get a first to get some authors
of input methods on board. As a user, you come with the ability to say what you need.
Maybe if you look at the protocol and if you're able to understand the purpose of the protocol,
you can say yes, I want this protocol, yes, I want this feature.
I think that would be not like a groundbreaking piece of feedback but it would send a message to people
who are the main painters of the protocols that there is an interest and maybe some effort
would be put into it. I don't know if it would be working actually.
Wasn't the main goal of the unstable protocol to have some way
and that because in the past it was implemented by the toolkit directly, like GTK,
as it's on custom protocol to do the IMF to IME code. Same thing for Q.
I think, yeah, I mean, you can kind of on the architecture level level do it either way. I don't
think the toolkits do not want to do it on their own anymore.
So the idea has shifted from the toolkit does it to the toolkit talks to the compositor and the
compositor does it. That's my understanding.
Yeah, it's why there's not much adoption but most of the way in compositor already use a specific toolkit.
So there's no change for the user. So you're saying maybe that's the reason there's no adoption
that the toolkit are already doing this and I would say I don't think so because I have seen
the great adoption of the broken protocol already. Like pretty much everything moved to the broken
protocol. That means they are not interested in doing the toolkits are not interested in doing
their own thing anymore. So fixing this is actually important because people are using this. They
want to use it. It's just not great.
I made a question here so I kind of got lost there but was there, was there any point to doing
the 3.2 version or was that also technically broken? Is there any point in doing 3.2 version
or is it still broken? No, I don't think that 3.2 is like fundamentally broken. The effort is
right. I gave a little bit of feedback and the feedback seems to be like just hanging there.
It seems that there is also suffering from the same problem that there's not enough interest to
actually fix it and put it through.
So the question is about the key repeats on the client. I did include a provision for like
repeating keys in the keyboard filtering protocol but otherwise it's not really
part of what an input method does. It would be an issue with an issue with the toolkits. I don't know.
I would have to look at it. I never dealt with it.
Yeah. You mentioned when it's mobile? Yes. When I think of it, it would method or I mean
I see like the policy show for example. Yes. How does that relate to the keyboard on the phone?
This is a great question because I forgot. Linux mobile, Linux mobile, how does it relate to input methods?
In Linux mobile or an Android or iOS, you have a panel which serves as a kind of thing that
includes text. It's not a keyboard because the phone doesn't have a keyboard and it is not
forwarding kernels. The kernel events to the composer. It has to be generated in a special way.
So like the input panel for the keyboard where the keys change like the submit keys sometimes it's
magnifying glass sometimes it's something else and it doesn't really do the same thing
all the time. It changes layers dynamically. This is something that falls into the input method
concept that we are employing here in a way laden. Or like swiping keyboards. T9 or T9.
One of the demos that I might in my input method is T9.
Looks like I exhausted you. Sorry.
Do I want a user story? Of course I do.
I think matter would be in the way itself. I don't think this adds thing.
You need a protocol for this but I don't know what those things use for all the time.
They could use an input method. They could use like pen.
Right. So I think there would be one more way to do it but it wouldn't get in the way.
Thank you and of time.