Questions and thoughts about input method protocol

[Pekka Paalanen]

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.

> > 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 ^...

> 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.

> > 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?


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
wl_shell_surface protocol to the compositor. You still have to specify
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 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. :-)


Thanks,
pq