Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

2015-10-02 Thread Bill Spitzak
On Fri, Oct 2, 2015 at 6:32 AM, Manuel Bachmann wrote: > > * Daniels, I totally agree with you that "raise()" is a bad choice of > wording, it offers false expectations, and we agreed with Jasper that > present() is a lot better (plus, it resembles a "present()" function > present in popular tool

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

2015-10-02 Thread Manuel Bachmann
Hi Jonas, Daniel, Derek, Bill, My apologizes for the late answer, I initiallty wanted to come back Monday with a new test case, and missed some answers. * Jonas, good point, I forgot to bump the protocol here. I really think it fits into xdg-shell ; what are you thinking of when you are referring

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

2015-10-01 Thread Jonas Ådahl
On Thu, Apr 09, 2015 at 06:22:53PM +0200, Manuel Bachmann wrote: > xdg_surface_present() and xdg_surface_present_from_event() > are new requests supposed to be called on an existing > xdg_surface. They tell the compositor that the surface > has new content which may be of interest to the user. > Th

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

2015-09-30 Thread Daniel Stone
On Wednesday, 30 September 2015, Derek Foreman wrote: > On 30/09/15 12:01 PM, Bill Spitzak wrote: > > My main concern is that programmers are going to search for the word > > "raise" to figure out how to raise windows. They are not going to search > > for "present" or "indicate_activity" or any o

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

2015-09-30 Thread Bill Spitzak
On Wed, Sep 30, 2015 at 10:27 AM, Derek Foreman wrote: > > Well, X calls similar functionality "UrgencyHint"... That's actually > more descriptive than imperative. The idea is that we let the > compositor know the surface needs attention, not that we tell it what to > do. > That was because th

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

2015-09-30 Thread Derek Foreman
On 30/09/15 12:01 PM, Bill Spitzak wrote: > > > On Tue, Sep 29, 2015 at 12:18 PM, Derek Foreman > wrote: > > > > 2. Call the function "xdg_surface_raise". Because raising is exactly > > what the client expects. It does not mean that it *has* to raise the

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

2015-09-30 Thread Bill Spitzak
On Tue, Sep 29, 2015 at 12:18 PM, Derek Foreman wrote: > > > 2. Call the function "xdg_surface_raise". Because raising is exactly > > what the client expects. It does not mean that it *has* to raise the > > window. If you don't do this, lots of programmers are going to ask where > > the raise fun

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

2015-09-29 Thread Derek Foreman
On 29/09/15 12:47 PM, Bill Spitzak wrote: > Another important point is that the compositor can check what *type* of > event was used for the raise. It could accept press/release and ignore > move events, for instance. Keyboard events could be ignored if the > client no longer has keyboard focus, wh

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

2015-09-29 Thread Daniel Stone
Hi, On 29 September 2015 at 18:47, Bill Spitzak wrote: > Another important point is that the compositor can check what *type* of > event was used for the raise. It could accept press/release and ignore move > events, for instance. Keyboard events could be ignored if the client no > longer has key

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

2015-09-29 Thread Bill Spitzak
Another important point is that the compositor can check what *type* of event was used for the raise. It could accept press/release and ignore move events, for instance. Keyboard events could be ignored if the client no longer has keyboard focus, while clicks are ignored if the client no longer has

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

2015-09-29 Thread Manuel Bachmann
Hi Derek, and thanks a lot for your feedback, I think it makes sense if you consider the compositor can know if a past input event could have happened "not long ago" or "a very long time ago" (if the event happened not long ago, raise the window, otherwise blink). It is really a matter of policy,

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

2015-09-28 Thread Derek Foreman
On 09/04/15 11:22 AM, Manuel Bachmann wrote: > xdg_surface_present() and xdg_surface_present_from_event() > are new requests supposed to be called on an existing > xdg_surface. They tell the compositor that the surface > has new content which may be of interest to the user. > The compositor may the

Re: [PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

2015-04-13 Thread Bryce Harrington
On Thu, Apr 09, 2015 at 06:22:53PM +0200, Manuel Bachmann wrote: > xdg_surface_present() and xdg_surface_present_from_event() > are new requests supposed to be called on an existing > xdg_surface. They tell the compositor that the surface > has new content which may be of interest to the user. > Th