<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 2, 2016 at 4:58 AM, Jan Arne Petersen <span dir="ltr"><<a href="mailto:janarne@gmail.com" target="_blank">janarne@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
<br>
On 29/01/16 00:33, Bill Spitzak wrote:<br>
><br>
><br>
> On Wed, Jan 27, 2016 at 11:52 PM, Jan Arne Petersen <<a href="mailto:janarne@gmail.com">janarne@gmail.com</a><br>
</span><span class="">> <mailto:<a href="mailto:janarne@gmail.com">janarne@gmail.com</a>>> wrote:<br>
><br>
><br>
> + Text is generally UTF-8 encoded, indices and lengths are in<br>
> bytes.<br>
><br>
><br>
> Remove the word "generally". *All* text in your api's are UTF-8.<br>
<br>
</span>Done<br>
<span class=""><br>
> + <request name="activate"><br>
> + <description summary="request activation"><br>
> + Requests to activate a surface for text input (typically when a<br>
> + text entry in it gets focus).<br>
> +<br>
> + There can only be one active surface per client and seat.<br>
> When surface is<br>
> + null all surfaces of the client get deactivated.<br>
> + </description><br>
><br>
><br>
> I think clients should be allowed to send activate more than once per<br>
> surface, it is to indicate the input focus switching between widgets.<br>
> This removes the need for another api to indicate the widget is<br>
> switching. Sending null for the surface, or a different event, would<br>
> indicate that the keyboard focus is no longer on a text input widget.<br>
<br>
</span>We use enable/disable request now. That should be a bit easier to handle<br>
from client side.<br>
<span class=""><br>
> + <request name="reset"><br>
> + <description summary="reset"><br>
> + Should be called by an editor widget when the input state<br>
> should be<br>
> + reset, for example after the text was changed outside of the<br>
> normal<br>
> + input method flow.<br>
> + </description><br>
> + </request><br>
><br>
><br>
> I believe this request can be replaced by redundant activate requests.<br>
<br>
</span>It got integrated into update_state.<br>
<div><div class="h5"><br>
> + <request name="set_surrounding_text"><br>
> + <description summary="sets the surrounding text"><br>
> + Sets the plain surrounding text around the input position.<br>
> Text is<br>
> + UTF-8 encoded. Cursor is the byte offset within the<br>
> + surrounding text. Anchor is the byte offset of the<br>
> + selection anchor within the surrounding text. If there is no<br>
> selected<br>
> + text anchor is the same as cursor.<br>
> + </description><br>
> + <arg name="text" type="string"/><br>
> + <arg name="cursor" type="uint"/><br>
> + <arg name="anchor" type="uint"/><br>
> + </request><br>
><br>
><br>
> The anchor could be very far away from the cursor, much farther than any<br>
> small limit on the request size. I think this means the anchor position<br>
> could be negative or larger than the text length. Sending this without<br>
> clamping would be a good idea, the input method would then have a hint<br>
> where the anchor is, and it can clamp the value itself.<br>
><br>
> If the client wants new text to replace the selected text, the text<br>
> between anchor+cursor will be deleted, and any input method decisions<br>
> would depend on the text outside the anchor..cursor range. This may be<br>
> larger than the allowed buffer size, so I think clients have to send the<br>
> text as though the selection was deleted.<br>
><br>
> A client that does not want to replace the selected text could still<br>
> send an anchor, but then I am not clear if the input method can take<br>
> advantage of knowing what characters are selected to modify the results.<br>
> So it is possible the anchor is not needed at all.<br>
<br>
</div></div>Ok I use an int for anchor now. It still make sense for an input method<br>
to know what is in the selection even when it gets replaced by new<br>
entered text.<br></blockquote><div><br></div><div>I am unclear whether it is the input method's job to decide whether characters replace the selection, or the client's job.</div><div><br></div><div>My concern is this:</div><div><br></div><div>- The input method has rules so that if the text before the cursor is "A" and the user types 'x', you get "Ay". If the text is any other letter such as "C" you get "Cx".</div><div><br></div><div>- Assume the text before the cursor is "Annnnnnnnn" where all the 'n' are selected, and the length of the selection exceeds the size allowed by the surrounding text request. Therefore the input method cannot know there is an 'A' there.</div><div><br></div><div>- The user types 'x'. The input method cannot be aware that there is an A there and the result will be "Ax", not the correct "Ay".</div><div><br></div><div>My proposed solution is that the client decides whether input replaces the selection or is appended to it. If it replaces the selection, the text it sends the input method is with the selection already deleted.</div><div><br></div><div>Other solution is that the above situation does not happen in real input methods.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br>
> I think you might want non-zero bits to *disable* features. This allows<br>
> zero to be the default, and means that if some new correction is<br>
> invented in the future then they can default to on without you having to<br>
> modify the numerical value of default.<br>
<br>
</span>Toolkits need to handle default on client side now.<br></blockquote><div><br></div><div>I'm concerned that the value of "default" should not change. Assuming most toolkits choose default, it should not vary depending on when the toolkit was compiled.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Yes you do not want to show already typed text on a virtual keyboard in<br>
a password field. Usually the keyboard would show nothing then, no<br>
reason to show dots/stars on the virtual keyboard.<br></blockquote><div><br></div><div>I would assume it is considered better to use preedit than to have a virtual keyboard with it's own display, but I guess this is useful if somebody insists on making the keyboard work that way.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> + <request name="invoke_action"><br>
> + <arg name="button" type="uint"/><br>
> + <arg name="index" type="uint"/><br>
> + </request><br>
><br>
><br>
> Missing documentation? I would guess this is how clients send the<br>
> keyboard events to the input method?<br>
<br>
</span>Added description. It is about clicking/touching within the<br>
composing/pre-edit text.<br></blockquote><div><br></div><div>Makes sense. I think this could also be used to invoke the spelling corrector if the user clicks in previous incorrect text.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Added more description to v3:<br>
<br>
default: "default style for composing text"<br>
none: "composing text should be shown the same as non-composing text"<br>
active: "composing text might be bold"<br>
inactive: "composing text might be cursive"<br>
highlight: "composing text might have a different background color"<br>
underline: "composing text might be underlined"<br>
selection: "composing text should be shown the same as selected text"<br>
incorrect: "composing text might be underlined with a red wavy line"<br></blockquote><div><br></div><div>I think I asked the question a bit wrong. The input method may be relying on the user being able to distinguish two different highlights, and this assumption would fail if a client renders them the same. Are there any pairs of these numbers the client is allowed to render the same (for instance default and none, can they be rendered identically?).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> Can more than one of these be applied to the same bytes? If so, are they<br>
> allowed to intersect arbitrarily? I think it is reasonable to require<br>
> the input method to require any ranges to be entirely inside or outside<br>
> each previously-sent ranges. This makes it easier for a client to<br>
> mindlessly insert <b> and </b> tags into pango input.<br>
<br>
</span>It might make sense to combine some so I do not want to exclude that.<br></blockquote><div><br></div><div>Yes I agree combining them is required. My question is whether the input method should be restricted to simple nesting. For instance if it wants a region of active that intersects a region of highlight, it is not allowed to do this:</div><div><br></div><div> active range = 1..5<br></div><div> highlight range = 3..7</div><div><br></div><div>Instead it must do this, so the highlight ranges do not cross previous boundaries:</div><div><br></div><div><div> active range = 1..5</div><div> highlight range = 3..5</div></div><div> highlight range = 6..7</div><div><br></div><div>I believe if clients are allowed to assume this it will make their job easier.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> + <event name="keysym"><br>
> + <description summary="keysym"><br>
> + Notify when a key event was sent. Key events should not be used<br>
> + for normal text input operations, which should be done with<br>
> + commit_string, delete_surrounding_text, etc. The key event<br>
> follows<br>
> + the wl_keyboard key event convention. Sym is a XKB keysym,<br>
> state a<br>
> + wl_keyboard key_state. Modifiers are a mask for effective<br>
> modifiers<br>
> + (where the modifier indices are set by the modifiers_map event)<br>
> + </description><br>
> + <arg name="serial" type="uint" summary="serial of the latest<br>
> known text input state"/><br>
> + <arg name="time" type="uint"/><br>
> + <arg name="sym" type="uint"/><br>
> + <arg name="state" type="uint"/><br>
> + <arg name="modifiers" type="uint"/><br>
> + </event><br>
><br>
> Is this for keysyms that the input method did not handle? Or for fake<br>
> key strokes? Or both?<br>
<br>
</span>For synthetic key events (fake stroke) for unhandled real hardware key<br>
events wl_keyboard should be used (keyboard focus is the same as text<br>
focus).<br></blockquote><div><br></div><div>How does the compositor prevent wl_keyboard events it used from being sent to the client? What if the input method wants to handle the 'x' key itself, but send the 'xy' combination to the client? It will have to eat the x-down event, and then send a fake one just before the y-down???</div><div><br></div><div>I figured the input method would get all the keyboard events and would call this with unhandled keystrokes.</div><div><br></div><div>I personally feel that Wayland will need to add an api that is more like this, rather than clients running libxkb. It would solve all these problems, and also make it far easier on remote desktop clients on systems where you cannot get the keystrokes except in already-cooked form, and for utilities that insert fake keystrokes. However I have been repeatedly told that this is "impossible", for some reason having to do with multiple keymaps (??). If you are able to get this in, then good for you. First step toward fixing this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Yes that is more for use cases like you switch the input method in while<br>
a text field is focussed and the new input method needs the state.<br>
(Else we would need to cache state on compositor side which I do not like)<br></blockquote><div><br></div><div>This seems reasonable. It is trivial for a client to send the surrounding text an extra time.</div><div><br></div><div>To prevent the client from sending surround text requests that are ignored, I guess the input method should send a configure indicating that no text is needed, then change it just before sending this event.</div><div><br></div></div></div></div>