On Thu, Jul 09, 2015 at 03:10:51PM +0200, Alexander Larsson wrote:
On Thu, 2015-07-09 at 20:58 +0800, Jonas Ådahl wrote:
On Thu, Jul 09, 2015 at 01:26:09PM +0100, Daniel Stone wrote:
Or rather, xdg_foreign.reparent_as_dialog_into(xdg_surface). I like
the idea of limiting the surface
The shell is a client. Both are technically correct, but I'm fine with
this change if it makes things easier to read. We do use the terms
shell and client way too much. :)
On Thu, Jul 9, 2015 at 10:07 AM, Christopher Michael
cpmich...@osg.samsung.com wrote:
Documentation for the
On 07/09/2015 02:21 AM, Jonas Ådahl wrote:
That is more or less what was the idea before the thread derailed.
I have no idea why you think my proposal derailed this when I was
attempting to describe EXACTLY the same thing you are, except I replaced
fd with a key which I figured is a 128-bit
No, it's not the same thing. You want an xdg_surface interface exposed
on both sides. We don't want that. The resulting derail was us
collectively ramming our heads straight into the wall trying to figure
out any way that having the same interface exposed on both sides could
make any sense.
On 07/09/2015 02:19 AM, Jasper St. Pierre wrote:
Calling sandboxed_surface_manager.get_surface_for_id(); retrieves that
surface and deletes the ID from the global namespace.
I thought about having the ID work only once like you propose, but I
think this means that a client must be able to
Documentation for the prepare_lock_surface event description
is incorrect as it says to tell the client to create... however it is
actually the shell which creates the lock surface.
Signed-off-by: Chris Michael cp.mich...@samsung.com
---
protocol/desktop-shell.xml | 2 +-
1 file changed, 1
On 07/09/2015 01:33 PM, Giulio Camuffo wrote:
2015-07-09 20:12 GMT+03:00 Jasper St. Pierre jstpie...@mecheye.net:
The shell is a client. Both are technically correct, but I'm fine with
this change if it makes things easier to read. We do use the terms
shell and client way too much. :)
Imho
2015-07-09 20:12 GMT+03:00 Jasper St. Pierre jstpie...@mecheye.net:
The shell is a client. Both are technically correct, but I'm fine with
this change if it makes things easier to read. We do use the terms
shell and client way too much. :)
Imho this makes it a bit harder to read, as shell can
Here is an updated patch which changes the wording to match what Giulio
offered.
Documentation for the prepare_lock_surface event description is
incorrect. The summary says Tell the client... however the full-text
description says tell the shell...
Signed-off-by: Chris Michael
From the man pages it appears this routine can return NULL on certain
error conditions.
Suggested by Marek Chalupa
Signed-off-by: Bryce Harrington br...@osg.samsung.com
---
xwayland/selection.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/xwayland/selection.c b/xwayland/selection.c
Hi,
On 09-07-15 07:31, Peter Hutterer wrote:
Some model-specific information isn't available through udev properties. This
callout is used to query the device directly and set a property that we can
then match on for the hwdb entries.
This is geared for Elantech and ALPS touchpads where the
Hi,
On 8 July 2015 at 18:46, Bill Spitzak spit...@gmail.com wrote:
All your objections sounds like you are confusing the implementation with
the abstraction that the client program sees. A few examples:
No, not at all. On the contrary ...
On Wed, Jul 8, 2015 at 4:47 AM, Daniel Stone
Hi Alex,
On 9 July 2015 at 09:44, Alexander Larsson al...@redhat.com wrote:
On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
This thread has sadly degenerated into: 'what if Wayland's object
model was totally different? what if some of its explicit core design
principles were thrown out
On Thu, Jul 09, 2015 at 01:38:32PM +0300, Pekka Paalanen wrote:
On Thu, 09 Jul 2015 11:37:06 +0200
Alexander Larsson al...@redhat.com wrote:
On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
My issue with this is that you're tying two things together. You want
access to a
On Thu, 09 Jul 2015 11:37:06 +0200
Alexander Larsson al...@redhat.com wrote:
On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
My issue with this is that you're tying two things together. You want
access to a surface, and you think you can do this by having
global cross-client
On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
Hi,
None of them will really work.
This thread has sadly degenerated into: 'what if Wayland's object
model was totally different? what if some of its explicit core design
principles were thrown out the window?'. Realistically, that is
Hi,
On Wed, Jul 8, 2015 at 1:03 AM, Peter Hutterer peter.hutte...@who-t.net
wrote:
+double
+evdev_device_transform_touch_point_to_mm(struct evdev_device *device,
+ int32_t axis_value,
+ double axis_angle)
oh
On Thu, Jul 09, 2015 at 08:06:28AM +0200, Andreas Pokorny wrote:
Hi,
On Wed, Jul 8, 2015 at 1:03 AM, Peter Hutterer peter.hutte...@who-t.net
wrote:
+double
+evdev_device_transform_touch_point_to_mm(struct evdev_device *device,
+ int32_t
My issue with this is that you're tying two things together. You want
access to a surface, and you think you can do this by having
global cross-client objects and handles and such. I don't see a need
for this. We can just add a new protocol that does what we want.
We have a few requirements:
1.
Hi,
On 9 July 2015 at 12:51, Alexander Larsson al...@redhat.com wrote:
So, you disagree with xdg_surface.set_parent accepting both xdg_surface
and xdg_foreign objects?
It can't. Typing is very strict, and there is no subtyping.
xdg_surface doesn't extend wl_surface in a traditional (C++/Java)
On Thu, 2015-07-09 at 13:38 +0300, Pekka Paalanen wrote:
On Thu, 09 Jul 2015 11:37:06 +0200
Alexander Larsson al...@redhat.com wrote:
On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
My issue with this is that you're tying two things together. You
want
access to a
On Thu, Jul 09, 2015 at 10:00:56AM +0100, Daniel Stone wrote:
Hi Alex,
On 9 July 2015 at 09:44, Alexander Larsson al...@redhat.com wrote:
On Wed, 2015-07-08 at 12:47 +0100, Daniel Stone wrote:
This thread has sadly degenerated into: 'what if Wayland's object
model was totally different?
On Thu, 2015-07-09 at 10:00 +0100, Daniel Stone wrote:
However, the problem I have now is different, in that it involves
an
existing, less privileged client initiating a higher privileged
operation (in a controlled fashion) and the higher privileged
client
needing to refer to the
On Thu, 2015-07-09 at 02:19 -0700, Jasper St. Pierre wrote:
My issue with this is that you're tying two things together. You want
access to a surface, and you think you can do this by having
global cross-client objects and handles and such. I don't see a need
for this. We can just add a new
On Thu, Jul 09, 2015 at 01:26:09PM +0100, Daniel Stone wrote:
Hi,
On 9 July 2015 at 12:51, Alexander Larsson al...@redhat.com wrote:
So, you disagree with xdg_surface.set_parent accepting both xdg_surface
and xdg_foreign objects?
It can't. Typing is very strict, and there is no
On Sat, 27 Jun 2015 14:07:41 +0300
Giulio Camuffo giuliocamu...@gmail.com wrote:
This is a preliminary change for libweston, with no functional modifications.
Separate the backends and the core weston_compositor struct, by creating
the weston_compositor in the main(), and having the various
On Thu, 2015-07-09 at 20:58 +0800, Jonas Ådahl wrote:
On Thu, Jul 09, 2015 at 01:26:09PM +0100, Daniel Stone wrote:
Or rather, xdg_foreign.reparent_as_dialog_into(xdg_surface). I like
the idea of limiting the surface area as much as possible, to not
only
make it explicit as to what is
On Thu, Jul 09, 2015 at 01:09:35PM -0700, Bill Spitzak wrote:
On Wed, Jul 8, 2015 at 8:29 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:
good point, that does seem to be the best approach here.
the resolution claimed was 800 dpi - 31 u/mm.
I'm a bit worried about doing this though,
On Thu, Jul 9, 2015 at 5:58 AM, Jonas Ådahl jad...@gmail.com wrote:
Yea, an inverse of xdg_surface.set_parent on xdg_foreign sounds like the
best option to me too. We can't be too specific though, adding too much
DE design into the protocol (like making it modal or other things that
might
On Wed, Jul 8, 2015 at 11:38 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:
and since we say that we normalize to [0, 1], the _correct_ value is 1 when
we have a touch. it makes client code more straightforward because you can
rely on the value being useful.
if clients end up needing
On Wed, Jul 8, 2015 at 8:29 PM, Peter Hutterer peter.hutte...@who-t.net
wrote:
good point, that does seem to be the best approach here.
the resolution claimed was 800 dpi - 31 u/mm.
I'm a bit worried about doing this though, the reporter in
https://bugs.freedesktop.org/show_bug.cgi?id=90101
31 matches
Mail list logo
