Questions and thoughts about input method protocol

[Yichao Yu]

On Fri, Feb 1, 2013 at 9:38 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Fri, 1 Feb 2013 08:39:08 -0500
> Yichao Yu <yyc1992 at gmail.com> wrote:
>
>> On Fri, Feb 1, 2013 at 3:21 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> > On Thu, 31 Jan 2013 17:45:25 -0500
>> > Yichao Yu <yyc1992 at gmail.com> wrote:
>> >
>> >> On Thu, Jan 31, 2013 at 5:19 PM, Pekka Vuorela <pvuorela at iki.fi> wrote:
>> >> > Problem with window titles and all is that they are information not meant to
>> >> > input method. Those are meant for the user and can change any time and to
>> >> > anything. And using those will require application specific logic in the
>> >> > input method, like specific rules for specific application.
>> >> > Don't see that feasible except for very special cases.
>> >>
>> >> They will never change to random things and the only necessary thing
>> >> to do is keyword matching. And it will able to work for most cases
>> >> unless you have a window title like "window 1".
>> >
>> > Hi Yu,
>> >
>> > I have a trivial example of an application that will always have a
>> > random window title: a terminal.
>> >
>> > The window titles of my terminals in X show the current working
>> > directory and some other environment variables. There is no way you can
>> > use the window title to infer anything useful, especially when it is a
>> > matter of user's shell and prompt preferences. It does not say
>> > "terminal" or "bash" anywhere. There is no keyword you could match.
>> > Also, other apps that run in the terminal, may or may not set the window
>> > title to their own random things.
>>
>> You are right about the terminal, although that's not the most
>> important case for this: few people uses input method a lot in a
>> terminal.
>
> No, it's a trivial example. Ah, let's take this email I am writing to
> you. It is in its own window, and the window title is:
> "Re: Questions and thoughts about input method protocol - Compose
> message [Edited]". I'm not sure you could pull any useful information
> from that, either.

"Input method" is a perfect keyword here.

>
>> > Web browsers are actually the same. There is nothing requiring the
>> > browser name or website URL to be in the window title. You simply
>> > cannot trust it. In fact, in many cases on desktop, there can be an
>> > icon next to the title, and in that case it is just waste of space to
>> > have the application name in the window title.
>>
>> Well, since what I mean is not what visually available to the user,
>> rather the title set in the protocol icon shouldn't matter, plus the
>
> That's a sentence I do not understand ^...

nvm. I thought you mean the icon may be included in the title or sth
like that.... "the program name is available from somewhere else" is
really what I want to say here.

>
>> program name is also directly available (for the compositor) so the
>> program name is not what a  input method may need from the title(or
>> other context strings) but what's really inside if the application can
>> be used in different ways. It is indeed not 100% reliable, more on
>> this below.
>
> Indeed, you are not interested in the window title per se but something
> else.

And the title is just a good fallback for most cases.

>
>> > As you are now creating a new common protocol, you have a chance to
>> > design things to be reliable from the start. If you need more
>> > information from clients, add explicit protocol for it, and specify
>> > exactly what you want, and how it can be used.
>>
>> Does what I mentioned in the previous email sound any better for you
>> (the three thing an input method will need that I can come up with
>> now)? Well what I really mean is the window title is really useful as
>> a fallback of the context string. It will indeed be better if the
>> application is willing to set a better one.
>
> Do you refer to the following quote?
>

Exactly.

>
> On Fri, 1 Feb 2013 08:23:35 -0500
> Yichao Yu <yyc1992 at gmail.com> wrote:
>
>> It's not a direct map, rather a hint. Some protocol like a
>> context_string and a url will be good. Having that on top of a
>> key-value protocol can give better flexibility.
>>
>> To clarify what a input method will need and why, here is a short list
>> of them with explanation.
>> 1. pid: this is already used now to provide per-program input state.
>> (It's not related to context aware input and isn't a hack at all. I
>> put it here mainly because it is something a input method needs to
>> know that is not yet possible.)
>> 2. program name: something that can be directly know from that which
>> may be useful is categories of the program from the desktop file.
>> 3. context string(s): in most cases, the window title will be really
>> good enough. For a browser, this may be the title of the webpage, url,
>> or other info from the page describing what the page is all about.
>
> Yeah, except not window title. Pid you probably do not need as is, but
> the executable name, right? The .desktop file may be available via

Actually both. The pre-program actually means per-process.

> wl_shell_surface protocol to the compositor. You still have to specify

Yes, that's why I think these can be sent out by the compositor.

> what your context strings are, and how they will be used. Or are they
> just opaque identifiers (for what?). I don't really know the input
> method stuff, but I do know Wayland in general.

I cannot give a exact definition right now but the example you give
(email and it's title) is actually a good one. Other examples include
abstract/title of webpage/document, url etc.

>
> I have casually read this discussion you all have been having on the
> mailing list, and I haven't seen too explicitly mentioned, when you are
> talking about compositor <-> IM daemon protocol, or public compositor
> <-> client protocol. You don't have to explain for my sake, I just
> hope you are not mixing up protocols. I already am confused. :-)

I am not a expert on names, sorry if that causes any confusion :P . I
think a "client" here means a im-client (which is also a wayland
client) and although a input method is also a wayland client, it
should be refer to as "input method". The weston im-protocol is IMHO
really a protocol between the im-client and the input method. The only
non-im-related protocol I have mentioned is the protocol for the
compositor to get window title and program name from the im-client.

For this specific problem of sending additional information what I
mean is the im-client sending these information over the client side
im-protocol (text_model?) as well as general information over the
general wayland protocol (program name for example) and the input
method receiving these information (as well as sth like pid which the
compositor can directly know without the im-client sending it out)
from the input_method side im-protocol (input_method_context). Any
other confusion?

>
>
> Thanks,
> pq