Re: [PATCH v4 wayland-protocols] text: Create second version of text input protocol

[Rui Tiago Cação Matos]

On Wed, Feb 17, 2016 at 6:13 AM, Jan Arne Petersen  wrote:
>>> +
...
>>> +  
>>> +  
>>> +  
>>> +  
>>
>> These arguments could, and perhaps should, all be type="uint"
>
> Yes I guess for width/height.

As Jonas pointed out, just leave them as "int". One thing I now
noticed is that the text says the coordinates are relative to the
surface but I think it's better to be explicit and use the main
wayland protocol terms "surface local coordinates" i.e. the
coordinates should take the surface scale into account.


>>> +
...
> It is used to be able to interact with pre-edit text (move the cursor
> within pre-edit text or touch-and-hold to get some more options).

Aren't those client side operations? This request just doesn't seem
right in this protocol. Perhaps it belongs in a different protocol for
specific environments/devices? The text protocol should be strictly
about text input IMO.


>>> +
...
> Yes we have the text focus in cases there is no keyboard available
> (currently there is no way to have a focus then).
>
> It does not make sense to have text and keyboard focus on different
> surfaces at least not for the same seat. I do not see any case where you
> would want hardware keyboard input and virtual keyboard input going into
> different widgets/surfaces at the same time.

Perhaps it doesn't make sense but I don't see why we need to tie them
up here, just like wl_pointer's focus isn't necessarily tied to
wl_keyboard's focus in the main protocol.

In practice, sure, compositors will likely keep them all synced. In
any case, the sentence

"When the seat has one or more keyboards the text-input focus follows
the keyboard focus."

can't be worded like that because, again, even if a seat doesn't have
a hardware keyboard, the wl_keyboard object (and its focus) may exist
anyway. At least, it needs to be changed to

"The seat's text-input focus follows the keyboard focus."

if we indeed want to specify that they must be tied.

>>> +
>>> +
...
> wl_keyboard currently does not allow to send synthetic key events when
> you want to just send keysyms.

Why do we need to send keysyms though? Isn't it enough to commit
(single character) strings?


Rui
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v4 wayland-protocols] text: Create second version of text input protocol

[Rui Tiago Cação Matos]

Hi,

Thanks for the update. I'm replying to both v4 and your reply to my
previous mail. Inline:

On Tue, Feb 2, 2016 at 2:33 PM, Jan Arne Petersen  wrote:
> +
> +  
> +   Disable text input in a surface (typically when there is no focus on 
> any
> +   text entry inside the surface).
> +  
> +  
> +

This seems fine. But just to clarify. It's perfectly valid for an
application to never call the disable request even if it loses focus
on an enabled surface. Right?

> +
> +  
> +   Sets the content purpose and content hint. While the purpose is the
> +   basic purpose of an input field, the hint flags allow to modify some
> +   of the behavior.
> +
> +   When no content type is explicitly set, a normal content purpose with
> +   default hints (auto completion, auto correction, auto capitalization)
> +   should be assumed.

On Tue, Feb 2, 2016 at 1:26 PM, Jan Arne Petersen  wrote:
> Yes, they might be not relevant for all input methods. Removed the
> defaults,

They are still there though. I think that when unset this should
default to "normal" purpose and "none" hint.

> which should be handled by toolkits (what to set when nothing
> special is specified on an input widget).

Sure, toolkits, or clients in general, might always default on their
side to always call this request but that's beyond the protocol. What
the protocol needs to be clear about is what's assumed by the
compositor/IM when clients don't make this request.

In fact, that brings up another issue: _when_ does the compositor/IM
revert to the default purpose and hints? Does it revert when the text
input focus moves to a different wl_surface? Is it kept since it was
last set for all wl_surfaces of a particular client? Does it revert
when a client calls "update_state" ? There's several options here.

> +
> +  
> +   Sets the cursor outline as a rectangle relative to the surface.
> +
> +   Allows the compositor to put a window with word suggestions near the
> +   cursor.
> +  
> +  
> +  
> +  
> +  

These arguments could, and perhaps should, all be type="uint" .

> +
> +  
> +   Sets a specific language. This allows for example a virtual keyboard 
> to
> +   show a language specific layout. The "language" argument is a RFC-3066
> +   format language tag.
> +
> +   It could be used for example in a word processor to indicate language 
> of
> +   currently edited document or in an instant message application which
> +   tracks languages of contacts.
> +  

I think this request also needs to specify when the preferred language
reverts to the unset state.

> +
> +  
> +   Defines the reason for sending an updated state.
> +  
> +  
> +  
> +  
> +  
> +
> +
> +
> +  
> +   Allows to atomically send state updates from client.
> +
> +   This request should follow after a batch of state updating requests
> +   like set_surrounding_text, set_content_type, set_cursor_rectangle and
> +   set_preferred_language.
> +
> +   The flags field indicates why an updated state is sent to the input
> +   method.
> +
> +   Reset should be used by an editor widget after the text was changed
> +   outside of the normal input method flow.
> +
> +   For "change" it is enough to send the changed state, else the full
> +   state should be send.
> +  
> +  
> +  
> +

I don't understand how the "flags" argument is useful. Can you give
examples of how it would change anything for the compositor/IM ?

I think this request should also specify all, if any, transient state
that should be considered reset after it. E.g. content hints and
purpose, preferred language, etc.

> +
> +  
> +   Allows to invoke an action when tapping or clicking the currently
> +   composed word in the text input.
> +
> +   This can be used by input methods to offer more word suggestions.
> +  
> +  
> +  
> +

This is still underspecified. What is button and index? Is there a
list of actions missing? Can you provide us with the use case you have
in mind for this?

> +
> +  
> +   Notification that this seat's text-input focus is on a certain 
> surface.
> +
> +   When the seat has one or more keyboards the text-input focus follows 
> the
> +   keyboard focus.

There might or might not be a keyboard focus. Sure, if a compositor
has both a keyboard focus and a text focus, it makes sense for the
compositor to set both together to the same surface but that's not
necessary and I don't see any reason why we should tangle them in the
protocol.

> +
> +

Let's discuss these two together (btw, if they stay in the protocol,
they should be moved to be together IMO).

On Tue, Feb 2, 2016 at 1:26 PM, Jan Arne Petersen  wrote:
> There might be no hardware keyboard 

Re: [PATCH v4 wayland-protocols] text: Create second version of text input protocol

[Rui Tiago Cação Matos]

On Mon, Feb 8, 2016 at 7:07 PM, Bill Spitzak  wrote:
> The x and y have to be signed. Imagine if the client is scrolled in such a
> way that the cursor rectangle is partially outside the surface.

Are you saying this is an acceptable case:

++
|compositor popup|
++

  +---+
  | surface w/|
  | scrolled  |
  | contents  |
  +---+

I would expect the application to scroll its contents automatically so
that the cursor is visible on the surface...

Rui
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols] text: Create second version of text input protocol

[Rui Tiago Cação Matos]

Hi,

thanks for sending this. I was actually going to start a discussion
about the existing protocol but let's go from here instead. Comments
inline:

First a question of scope: a client would only ever need to instance
one text_input object per wl_seat and then "associate" it with a
particular wl_surface through the activate request. Am I right?

Not having a destroy request isn't so bad if that's the intended scope
but I think we should still have one.

On Thu, Jan 28, 2016 at 8:52 AM, Jan Arne Petersen  wrote:
> +  Text is generally UTF-8 encoded, indices and lengths are in bytes.

Why bytes instead of characters? It seems to me that using characters
is less error prone since an offset in bytes might end up in the
middle of an UTF-8 encoded character.

> +  Serials are used to synchronize the state between the text input and
> +  an input method. New serials are sent by the text input in the
> +  commit_state request and are used by the input method to indicate
> +  the known text input state in evsents like preedit_string, 
> commit_string,
> +  and keysym. The text input can then ignore events from the input method
> +  which are based on an outdated state (for example after a reset).

Any particular reason for serials to be generated and controlled by
clients? For the intended use case it seems ok but it's odd when
compared with other serials in wayland.

> +
> +  
> +   Requests input panels (virtual keyboard) to show.
> +  
> +
> +
> +  
> +   Requests input panels (virtual keyboard) to hide.
> +  
> +

Do we really need these requests? Isn't the fact that a text input is
currently active enough for the compositor/IM to decide on its own if
it should show an input panel?

> +
> +  
> +   Should be called by an editor widget when the input state should be
> +   reset, for example after the text was changed outside of the normal
> +   input method flow.
> +  
> +

Shouldn't this have a serial argument if we go with client controlled serials?

Otherwise reset could remain like this but adding specification to
what happens with serials sent in events from this point onwards.

> +
> +  
> +   Sets the content purpose and content hint. While the purpose is the
> +   basic purpose of an input field, the hint flags allow to modify some
> +   of the behavior.
> +
> +   When no content type is explicitly set, a normal content purpose with
> +   default hints (auto completion, auto correction, auto capitalization)
> +   should be assumed.

No strong opinion, particularly since these are just hints and thus
compositors/IMs are free to ignore them (right?), but I think the
default should be "none".

> +
> +  
> +  
> +  
> +  
> +

This needs specification. Why is it a rectangle and what does it
represent exactly? Are the coordinates relative to the activated
wl_surface? What are compositors expected to do with it?

> +
> +  
> +   Defines the reason for sending an updated state.
> +  
> +  
> +  
> +  
> +  
> +
> +
> +  
> +  
> +

This seems very underspecified. Care to elaborate how it's supposed to be used?

> +
> +  
> +  
> +

Underspecified.

> +
> +  
> +   Notification that this seat's text-input focus is on a certain 
> surface.
> +
> +   When the seat has one or more keyboards the text-input focus follows 
> the
> +   keyboard focus.

Wayland clients aren't aware of how many hardware keyboards exist. In
fact there might be none and a compositor is still free to advertise
the keyboard capability and assign keyboard focus (e.g. a touch screen
only device). I don't think we should mention wl_keyboard at all. Just
say that each wl_seat has a text-input focus and this is the enter
event for said focus.

> +
> +  
> +   Transfer an array of 0-terminated modifiers names. The position in
> +   the array is the index of the modifier as used in the modifiers
> +   bitmask in the keysym event.
> +  
> +  
> +

What's the purpose of this event?

> +
> +  
> +   Notify when the visibility state of the input panel changed.
> +  
> +  
> +

Unsure if we need this event at all. But if we do, it must at least
specify that this event will only be sent if this client currently
holds the text-input focus and the type should be be an enum.

> +
> +  
> +   Notify when a new composing text (pre-edit) should be set around the
> +   current cursor position. Any previously set composing text should
> +   be removed.

Should that read: "Any previously set _preedit_ text should be removed" ?

> +   The commit text can be used to replace the preedit text on reset

Can? I think this should be a "should" like below.

> +   The text input should also handle all preedit_style and 

Re: [PATCH libinput] evdev: set CLOCK_MONOTONIC as the time source

[Rui Tiago Cação Matos]

On 19 February 2014 13:35, Daniel Stone dan...@fooishbar.org wrote:
 Can this be CLOCK_MONOTONIC_COARSE instead, to avoid griefing HPET and
 thus causing much higher power usage?

Makes sense and indeed the X server seems to use _COARSE if it's
available and has good enough resolution:

http://cgit.freedesktop.org/xorg/xserver/tree/os/utils.c#n440

Perhaps libevdev should do something like that too?

Rui
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 1/2] Hook up libevdev as backend

[Rui Tiago Cação Matos]

On 18 February 2014 07:09, Peter Hutterer peter.hutte...@who-t.net wrote:
 libevdev wraps the various peculiarities of the evdev kernel API into a
 type-safe API. It also buffers the device so checking for specific features at
 a later time is easier than re-issuing the ioctls. Plus, it gives us almost
 free support for SYN_DROPPED events (in the following patch).

 This patch switches all the bit checks over to libevdev and leaves the event
 processing as-is. Makes it easier to review.

This looks fine to me. Can we also add a

libevdev_set_clock_id(device-evdev, CLOCK_MONOTONIC);

on device creation? CLOCK_MONOTONIC is already a hard dependency in
configure.ac and it's required for good interoperability between
xwayland (which uses it for its time stamps) and mutter.

Rui
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xwayland: Handle the wl_keyboard modifiers event

[Rui Tiago Cação Matos]

Hi,

this patch still applies after the xwayland branch rebase. Pinging for review.

Thanks,
Rui

On 22 October 2013 16:52, Rui Matos tiagoma...@gmail.com wrote:
 This allows us to keep track of latched and locked modifiers as well
 as the XKB group while the keyboard focus is on another wayland
 client. Note that we don't need to track depressed modifiers since
 wayland guarantees that we'll get them as key press events whenever
 we get the keyboard focus.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] input: Don't leak the initial keymap

[Rui Tiago Cação Matos]

Review ping.

On 24 October 2013 19:28, Rui Matos tiagoma...@gmail.com wrote:
 weston_xkb_info_create() takes ownership of the xkb_keymap instance so
 we should drop our reference or we would leak it later if the keymap
 was changed.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: XWayland security, equals to X11 or Wayland?

[Rui Tiago Cação Matos]

On 3 January 2014 20:59, Tobias Sarnowski tob...@sarnowski.io wrote:
 does XWayland operate? From the highlevel documentation at
 http://wayland.freedesktop.org/xserver.html I conclude, that the X11 support
 is done via having a single Wayland client which then multiplexes the stuff
 internally to all X11 clients. So my guess is, that all X11 applications
 that work via XWayland have access to eachother but not other native Wayland
 clients.

This is correct.

 Or are the X11 clients already separated ike Wayland clients, so
 that this security aspect is already solved for those?

I don't think this can be done without breaking X11 clients, so it
will remain like that.

Rui
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Making Wayland accessible

[Rui Tiago Cação Matos]

Hi,

just replying to this part:

On 15 October 2013 22:05, Matthias Clasen matthias.cla...@gmail.com wrote:
 - input tweaks like slow keys or bounce keys or hover-to-click naturally fit
 in the event dispatching in the compositor

In the same spirit of having key repeat on the client side, I think
that slow, bounce and sticky keys should also be implemented by the
clients. Doing these on the compositor would in particular make things
more complex for xwayland which (I assume) should continue to provide
these features for X clients while being a regular wl_keyboard client
itself.

MouseKeys though, seems like it can be implemented in the wayland
compositor and we should probably remove the functionality from
xwayland. Hover-to-click can be done in the compositor as well.

Rui
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] Add a way to update the keymap

[Rui Tiago Cação Matos]

Hi,

On 7 October 2013 16:27, Daniel Stone dan...@fooishbar.org wrote:
 But I'm really not sure about this.  It's really hard to get this
 right, especially when you're changing modifier options.  The only
 real workable solution I've seen is to pend the actual change until
 all keys have been released.  So, in this case, if any keys are down,
 just drop the keymap into a separate pending_keymap pointer and have
 notify_key() check for pending_keymap and do the actual change after
 the last key release.

Makes sense. Should be working like this now.

Thanks,
Rui
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] Add a way to update the keymap

[Rui Tiago Cação Matos]

Hi,

On 7 October 2013 20:16, Ran Benita ran...@gmail.com wrote:
 At least retaining the locked modifiers (and therefore the LED state in
 most cases) would be nice, and not too problematic I think (though some
 edge cases are expected).

Ok, the new version keeps both latched and locked modifiers.

 (Also, the keymap updating in compositor-x11 is currently not optimal, we
 should really be listening for XKB protocol events rather than the
 rules property changes. But this is pending an XCB release at least,
 which I can only hope will happen sometime this decade :)

Hmm, is there even a way to get the RMLVO from the server with XKB? I
thought the root window property was the only way to get it. Even
setxkbmap calls XkbRF_SetNamesProp() and uses the property all over.

Thanks,
Rui
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Wayland Window Management Proposal

[Rui Tiago Cação Matos]

On 13 May 2011 18:59, Mike Paquette paquette...@gmail.com wrote:
 I hope you guys don't mind my chiming in here.

Speaking only for myself as mostly a lurker on this list, I very much
welcome your insightful and experienced remarks. Thanks for sharing!

 The way I handled a window resize was to grow or shrink the window buffer and 
 onscreen region  as requested by the client, mark it as invalid, and hold off 
 on compositing it until the app indicated the buffer was valid, or had good 
 content again.  A timer in the server acted as a backup for this, to allow 
 display update treating the window as containing only the background or 
 autofill color for compositing purposes, so things like running an app under 
 the debugger wouldn't render the display unusable.  The compositor treated an 
 'invalid' buffer as being a 1x1 pixel buffer holding the background/autofill 
 color, scaled up to the onscreen window size.

 The window resize request could specify that content was to be preserved 
 relative to the window origin with new content areas autofilled with the 
 background color, or the buffer would just be filled with the autofill color, 
 or that the buffer would be left as-is because the app would completely 
 repaint the content (as-is could look pretty bad if not repainted, what with 
 the wrong rowbyte values and all...).

 It did take a bit of work to convince a few app developers that when they 
 resized a window, they should immediately fix up the content without 
 wandering off to query the odd remote database, but the majority of apps 
 appeared to be ready to redraw content promptly on doing a resize.

Completely agree. The compositor/WM has no business in working around
application bugs. If application programmers are lazy and can't get
their windows acting timely on input then, the ecosystem (users,
distributors) will just naturally select those apps out and the well
behaved ones will just be more popular.

Hiding badly designed applications' problems is just rewarding bad
work and, in this case, it's even worse. If the compositor acts on
input before the application draws the final frame it will create
graphical flashes (background color, autofill, junk, whatever) for
*every* application which actually penalizes the good ones because the
graphical glitch will be there, even if for a single frame, since this
is inherently how server side asynchronous actions behave.

Rui
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel