when a mouse is moved the binding handler is called, passing it the
mouse position and the timestamp. a shell plugin can use this to
activate an effect when the mouse hits an output corner.
---
src/bindings.c | 36
src/compositor.c | 8
Anyone know about clipboard?
On Sat, Mar 30, 2013 at 11:39 PM, Yichao Yu yyc1...@gmail.com wrote:
Hi,
I have already sent a email about the clipboard and selection in
wayland a few weeks ago[1] (mainly about middle button paste). After
reading more about clipboard and selection protocol in
---
clients/terminal.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/clients/terminal.c b/clients/terminal.c
index e80e0e5..81edd25 100644
--- a/clients/terminal.c
+++ b/clients/terminal.c
@@ -757,11 +757,13 @@ resize_handler(struct widget *widget,
On 4 April 2013 07:58, John Kåre Alsaker john.kare.alsa...@gmail.com wrote:
The weston_color_manager struct could lose the state field
All fixed in the newest patchset, thanks for your detailed review.
I don't see a GLib event loop, so I'm curious to how the signals work.
As discussed on
On Thu, 4 Apr 2013 11:00:50 -0400
Jason Woofenden ja...@jasonwoof.com wrote:
---
clients/terminal.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/clients/terminal.c b/clients/terminal.c
index e80e0e5..81edd25 100644
--- a/clients/terminal.c
+++
On Thu, Apr 04, 2013 at 11:00:50AM -0400, Jason Woofenden wrote:
---
clients/terminal.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/clients/terminal.c b/clients/terminal.c
index e80e0e5..81edd25 100644
--- a/clients/terminal.c
+++ b/clients/terminal.c
Giulio Camuffo wrote:
when a mouse is moved the binding handler is called, passing it the
mouse position and the timestamp. a shell plugin can use this to
activate an effect when the mouse hits an output corner.
Any preview of resize must be after the client tells the compositor that
it
Hmm, did you reply to the right mail? This has nothing to do with resizing.
2013/4/4 Bill Spitzak spit...@gmail.com
Giulio Camuffo wrote:
when a mouse is moved the binding handler is called, passing it the
mouse position and the timestamp. a shell plugin can use this to
activate an
No this is the right message.
The problem is that only the client knows when the mouse hits an output
corner (or more accurately, the client is the only one that knows the
mouse is not pointing at something of mine that should do something
other than a shell effect). Therefore any effect when
There is no protocol for the client to tell the server if it used a motion
event.
But even if there was i don't think it should. The event is still delivered
to the client, it isn't eaten, so the client can still do whatever it
wants, but what's more important is that no client should change the
How is this intended to work in Wayland?
Are clients supposed to tell the compositor what color space their
buffer is, and the compositor then converts to the output's color space
as part of the compositing step? Problems with this:
* We need a reliable way for clients to tell compositor
Giulio Camuffo wrote:
There is no protocol for the client to tell the server if it used a
motion event.
But even if there was i don't think it should. The event is still
delivered to the client, it isn't eaten, so the client can still do
whatever it wants, but what's more important is that
Am 03.04.2013 21:47, schrieb Richard Hughes:
Patch 1 adds the framework code, patch 2 adds the ability to load CMS
modules, and patch 3 adds a CMS module written for colord. With those
People have a hard time to understand ICC and colour termininology. So
some annotations to that first.
A CMS
On 4 April 2013 19:21, Kai-Uwe Behrmann k...@gmx.de wrote:
Parsing of ICC profiles inside weston is not nice. That would be better
abstracted out to lay inside the CMS plugins. Those CMS plugins can link
against lcms or whatever CMM they prefere.
Well, we could certainly add some abstraction
On 4 April 2013 19:08, Bill Spitzak spit...@gmail.com wrote:
Are clients supposed to tell the compositor what color space their buffer
is, and the compositor then converts to the output's color space as part of
the compositing step?
At the moment I'm just implementing the calibration state
On Thu, Apr 4, 2013 at 1:54 PM, Giulio Camuffo giuliocamu...@gmail.com wrote:
There is no protocol for the client to tell the server if it used a motion
event.
But even if there was i don't think it should. The event is still delivered
to the client, it isn't eaten, so the client can still do
Richard Hughes wrote:
On 4 April 2013 19:08, Bill Spitzak spit...@gmail.com wrote:
Are clients supposed to tell the compositor what color space their buffer
is, and the compositor then converts to the output's color space as part of
the compositing step?
At the moment I'm just implementing
2013/4/4 Kristian Høgsberg k...@bitplanet.net
On Thu, Apr 4, 2013 at 1:54 PM, Giulio Camuffo giuliocamu...@gmail.com
wrote:
There is no protocol for the client to tell the server if it used a
motion
event.
But even if there was i don't think it should. The event is still
delivered
to
Kristian Høgsberg wrote:
I'm not sure if this is what Bill is getting at, but there is a
problem with just unconditionally triggering motion bindings. If
you're moving or resizing a window and move the pointer to the corner,
you don't want to make that trigger an expose effect or such.
I was
2013/4/4 Bill Spitzak spit...@gmail.com
Kristian Høgsberg wrote:
I'm not sure if this is what Bill is getting at, but there is a
problem with just unconditionally triggering motion bindings. If
you're moving or resizing a window and move the pointer to the corner,
you don't want to make
Thank you Pekka Paalanen and Kristian Høgsberg for your review and
feedback.
I can't believe I forgot to compile and test again before sending
in that patch.
I played with it a bit before refactoring, and I like the way it
looked/responded while resizing. But now (thanks to Kristian) that
I
On Thu, Apr 4, 2013 at 2:58 AM, John Kåre Alsaker
john.kare.alsa...@gmail.com wrote:
I don't see a GLib event loop, so I'm curious to how the signals work.
Just ftr (and without actually looking at the patch): glib signals
don't need an event loop, they're entirely synchronous.
On Thu, Apr 04, 2013 at 11:18:33AM +1000, Peter Hutterer wrote:
The \file comment at the top is required to tell doxygen that this file
actually has members (or use EXTRACT_ALL, which in our setup has the same
effect since we restrict the source files)
By default, all function's man pages
weston_client_launch() might return a client pointer that will not be the
actual one the shell client is binding. Therefore, assign the pointer only
later after the interface is already bound.
Signed-off-by: Tiago Vignatti tiago.vigna...@intel.com
---
src/shell.c |9 +++--
1 file
---
src/compositor.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/compositor.c b/src/compositor.c
index 3645b04..88f083c 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -977,6 +977,7 @@ weston_surface_unmap(struct weston_surface *surface)
On Thu, Apr 04, 2013 at 06:07:39PM -0300, Tiago Vignatti wrote:
If a shell client decides to call wl_display_connect more than once and only
later bind the desktop_shell interface, then the logic that uses the client
pointer fails, because the current client trying to connect won't match with
26 matches
Mail list logo
