Re: Orbital 0.1
> > [0]: http://min.us/m7qsx2pHqpImB > > [1]: http://www.youtube.com/watch?v=bd1hguj2bPE > > > > Giulio > > Looks great, thanks for sharing! Agree, good work. But what *is* orbit and the other thing, in a single sentence? Compiz-ng? ciao Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: Payload size and text.xml in weston
On Mon, 2013-12-16 at 11:52 +0900, Elvis Lee(KwangWoong Lee) wrote: > I just started to feel that something is wrong on our implementation. > Anyway let me explain current state. > > 'set_surrounding_text' carries whole text of input box(UX). Now it's > used to support an action 'clear all' with Maliit virtual keyboard. > 'Clear all' means to delete whole text in the input box. So the > IME(VKB) needs to know whole length of the contents in the box. Hm no. 'Clear all' is the equivalent of sending an empty commit string or synthesizing an input method event that carries an empty commit string on the client side. Cursor position and offset for the commit string can just be set to min/max int. That way there is no need to compute the additional information ;-) > Also I thought(felt) that 'set_surrounding_text' is for text > selection. If it is, what happens when user drags whole text in an > input box? set_surrounding_text is sensitive to the cursor position. If there's no cursor then there is no (valid) surrounding text. > I didn’t get this part. - Read: client-side decision/controlled by UI > toolkit. > Is it a document? Ah sorry, I meant 'Read: …' as an alternative explanation, in the sense of "With other words, …". ciao Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Accessibility] Need to be able to register for key events globally
Hi, On Tue, 2013-12-17 at 11:23 +0100, Piñeiro wrote: > Well, if we can consider an on-screen keyboard, or a screen reader > trusted clients, but we can't consider as a trusted client the daemon > providing accessibility services, then we have a problem. A bridge to connect existing accessibility services with Wayland is the logical first step. But I wouldn't stop there. > In any case, my conclusion from these two emails is that in order to get > those features we would need to define some wayland extensions, no > matters if is Orca or at-spi2 the one using it. > > So with all that in mind, what about a plan like this: > a) Start to write accessibility-specific wayland extensions > a.1) Start to implement them on a compositors (first on Weston?) > b) Meanwhile investigate if it is possible to add security policies on > at-spi2, so this can be the trusted client using those extensions. > b.1) If that fails, Orca would be the trusted client using those > extensions > > Thoughts? I'd use the opportunity and design accessibility for the layer below UI toolkits instead of adding it on top. UI toolkits that adopt Wayland will also adopt common and useful extensions. Being able to design the Wayland input method protocol with transaction semantics in mind helped to create a more robust solution when compared to traditional input contexts. Accessibility is a great deal more complex. Better protocol semantics could improve usability in the long term. For instance, one could make Wayland clients announce accessibility-relevant objects (and their properties) to the compositor instead of having to rely on introspecting client objects. Yes this will break stuff but Wayland already made that decision. ciao Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Payload size and text.xml in weston
On Thu, 2013-12-12 at 18:23 -0600, Jason Ekstrand wrote: > Elvis, > > On Dec 12, 2013 2:08 AM, "Elvis Lee(KwangWoong Lee)" > wrote: > > While using text protocol in Weston, we encountered some cases which > exceeds the limitation. > > > > For example, "set_surrounding_text" carries a string which is longer > than 1024 bytes. Surround text is usually the current paragraph or sentence. Use-case is text prediction via text n-grams for instance, which only needs a few neighboring words to work out. I'd be curious to know which use-cases you tried to implement to hit the buffer limit. That is, if you can disclose them of course. > > 1. Restricts input size of text box in UX. That's a property of the text editor, not necessarily the input method. Read: client-side decision/controlled by UI toolkit. > > > > 2. Restricts the string size of “set_surrounding_text”. (Then > how can I handle delete_surrounding_text properly?) Could you please explain in more detail? Sounds as if you think some parameter or such is missing. There's always the possibility we got some details wrong when designing the protocol ;-) ciao Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: weston and hardware keyboard
On Mon, 2013-06-17 at 18:08 +0200, Marc Chalain wrote: > Hello, > My first observation is we need a PC keyboard support at the end > ( often a virtual keyboard). There's an input method procotol that we intended to use for virtual keyboards. Try weston's clients/editor.c together with the example keyboard. You can plug in your own by changing [input-method] in weston.ini for instance. Sending key events should be the exception when using a virtual keyboard. Instead, we rely on input method events to input text. But even then clients will have to parse those rare key events. ciao Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Compiling weston now needs colord
On Tue, 2013-05-28 at 22:16 -0700, Bill Spitzak wrote: > Running autogen.sh in weston with --disable-colord works to avoid this, > I suspect nothing I care about is lost this way. I ran into the very same problems. I would have preferred if such new dependencies were optional or if someone would explain what we will miss if we disable them. For colord, trying to build the latest required version from git just pulls in more dependencies that you also have to build from git (as Bill mentioned). It's kind of frustrating, even if weston is meant to be a playground and thus new dependencies have to be expected. http://wayland.freedesktop.org/building.html should be updated I guess? ciao Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] text: Respawn input method process if it exits
On Tue, 2013-05-14 at 12:16 -0300, Eduardo Lima (Etrunko) wrote:
> +static void launch_input_method(struct text_backend *text_backend);
> +
> static void
> handle_input_method_sigchld(struct weston_process *process, int status)
> {
> + uint32_t time;
> struct text_backend *text_backend =
> container_of(process, struct text_backend,
> input_method.process);
>
> text_backend->input_method.process.pid = 0;
> text_backend->input_method.client = NULL;
> +
> + /* if input_method dies more than 5 times in 10 seconds, give up */
> + time = weston_compositor_get_time();
> + if (time - text_backend->input_method.deathstamp > 1) {
> + text_backend->input_method.deathstamp = time;
> + text_backend->input_method.deathcount = 0;
> + }
> +
> + text_backend->input_method.deathcount++;
> + if (text_backend->input_method.deathcount > 5) {
> + weston_log("weston-desktop-shell died, giving up.\n");
Wrong log message, should be "input_method died, giving up.\n"
> + return;
> + }
> +
> + weston_log("input_method died, respawning...\n");
> + launch_input_method(text_backend);
I am not smart enough to figure out whether this could be abused to
launch a (possibly untrusted) 3rd party input method at runtime, say by
manipulating some cached config and then triggering a crash in the input
method.
ciao Michael
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Hawaii is usable now
On Mon, 2013-04-01 at 16:46 +0200, Pier Luigi wrote: > Hi, > > Hawaii is a lightweight desktop environment for Wayland written using > QtQuick 2.x. Very nice! Do you have a recent screencast for http://www.youtube.com/user/mauidesktop perhaps? ciao Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland] client: Invoke new_id closure arguments as pointers instead of integers
Could we get this merged please? It fixes an annoying crasher bug for us
(see FDO#62367).
Thanks,
Michael
On Fri, 2013-03-08 at 18:44 +0100, Jonas Ådahl wrote:
> This commit adds a flags parameter to wl_closure_invoke(). The so far
> added flags are ment to specify if the invokation is client side or
> server side. When on the server side, closure arguments of type 'new_id'
> should be invoked as a integer id while on the client side they should
> be invoked as a pointer to a proxy object.
>
> This fixes a bug happening when the address of a client side 'new_id'
> proxy object did not fit in a 32 bit integer.
>
> Signed-off-by: Jonas Ådahl
> ---
> src/connection.c | 16 +++-
> src/wayland-client.c |2 +-
> src/wayland-private.h |7 ++-
> src/wayland-server.c |2 +-
> 4 files changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/src/connection.c b/src/connection.c
> index e6c2b64..b952da1 100644
> --- a/src/connection.c
> +++ b/src/connection.c
> @@ -801,7 +801,8 @@ wl_closure_lookup_objects(struct wl_closure *closure,
> struct wl_map *objects)
> }
>
> static void
> -convert_arguments_to_ffi(const char *signature, union wl_argument *args,
> +convert_arguments_to_ffi(const char *signature, uint32_t flags,
> + union wl_argument *args,
>int count, ffi_type **ffi_types, void** ffi_args)
> {
> int i;
> @@ -834,8 +835,13 @@ convert_arguments_to_ffi(const char *signature, union
> wl_argument *args,
> ffi_args[i] = &args[i].o;
> break;
> case 'n':
> - ffi_types[i] = &ffi_type_uint32;
> - ffi_args[i] = &args[i].n;
> + if (flags & WL_CLOSURE_INVOKE_CLIENT) {
> + ffi_types[i] = &ffi_type_pointer;
> + ffi_args[i] = &args[i].o;
> + } else {
> + ffi_types[i] = &ffi_type_uint32;
> + ffi_args[i] = &args[i].n;
> + }
> break;
> case 'a':
> ffi_types[i] = &ffi_type_pointer;
> @@ -855,7 +861,7 @@ convert_arguments_to_ffi(const char *signature, union
> wl_argument *args,
>
>
> void
> -wl_closure_invoke(struct wl_closure *closure,
> +wl_closure_invoke(struct wl_closure *closure, uint32_t flags,
> struct wl_object *target, void (*func)(void), void *data)
> {
> int count;
> @@ -870,7 +876,7 @@ wl_closure_invoke(struct wl_closure *closure,
> ffi_types[1] = &ffi_type_pointer;
> ffi_args[1] = ⌖
>
> - convert_arguments_to_ffi(closure->message->signature, closure->args,
> + convert_arguments_to_ffi(closure->message->signature, flags,
> closure->args,
>count, ffi_types + 2, ffi_args + 2);
>
> ffi_prep_cif(&cif, FFI_DEFAULT_ABI,
> diff --git a/src/wayland-client.c b/src/wayland-client.c
> index 3ead2ac..c5ad96d 100644
> --- a/src/wayland-client.c
> +++ b/src/wayland-client.c
> @@ -836,7 +836,7 @@ dispatch_event(struct wl_display *display, struct
> wl_event_queue *queue)
> if (wl_debug)
> wl_closure_print(closure, &proxy->object, false);
>
> - wl_closure_invoke(closure, &proxy->object,
> + wl_closure_invoke(closure, WL_CLOSURE_INVOKE_CLIENT,
> &proxy->object,
> proxy->object.implementation[opcode],
> proxy->user_data);
> }
> diff --git a/src/wayland-private.h b/src/wayland-private.h
> index f0c9010..4b757a1 100644
> --- a/src/wayland-private.h
> +++ b/src/wayland-private.h
> @@ -129,8 +129,13 @@ wl_connection_demarshal(struct wl_connection *connection,
> int
> wl_closure_lookup_objects(struct wl_closure *closure, struct wl_map
> *objects);
>
> +enum wl_closure_invoke_flag {
> + WL_CLOSURE_INVOKE_CLIENT = (1 << 0),
> + WL_CLOSURE_INVOKE_SERVER = (1 << 1)
> +};
> +
> void
> -wl_closure_invoke(struct wl_closure *closure,
> +wl_closure_invoke(struct wl_closure *closure, uint32_t flags,
> struct wl_object *target, void (*func)(void), void *data);
> int
> wl_closure_send(struct wl_closure *closure, struct wl_connection
> *connection);
> diff --git a/src/wayland-server.c b/src/wayland-server.c
> index 2f3ddc9..aaecf29 100644
> --- a/src/wayland-server.c
> +++ b/src/wayland-server.c
> @@ -277,7 +277,7 @@ wl_client_connection_data(int fd, uint32_t mask, void
> *data)
> if (wl_debug)
> wl_closure_print(closure, object, false);
>
> - wl_closure_invoke(closure, object,
> + wl_closure_invoke(closure, WL_CLOSURE_INVOKE_SERVER, object,
> object->implementation[opcode], client);
>
> wl_closure_destroy(closure);
___
wayl
Re: [PATCH 00/13] Clean up text protocol and move to wayland
On Tue, 2013-02-19 at 23:31 +0200, Pekka Vuorela wrote: > On 19.02.2013 22:11, Jan Arne Petersen wrote: > > With this series we try to get the text protocol into Wayland (so it can > > be supported by toolkits). The input-method protocol for input methods > > is not ready yet and will be included into Wayland later (when it will > > be ready). > > Could perhaps clarify what this means protocol stability-wise. Intention > to merge into Wayland master, but allowed to still be modified until > 1.1(?) is released, or to be stable already when reaching Wayland? At least new API should be no problem. Which API you feel might change still? For instance, I don't believe that the input_panel_surface interface is complete yet. > I do share some concerns with Yichao since this hasn't yet been taken > into use with a basic CJK setup. Every single feature part, of course, > being still huge exaggeration. Not quite, in Weston's repository, there is clients/weston-simple-im.c at least. And Jan Arne is currently looking at ibus integration, too. ciao Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 00/13] Clean up text protocol and move to wayland
On Tue, 2013-02-19 at 14:01 -0500, Yichao Yu wrote: > On Tue, Feb 19, 2013 at 1:26 PM, Jan Arne Petersen > wrote: > > From: Jan Arne Petersen > > > > This series finalizes the first version of the text protocol and > > moves it from Weston to Wayland, so that it can be implemented in > > toolkits. > > Well, the only problem is that this protocol is totally not usable yet > and it lacks every single feature a non-layout input method needs. > Apart from what I have already mentioned ((more important ones first) > tracking input context, cursor following, getting information about > im-clients (pid, appname, context), and not really sure about having > multiple processes drawing the user interface) there is one more > feature that is missing. Is it possible for the im-client to send a > key event that is not previously handled by the input method back to > text_model (or is wl_text_input the new name...)? At least I haven't > found a request on the im-client to send this out... This is really > useful when the text model only get input focus after certain key > event (see pidgin input window as an example). There is no one preventing you from submitting patches. ciao Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Rename text_model and text_model_factory?
On Sat, 2013-02-02 at 13:39 +0100, Michael Hasselmann wrote: > Hi! > > Shouldn't the naming for the complementary interfaces in Weston's > protocol/text.xml and protocol/input-method.xml be more consistent? > > For instance, there's text_model and text_model_factory interfaces in > text.xml, but in input-method.xml, the corresponding interfaces are > called input_method_context (~ text_model) and input_method (~ > text_model_factory). And another inconsistency I just noticed is how some requests have a set_* prefix (set_surrounding_text) whereas others have not (commit_string). Isn't the read/write direction already clear from the event/request separation? Or should we just always prefix requests with set_*? ciao Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Rename text_model and text_model_factory?
Hi! Shouldn't the naming for the complementary interfaces in Weston's protocol/text.xml and protocol/input-method.xml be more consistent? For instance, there's text_model and text_model_factory interfaces in text.xml, but in input-method.xml, the corresponding interfaces are called input_method_context (~ text_model) and input_method (~ text_model_factory). ciao Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC] Add language and text-direction to text protocol
On Thu, 2013-01-31 at 09:33 -0800, Bill Spitzak wrote: > On 01/31/2013 08:44 AM, Jan Arne Petersen wrote: > > From: Jan Arne Petersen > > > > The proposed API allows to send the language and text-direction for > > inserted text from an input-method to an application. > > Can't direction be determined by using Unicode rules on the new text, > with direction override characters if the default rules don't work. This > will allow the input method to return mixed-mode text. I think mixed-mode text is an orthogonal use-case. A common example is mixing "western" numbers (in reality they are Devanagari numbers) with RTL text. You need to place your cursor at the left or right end of a text entry (actually, right or left of the possibly already existing text, on focus-in). An explicit text direction event makes it easier than having to wait and parse for the input method's text (which you can only really do after receiving the commit string, not while showing the preedit string). Without the extra event you have to accept annoying UI adjustments while already typing in text. You are probably right that we could make clever use of existing events instead, but I prefer simple-to-use & robust protocols over clever protocols, even if I pay with redundancy here and there. > This might require the client to send the input method a large block of > "context", such as the entire current paragraph, so that it can figure > out the best insertion text so the direction indicators are right. We already do send surrounding text, no? > Since > it seems to me this context is very useful for other parts of input > methods this may be better than the alternative of the client having to > figure out how to merge the UTF-8 insertion into the existing text. Making use of surrounding text for improving input method enigne results is another orthogonal use-case. The text merging always happens on the client side and is already well-defined with the preedit/commit string interaction. I think it's assumed that Wayland strings represent Unicode. I feel as if I am entirely missing the point you're trying to make. regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 2/5] text: Add commit request
On Thu, 2013-01-31 at 15:52 +0100, Jan Arne Petersen wrote:
> From: Jan Arne Petersen
>
> Allows for atomic state changes. Updated surrounding text, content type
> and micro focus is taken into account all at once at commit.
Does this enforce the atomicity of state changes or does it rely on
well-behaved clients?
> Signed-off-by: Jan Arne Petersen
> ---
> clients/editor.c | 2 ++
> clients/keyboard.c | 35 ---
> clients/weston-simple-im.c | 9 -
> protocol/input-method.xml | 1 +
> protocol/text.xml | 2 ++
> src/text-backend.c | 17 -
> 6 files changed, 53 insertions(+), 13 deletions(-)
>
> diff --git a/clients/editor.c b/clients/editor.c
> index 1eb8f11..5c072f2 100644
> --- a/clients/editor.c
> +++ b/clients/editor.c
> @@ -558,6 +558,8 @@ text_entry_update(struct text_entry *entry)
> entry->text,
> entry->cursor,
> entry->anchor);
> +
> + text_model_commit(entry->model);
> }
>
> static void
> diff --git a/clients/keyboard.c b/clients/keyboard.c
> index 986dcff..8d94870 100644
> --- a/clients/keyboard.c
> +++ b/clients/keyboard.c
> @@ -45,6 +45,7 @@ struct virtual_keyboard {
> uint32_t serial;
> uint32_t content_hint;
> uint32_t content_purpose;
> + char *surrounding_text;
> struct window *window;
> struct widget *widget;
> };
> @@ -496,17 +497,9 @@ input_method_context_surrounding_text(void *data,
> uint32_t anchor)
> {
> struct virtual_keyboard *keyboard = data;
> - const struct layout *layout;
> -
> - layout = get_current_layout(keyboard);
> -
> - fprintf(stderr, "Surrounding text updated: %s\n", text);
> -
> - window_schedule_resize(keyboard->window,
> -layout->columns * key_width,
> -layout->rows * key_height);
>
> - widget_schedule_redraw(keyboard->widget);
> + free(keyboard->surrounding_text);
> + keyboard->surrounding_text = strdup(text);
> }
>
> static void
> @@ -559,11 +552,31 @@ input_method_context_invoke_action(void *data,
> virtual_keyboard_send_preedit(keyboard, index);
> }
>
> +static void
> +input_method_context_commit(void *data,
> + struct input_method_context *context)
> +{
> + struct virtual_keyboard *keyboard = data;
> + const struct layout *layout;
> +
> + layout = get_current_layout(keyboard);
> +
> + if (keyboard->surrounding_text)
> + fprintf(stderr, "Surrounding text updated: %s\n",
> keyboard->surrounding_text);
> +
> + window_schedule_resize(keyboard->window,
> +layout->columns * key_width,
> +layout->rows * key_height);
> +
> + widget_schedule_redraw(keyboard->widget);
> +}
> +
> static const struct input_method_context_listener
> input_method_context_listener = {
> input_method_context_surrounding_text,
> input_method_context_reset,
> input_method_context_content_type,
> - input_method_context_invoke_action
> + input_method_context_invoke_action,
> + input_method_context_commit
> };
>
> static void
> diff --git a/clients/weston-simple-im.c b/clients/weston-simple-im.c
> index d038382..fab7fc5 100644
> --- a/clients/weston-simple-im.c
> +++ b/clients/weston-simple-im.c
> @@ -140,11 +140,18 @@ input_method_context_invoke_action(void *data,
> {
> }
>
> +static void
> +input_method_context_commit(void *data,
> + struct input_method_context *context)
> +{
> +}
> +
> static const struct input_method_context_listener
> input_method_context_listener = {
> input_method_context_surrounding_text,
> input_method_context_reset,
> input_method_context_content_type,
> - input_method_context_invoke_action
> + input_method_context_invoke_action,
> + input_method_context_commit
> };
>
> static void
> diff --git a/protocol/input-method.xml b/protocol/input-method.xml
> index b4ffa72..690aee1 100644
> --- a/protocol/input-method.xml
> +++ b/protocol/input-method.xml
> @@ -131,6 +131,7 @@
>
>
>
> +
>
>
>
> diff --git a/protocol/text.xml b/protocol/text.xml
> index 8004f91..7fdbcf1 100644
> --- a/protocol/text.xml
> +++ b/protocol/text.xml
> @@ -138,6 +138,8 @@
>
>
>
> +
> +
>
>
> Notify when text should be inserted into the editor widget. The text
> diff --git a/src/text-backend.c b/src/text-backend.c
> index c7761a9..f096a9b 100644
> --- a/src/text-backend.c
> +++ b/src/text-backend.c
> @@ -257,6 +257,20 @@ text_model_invoke_action(struct wl_client *client,
> }
> }
>
> +static void
> +text_model_commit(struct wl_client *client,
> + struct wl_resource *resource)
> +{
> + st
Re: FOSDEM2013: DevRoom or not?
On Fri, 2012-09-28 at 23:51 +0200, Luc Verhaegen wrote: > We still have, i hope (depends on what the FOSDEM organizers have left > for us), 6 slots fully open: first come first serve, and the earlier > bird gets the nicer slot! > > Thanks all, especially those who stepped up already. What's the deadline for session proposals? https://fosdem.org/2013/news/2012-11-18-announcing-devrooms/ mentions the X.org devroom but no link to an announcement mail nor a deadline. Does that mean you won't accept any further session proposals? ciao Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] text: Rename de/activate to enter/leave
On Mon, 2012-09-24 at 14:51 +0200, Jan Arne Petersen wrote:
> + if (surface != window_get_wl_surface(entry->window))
> + return;
> +
not what the git message says ("text") -- this is a functional change
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH v2 16/17] text: Add support for control keys to the protocol
On Sun, 2012-09-09 at 23:08 +0200, Jan Arne Petersen wrote:
> From: Jan Arne Petersen
>
> Add key event to the text_model interface and a key request to the
> input_method_context interface. Implement it in the example editor
> client and the example keyboard.
Could mention why you introduced it:
Not every key event can be easily applied to the text model, because the
current input context APIs in toolkits don't reveal enough information
about the text editor. We cannot sanely predict the result of pressing
the enter key or even the arrow keys on a virtual keyboard for instance,
simply because we miss the information how the text is layouted (and
where to break lines).
Also, one should note that this *can* be used to transmit hardware
keyboard events. There is opt-in for the application (as originally
proposed): The behaviour will entirely depend on the chosen input method
and applications (toolkits, rather) will always have to process the key
events even when making use of the text model otherwise.
> Signed-off-by: Jan Arne Petersen
> ---
> clients/editor.c | 25 -
> clients/keyboard.c| 4
> protocol/input-method.xml | 4
> protocol/text.xml | 5 -
> src/text-backend.c| 14 +-
> tests/test-text-client.c | 6 --
> 6 files changed, 53 insertions(+), 5 deletions(-)
>
> diff --git a/clients/editor.c b/clients/editor.c
> index 0ed217f..2baf6af 100644
> --- a/clients/editor.c
> +++ b/clients/editor.c
> @@ -284,8 +284,31 @@ text_model_preedit_styling(void *data,
>
> static void
> text_model_key(void *data,
> -struct text_model *text_model)
> +struct text_model *text_model,
> + uint32_t key,
> + uint32_t state)
> {
> + const char *state_label;
> + const char *key_label;
> +
> + if (state == WL_KEYBOARD_KEY_STATE_PRESSED) {
> + state_label = "pressed";
> + } else {
> + state_label = "released";
> + }
> +
> + switch (key) {
> + case XKB_KEY_Tab:
> + key_label = "Tab";
> + break;
> + case XKB_KEY_KP_Enter:
> + key_label = "Enter";
> + break;
> + default:
> + key_label = "Unknown";
> + }
> +
> + fprintf(stderr, "%s key was %s.\n", key_label, state_label);
> }
>
> static void
> diff --git a/clients/keyboard.c b/clients/keyboard.c
> index 588ef78..0cbf531 100644
> --- a/clients/keyboard.c
> +++ b/clients/keyboard.c
> @@ -228,6 +228,8 @@ keyboard_handle_key(struct keyboard *keyboard, const
> struct key *key)
> }
> break;
> case keytype_enter:
> + input_method_context_key(keyboard->keyboard->context,
> + XKB_KEY_KP_Enter,
> WL_KEYBOARD_KEY_STATE_PRESSED);
> break;
> case keytype_space:
> keyboard->keyboard->preedit_string =
> strcat(keyboard->keyboard->preedit_string,
> @@ -250,6 +252,8 @@ keyboard_handle_key(struct keyboard *keyboard, const
> struct key *key)
> case keytype_symbols:
> break;
> case keytype_tab:
> + input_method_context_key(keyboard->keyboard->context,
> + XKB_KEY_Tab,
> WL_KEYBOARD_KEY_STATE_PRESSED);
> break;
> }
> }
> diff --git a/protocol/input-method.xml b/protocol/input-method.xml
> index 10ca32a..100fa46 100644
> --- a/protocol/input-method.xml
> +++ b/protocol/input-method.xml
> @@ -53,6 +53,10 @@
>
>
>
> +
> +
> +
> +
>
>
> The plain surrounding text around the input position. Cursor is the
> diff --git a/protocol/text.xml b/protocol/text.xml
> index 3d7d8f5..62746d3 100644
> --- a/protocol/text.xml
> +++ b/protocol/text.xml
> @@ -89,7 +89,10 @@
>
>
>
> -
> +
> +
> +
> +
>
>
>
> diff --git a/src/text-backend.c b/src/text-backend.c
> index b2f9094..0a93b6b 100644
> --- a/src/text-backend.c
> +++ b/src/text-backend.c
> @@ -316,11 +316,23 @@ input_method_context_delete_surrounding_text(struct
> wl_client *client,
> text_model_send_delete_surrounding_text(&context->model->resource,
> index, length);
> }
>
> +static void
> +input_method_context_key(struct wl_client *client,
> + struct wl_resource *resource,
> + uint32_t key,
> + uint32_t state)
> +{
> + struct input_method_context *context = resource->data;
> +
> + text_model_send_key(&context->model->resource, key, state);
> +}
> +
> static const struct input_method_context_interface
> input_method_context_implementation = {
> input_method_context_destroy,
> i
Re: Input method and input/output redirect under wayland
On Mon, 2012-08-27 at 21:02 -0400, Yichao Yu wrote: > Hi, > > How can the proposed input method system[1] support the input method > server drawing a window around the cursor for user interaction? Best to check Weston keyboard example: http://cgit.freedesktop.org/wayland/weston/tree/clients/keyboard.c That's a client that draws a virtual keyboard and uses the mentioned input method protocols, yet at the same time draws like a regular client (into a special surface). > For some input method (especially for CJK), it is important to have > some user interaction before some text is finally committed (e.g. > there might be more than one candidate words for a single input > string), and for better user experience, it is important to show this > window (for user interaction) closed to the cursor and in a way > consistent with the input window. Yes, pre-edit support. Work in progress. > Moreover, since wayland support input and output redirection, the > window (although it might be a rectangle for the client) might not > appears to be a normal rectangle on the screen. Special cases. Instead of sending a rectangle, we could always send a region instead. I am not worried about that right now. regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 3/3] text: Add some documentation to the text protocol.
On Tue, 2012-08-21 at 18:28 +0200, Jan Arne Petersen wrote: > From: Jan Arne Petersen > + > + A model for text input. Adds support for text input and input methods > to > + applications. A text_model object is created from a text_model_factory > and > + corresponds typically to a text entry in an application. Requests are > used > + to activate/deactivate the model and set informations like surrounding > and > + selected text or the content type. The information about entered text > is > + sent to the model via the preedit and commit events. > + I think this paragraph deserves a more high-level introduction, because the concept we introduce here is a somewhat new approach: Traditionally, applications (or the toolkit in use) would assume they process hardware events directly and try to compose text from that. With the text model, for the majority of use-cases, this should no longer be necessary. A regular text editor should work by just using this protocol, without direct hardware event processing. This is also what we try to prove in the Weston example, no? > > > > @@ -7,10 +15,21 @@ > > > > + > +Requests the model to be activated (typically when the text entry > gets > +focus). The seat argument is a wl_seat which maintains the focus for > +this activation. The surface argument is a wl_surface assigned to the > +model and tracked for focus lost. > + If it is a request, you should perhaps explain under which condition it can get rejected. I can imagine that the compositor would deny activation of a text model that is bound to an invisible surface. Also mention that upon successful activation, you'll get the activated event (but perhaps that's already so well established as a general concept in Wayland we don't have to mention it all the time). > > > > > + Wrong summary. > + > + > +Notify the model when it is deactivated. Either in response to a > +deactivate request or when the assigned surface lost focus or was > + destroyed. > + > + So when would a surface lose focus? Please list some cases. > > > > + > + A factory for text models. This object is a singleton global. > + Allows the compositor to keep track of issued text models, right? Perhaps mention why we do that. > > + > + Corresponds to a text model on input method side. An input method > context > + is created on text mode activation on the input method side. It allows > to > + receive information about the text model from the application via > events. > + Input method contexts do not keep state after deactivation and should > be > + destroyed after deactivation is handled. > + Could make it a bit more visual by writing: "input_method_context mirrors the text_model on the input method side. Requests become events and events become requests. > + > + An input method object is responsible to compose text in repsonse to typo --^ > + input from hardware or virtual keyboards. There is one input method > + object per seat. On activate there is a new input method context object > + created which allows the input method to communicate with the text > model. > + ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] compositor: Simple key repeat implementation.
On Thu, 2012-03-08 at 14:52 +0100, Joakim Sindholt wrote: > On Wed, 2012-03-07 at 15:21 -0700, Scott Moreau wrote: > > There's nothing fancy about this, we just set a timer and simulate > > events using states 2 and 3 for repeat-up and repeat-down events. > > Any particular reason that this is in the server and not the toolkits? > I'm of the persuasion that wayland should just function as a relay here. Why? You might be convinced already, but that's not an argument in itself, unless you present the reasons and use-cases that convinced you ;-) regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC] compositor: Simple key repeat implementation.
On Wed, 2012-03-07 at 15:35 -0700, Scott Moreau wrote: > > > On Wed, Mar 7, 2012 at 3:27 PM, Daniel Stone > wrote: > Hi, > > On 7 March 2012 22:21, Scott Moreau wrote: > > There's nothing fancy about this, we just set a timer and > simulate > > events using states 2 and 3 for repeat-up and repeat-down > events. > > > Did you think about just using a single event, rather than the > separate repeat press/release events? If nothing else, it > saves > clients the hassle of processing two events they know are > always > guaranteed to immediately follow each other ... > > Cheers, > Daniel > > > If it doesn't cause a problem, we can do whatever is best. After all, > it's a single line change here. The difference is that press-press-press-release is detectable as auto-repeat by the client, whereas press-release-press-release-press-release is not. Toolkits might need that information. regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Designing an input method system for Wayland
Hi, I wrote down an initial design proposal [P] that would allow integration of input methods with Wayland. I worked on text input methods for the Nokia N9, for the last two years, so that's where I am coming from. I think we can basically break it down to two additional Wayland protocols, and lots of prototyping. The proposal is quite long, so I tried to summarize the important aspects in a blog post [B]. There are many open questions still, so if you want to provide feedback, you can do that directly on the wiki, on this ML, or in the comment section of the blog post. regards, Michael [P] https://wiki.maliit.org/Wayland_Input_Method_System_Proposal [B] http://mikhas.posterous.com/designing-an-input-method-system-for-wayland ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 0/3] Resubmit - Unit test framework for Wayland
On Thu, 2012-03-01 at 22:34 -0500, Kristian Høgsberg wrote: > Hi Artie, > > Thanks for starting this. Looks good and certainly when we start > adding tests for some of the more complex objects and data structures > in the library (wl_map would be a good next step), it will be a good > way to avoid regressing functionality. I'm not convinced that we > really need an external unit testing framework though. All each TESTS > binary need to do is to test something and fail or succeed. We can > add a little test helper to provide the fail_if() etc functions. I found that a good testing framework can lower the barrier of writing useful tests. Nice logging and status reports are important I feel. And if for example you can easily write data driven tests, then testing all possible code paths in a critical area becomes straight-forward and the tests will remain readable (and with that, maintainable; people tend forget that every test also adds to the overall maintenance costs which can often enough outweight the benefits of the test). It's actually the one thing I really like about Qt's testlib. If a testing framework even goes so far to allow fuzz testing out of the box, then you have a nice sanity check for your APIs. I have no experience in writing a testlib, but I would assume it's a non-trivial task. regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC] protocol: add xslt stylesheet to prettify the protocol
On Fri, 2012-02-24 at 17:42 +1000, Peter Hutterer wrote: > I've played around a bit today and the result is this: > http://people.freedesktop.org/~whot/Wayland/tmp/en-US/html/ The blue text for type names etc. is a bit confusing, in the sense that they are not links. regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC] protocol: add xslt stylesheet to prettify the protocol
On Thu, 2012-02-23 at 16:26 -0500, Kristian Hoegsberg wrote: > On Thu, Feb 23, 2012 at 03:58:37PM +1000, Peter Hutterer wrote: > > Includes rudimentary styling only. > > > > Signed-off-by: Peter Hutterer > > --- > > A few things to note: > > - I'm not a designer > > - Having a html version of the protocol makes it a lot easier to read, and > > it certainly reveals missing bits of documentation in the protocol > > - the .css file is the one from wayland.freedesktop.org, someone could > > easily fix it to prettify the result a bit. > > That is very nice. As part of 1.0, we need to figure out a way to > combine the protocol and the spec document into something like docbook > and make pdf and html versions. I don't think we want to stick with latex. Mallard comes to mind: http://projectmallard.org/ regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH RFC] protocol: add xslt stylesheet to prettify the protocol
On Thu, 2012-02-23 at 21:20 +1000, Peter Hutterer wrote: > On 23/02/12 19:57 , Tiago Vignatti wrote: > > On 02/23/2012 07:58 AM, Peter Hutterer wrote: > >> Includes rudimentary styling only. > >> > >> Signed-off-by: Peter Hutterer > >> --- > >> A few things to note: > >> - I'm not a designer > >> - Having a html version of the protocol makes it a lot easier to read, > >> and > >> it certainly reveals missing bits of documentation in the protocol > >> - the .css file is the one from wayland.freedesktop.org, someone could > >> easily fix it to prettify the result a bit. > > > > I concur we need a prettier way to read the protocol. But what do you > > think about the idea of dumping the whole protocol in a separate section > > of main.tex instead? > > largely depends on what you expect the canonical source to be. shouldn't > be that hard to knock up another xslt that converts the xml into latex. I would prefer HTML over Latex. Especially if the resulting HTML is hosted as some form of online documentation. regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Passive and active attacks via X11. Is Wayland any better?
On Fri, 2012-02-17 at 12:05 -0800, Bill Spitzak wrote: > Kristian Høgsberg wrote: > > >> 1) Are you planning to support on-screen keyboard apps? If so, how this > >> is going to be implemented, so that a malicious/compromised app couldn't > >> act as such "on-screen keyboard" and inject keystrokes to other apps? > > > > We can restrict access to functionality on a per-application basis. > > An on-screen keyboard would be part of the core ui and launched by the > > compositor in a way that gives it access to the "input event > > injecting" interface. > > I think a much easier way is that clients directly talk to the on-screen > keyboard application. Exposing the virtual keyboard to the applications means you have to patch all toolkits that run on your platform, in order to support. Desktops usually allow all kind of toolkits. So having the virtual keyboard in the compositor allows it to support applications that use different toolkits. It also allows the compositor to restrict access to the active application, as Kristian mentioned. On top of that, the virtual keyboard (and possibly other input methods) only need to be launched once, if running inside the compositor. This can affect application start up time significantly (think of dictionaries and word engines that need to be initialized). Giving applications too much control over the virtual keyboard also makes it too easy for applications to simply provide their own, and then any form of platform consistency is gone. I think it's better to have a policy where toolkits need to implement the virtual keyboard support for Wayland and the applications don't have to do anything at all. That being said, there are a few use-cases where on-screen keyboard inside the application makes sense, but for the majority of use-cases, it's more beneficial to have it in the compositor (or even as a dedicated process, but still protected from direct application access). regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: spec: Fix the escaping of special characters in Interfaces section
On Thu, 2012-02-16 at 15:40 +0200, Tiago Vignatti wrote: > On 02/16/2012 01:42 PM, Michael Hasselmann wrote: > > Hi, > > > > just noticed these small issues while going through the available > > Wayland documentation. > > FYI, this short-circuit with the idea of dynamically dump the interfaces > on the doc - check last commit there mainly: > > http://cgit.freedesktop.org/~vignatti/wayland/log/?h=tex Ah yes, makes of course more sense to generate that section, since the information is already available. And I see that you already included the escaping for underscores, but not yet for ampersands (they will be simply skipped, which makes the text a bit funny to read). regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
spec: Fix the escaping of special characters in Interfaces section
Hi,
just noticed these small issues while going through the available
Wayland documentation.
regards,
Michael
>From cf98b94497fc8e9a2e9eb5c2f99a9b21f20fe1d0 Mon Sep 17 00:00:00 2001
From: Michael Hasselmann
Date: Thu, 16 Feb 2012 11:55:32 +0100
Subject: [PATCH] spec: Fix the escaping of special characters in Interfaces
section
Section 2.4 about interfaces did not render properly, as tex requires escaping
of underscores and ampersands. This was fixed now, together with two minor
spelling mistakes.
---
spec/main.tex | 28 ++--
1 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/spec/main.tex b/spec/main.tex
index 59d4fe0..8c91592 100644
--- a/spec/main.tex
+++ b/spec/main.tex
@@ -193,20 +193,20 @@ always expected to be present.
Core interfaces:
\begin{itemize}
-\item wl_display: provides global functionality like objecting binding and fatal error events
-\item wl_callback: callback interface for dnoe events
-\item wl_compositor: core compositor interface, allows surface creation
-\item wl_shm: buffer management interface with buffer creation and format handling
-\item wl_buffer: buffer handling interface for indicating damage and object destruction, also provides buffer release events from the server
-\item wl_data_offer: for accepting and receiving specific mime types
-\item wl_data_source: for offering specific mime types
-\item wl_data_Device: lets clients manage drag & drop, provides pointer enter/leave events and motion
-\item wl_data_device_manager: for managing data sources and devices
-\item wl_shell: shell surface handling
-\item wl_shell_surface: shell surface handling and desktop-like events (e.g. set a surface to fullscreen, display a popup, etc.)
-\item wl_surface: surface management (destruction, damage, buffer attach, frame handling)
-\item wl_input_device: cursor setting, motion, button, and key events, etc.
-\item wl_output: events describing an attached output (subpixel orientation, current mode & geometry, etc.)
+\item wl\_display: provides global functionality like objecting binding and fatal error events
+\item wl\_callback: callback interface for done events
+\item wl\_compositor: core compositor interface, allows surface creation
+\item wl\_shm: buffer management interface with buffer creation and format handling
+\item wl\_buffer: buffer handling interface for indicating damage and object destruction, also provides buffer release events from the server
+\item wl\_data\_offer: for accepting and receiving specific mime types
+\item wl\_data\_source: for offering specific mime types
+\item wl\_data\_device: lets clients manage drag \& drop, provides pointer enter/leave events and motion
+\item wl\_data\_device\_manager: for managing data sources and devices
+\item wl\_shell: shell surface handling
+\item wl\_shell\_surface: shell surface handling and desktop-like events (e.g. set a surface to fullscreen, display a popup, etc.)
+\item wl\_surface: surface management (destruction, damage, buffer attach, frame handling)
+\item wl\_input\_device: cursor setting, motion, button, and key events, etc.
+\item wl\_output: events describing an attached output (subpixel orientation, current mode \& geometry, etc.)
\end{itemize}
\subsection{Connect Time}
--
1.7.6.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: RFC: multitouch support v2
On Thu, 2011-12-22 at 11:40 -0800, Chase Douglas wrote: > >> Off the top of my head, I would think Wayland should automatically > >> create the equivalent of X master pointer devices for each touchscreen > >> device. There shouldn't be a sprite for touchscreens, though the WM > >> could do fancy effects like MS Surface if you wanted it to. > > > > Right... in the MPX sense, right? So you could have a keyboard and > > mouse combo controlling one pointer/kb focus and the touch screen > > being its own master device. Then maybe you could have one person > > using the touch screen UI, and another person using the kb/mouse > > combo. That's kind of far fetched, of course, but I think the main > > point is that there's no inherent association between a kb/mouse combo > > and a touch screen. On the other hand, what about a setup with two > > mouse/kb combos (master devices) and a touch screen... you'd expect > > tapping a window on the touch screen to set kb focus, but if you have > > multiple master kbs, which kb focus do you set? Maybe we're just > > doomed for trying to make both pointer and direct touch interaction > > work in the same UI. > > In the past I've tried to think of a good solution for this. I haven't > had enough time to come up with one yet :). I wouldn't advocate holding > up all of wayland to get this right, but I do think it needs to be > rethought from the ground up long term. My proposal: Forget briefly about focus. Instead, keyboards and mice get registered to a surface, and if you touch that surface, it activates the registered keyboards and mice. If you registered multiple keyboards/mice to the same surface, then yes, all of them become active at the same time. This should, however, be the exception (depending on the UX design). Even on a multi-user setup, I would expect users to their own work areas (surfaces) to interact with. The whole idea of single focus widgets does not seem to work with multi input, so how about just giving up on this (artificial?) constraint? regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Input Method support in wayland.
On Sat, 2011-07-09 at 12:10 +0530, manish sharma wrote: > Hi, > > I am a input method developer, wondering how input methods will work > in wayland? Is there going to be a protocol for it something similar > to www.x.org/docs/XIM/xim.pdf? > > If yes then i will be very happy to get more information on this. I think the honest answer is still "TBD". But hey, if you can make it to the Desktop Summit in Berlin this year, then make sure to drop by: http://wiki.desktopsummit.org/Workshops_%26_BoFs/2011/Input_methods_and_Wayland regards, Michael ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Wayland's client protocol header is not self contained
Hi,
while trying to build the Wayland support for Qt, I noted that the
generated (and exported) client protocol header is not self contained.
Attached is a simple fix, though I haven't checked whether the server
protocol header would need similar treatment.
regards,
Michael
>From df9af09af8104b71d09b49deb98713a59e47ddfd Mon Sep 17 00:00:00 2001
From: Michael Hasselmann
Date: Sun, 19 Jun 2011 19:39:39 +0200
Subject: [PATCH] Include wayland-client.h in exported client protocol headers
---
wayland/scanner.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/wayland/scanner.c b/wayland/scanner.c
index b6aebdb..6499977 100644
--- a/wayland/scanner.c
+++ b/wayland/scanner.c
@@ -560,11 +560,13 @@ emit_header(struct protocol *protocol, int server)
"\n"
"#include \n"
"#include \n"
- "#include \"wayland-util.h\"\n\n"
+ "#include \"wayland-util.h\"\n"
+ "%s\n"
"struct wl_client;\n\n",
copyright,
protocol->uppercase_name, s,
- protocol->uppercase_name, s);
+ protocol->uppercase_name, s,
+ server ? "" : "#include \"wayland-client.h\"\n");
wl_list_for_each(i, &protocol->interface_list, link)
printf("struct %s;\n", i->name);
--
1.7.5.4
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
