Looks like that theme uses different names. Also, add the correspoding
horizontal and vertical resize cursors, just for consistency.
---
clients/window.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/clients/window.c b/clients/window.c
index 1562957.
On Tue, 14 May 2013 04:49:39 + (UTC)
Rick Yorgason wrote:
> Daniel Stone writes:
> > I know I've had some trouble expressing my problems with the
> > every-gamepad-in-a-seat proposal, but this pretty much hits the nail
> > on the head. How does the gamepad's focus get assigned (and change)
On Mon, 13 May 2013 17:26:28 -0500
Jason Ekstrand wrote:
> On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli
> wrote:
>
> > Hi Jason,
> >
> > On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand
> > wrote:
> > > Hi Rafael,
> > >
> > >
> > > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli
> > > w
On Mon, 13 May 2013 19:02:34 -0700
Bill Spitzak wrote:
> Alexander Larsson wrote:
>
> > On ons, 2013-05-08 at 12:07 -0700, Bill Spitzak wrote:
> >> I think in the end Wayland is going to have to have arbitrary affine
> >> transforms in the api, and it might make sense to decide a standard for
On Mon, 13 May 2013 15:55:47 -0700
"U. Artie Eoff" wrote:
> From: "U. Artie Eoff"
>
> The subsurface-server-protocol.h header should not be included
> by any headers that are part of the SDK since it is not exported.
> Otherwise, SDK consumers will break during compilation.
>
> Move this inclu
> I expect a compositor to render deviations of the desired scaling factor
> without scaling windows. The range when this is allowed is reported to
> clients so they can try to render at a size which will avoid scaling.
>
> For example a compositor may want to use a 1-1.2 range with 1.1 as the
> de
On Mon, May 13, 2013 at 8:52 PM, Jason Ekstrand wrote:
> On Mon, May 13, 2013 at 9:54 AM, Alexander Larsson wrote:
>
>>
>> On mån, 2013-05-13 at 14:40 +0200, John Kåre Alsaker wrote:
>>
>> >
>> > I don't think this will work in practice. I know for sure that
>> > e.g. Gtk
>> >
Daniel Stone writes:
> I know I've had some trouble expressing my problems with the
> every-gamepad-in-a-seat proposal, but this pretty much hits the nail
> on the head. How does the gamepad's focus get assigned (and change)
> if it's in its own seat? Does it always follow the focus of another
>
Kristian Høgsberg wrote:
The problem then is that the key release of the binding will now count
as activity and undo the lock. I think we'll need a custom grab (see
weston_compositor_run_key_binding()) that triggers the lock on release
of the last key in the binding. Or maybe add a "virtual mo
Hi Kristian,
I think it's good to go - however, inlining the patch messed up the
> whitespace. Ideally, send patches using git send-email, which can be
> configured to use smtp servers, and you can pass --annotate if you
> want to add a message or comment to the patch (put it after the ---
> that
Alexander Larsson wrote:
On ons, 2013-05-08 at 12:07 -0700, Bill Spitzak wrote:
Output scaling should be merged with the existing "buffer_transform"
(the 8-value enumeration describing 90 degree rotations/reflections).
In effect they are parts of the same thing, yeah. I don't know if ABI
comp
From: "U. Artie Eoff"
This test should be executed with 'make installcheck' after
running 'make install'. It is a simple, basic test that attempts
to compile a trivial (and inherently useless) weston sdk module
to ensure the exported SDK can be used by consumers.
Any improvements are welcome.
On Mon, May 13, 2013 at 04:31:06PM -0700, Othman, Ossama wrote:
> Hi Kristian,
>
> Here's another revision of the patch that attempts to implement your
> suggested simplification, as well as address the TOCTOU race in previous
> revisions of the patch. The module entry point signature changed sli
From: "U. Artie Eoff"
The subsurface-server-protocol.h header should not be included
by any headers that are part of the SDK since it is not exported.
Otherwise, SDK consumers will break during compilation.
Move this include from compositor.h to compositor.c.
Fixes https://bugs.freedesktop.org/
On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli wrote:
> Hi Jason,
>
> On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand
> wrote:
> > Hi Rafael,
> >
> >
> > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli
> > wrote:
> >>
> >> Hello,
> >>
> >> I've been looking the Weston code relative to maxim
On Sun, May 12, 2013 at 10:58:04AM +0200, Quentin Glidic wrote:
> From: Quentin Glidic
It's a good idea, but there are a couple of issues with the patch.
> Signed-off-by: Quentin Glidic
> ---
> src/shell.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/src/shell.c b/src
Hi Jason,
On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand wrote:
> Hi Rafael,
>
>
> On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli
> wrote:
>>
>> Hello,
>>
>> I've been looking the Weston code relative to maximized windows, and
>> it seems that the respective code for minimized windows wouldn'
On Mon, May 13, 2013 at 10:37 AM, Daniel Stone wrote:
> Hi,
>
> On 12 May 2013 16:54, Kristian Høgsberg wrote:
>> I think we can change the interface to int open_config_file(const char
>> *), which looks up and opens the config file and returns the fd. We
>> can keep that in weston_compositor in
On Mon, May 13, 2013 at 9:54 AM, Alexander Larsson wrote:
>
> On mån, 2013-05-13 at 14:40 +0200, John Kåre Alsaker wrote:
>
> >
> > I don't think this will work in practice. I know for sure that
> > e.g. Gtk
> > is not set up to do any reasonable non-integer scaling. It
>
On Sun, May 12, 2013 at 07:33:44PM -0700, Othman, Ossama wrote:
> Hi Kristian,
>
> On Sun, May 12, 2013 at 8:54 AM, Kristian Høgsberg wrote:
> >
> > I think we can change the interface to int open_config_file(const char
> > *), which looks up and opens the config file and returns the fd. We
> > c
Hi,
On 13 May 2013 14:43, Todd Showalter wrote:
> On Mon, May 13, 2013 at 2:33 AM, David Herrmann wrote:
>> That is why the kernel provides "PHYS" and "UNIQ" fields for every
>> input device (they might be empty if not implemented, but at least
>> they're supposed to be there..). "PHYS" provides
Hi,
On 13 May 2013 07:14, Pekka Paalanen wrote:
> On Mon, 13 May 2013 09:12:03 +1000
> Peter Hutterer wrote:
>> > Those were exactly my thoughts in the beginning, however during the way
>> > long email thread, I got convinced otherwise for now. There are a few
>> > issues that come mind:
>> > -
On mån, 2013-05-13 at 14:40 +0200, John Kåre Alsaker wrote:
>
> I don't think this will work in practice. I know for sure that
> e.g. Gtk
> is not set up to do any reasonable non-integer scaling. It
> will just
> scale up all drawing by a fractiona
Hi,
On 12 May 2013 16:54, Kristian Høgsberg wrote:
> I think we can change the interface to int open_config_file(const char
> *), which looks up and opens the config file and returns the fd. We
> can keep that in weston_compositor instead of the config_file path.
> The parse function can then fs
On Mon, May 13, 2013 at 2:33 AM, David Herrmann wrote:
> That is why the kernel provides "PHYS" and "UNIQ" fields for every
> input device (they might be empty if not implemented, but at least
> they're supposed to be there..). "PHYS" provides the physical location
> for the device. "UNIQ" provid
On Mon, May 13, 2013 at 2:19 PM, Alexander Larsson wrote:
> On mån, 2013-05-13 at 14:00 +0200, John Kåre Alsaker wrote:
>
> > > Clients can easily scale larger features like icons, padding
> > and fonts
> > > and round them to pixel sizes and draw sharp output even
> >
On mån, 2013-05-13 at 14:00 +0200, John Kåre Alsaker wrote:
> > Clients can easily scale larger features like icons, padding
> and fonts
> > and round them to pixel sizes and draw sharp output even
> with a
> > fractional scaling factor. This allows users to
On mån, 2013-05-13 at 13:49 +0200, John Kåre Alsaker wrote:
> On Mon, May 13, 2013 at 1:28 PM, Alexander Larsson
> wrote:
> On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote:
> > For the wl_output case I suggest we add a 'done' event which
> signals
> > tha
Mon, May 13, 2013 at 1:26 PM, Alexander Larsson wrote:
> On mån, 2013-05-13 at 12:40 +0200, John Kåre Alsaker wrote:
>
> > The scaling factor should not have any affect of any coordinate system
> > or anything else in the protocol. It should only affect the size in
> > pixels of the surfaces of t
On Mon, 13 May 2013 13:14:29 +0200
Alexander Larsson wrote:
> On mån, 2013-05-13 at 13:12 +0300, Pekka Paalanen wrote:
> > On Mon, 13 May 2013 11:16:07 +0200
> > Alexander Larsson wrote:
> >
> > > On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote:
> > >
> > > > Also, we need to figure ou
On Mon, May 13, 2013 at 1:28 PM, Alexander Larsson wrote:
> On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote:
> > For the wl_output case I suggest we add a 'done' event which signals
> > that the compositor is done sending a batch of events for an wl_output
> > and related extension obj
On mån, 2013-05-13 at 13:26 +0200, John Kåre Alsaker wrote:
> For the wl_output case I suggest we add a 'done' event which signals
> that the compositor is done sending a batch of events for an wl_output
> and related extension objects (which versioned message arguments won't
> handle). This would
On mån, 2013-05-13 at 12:40 +0200, John Kåre Alsaker wrote:
> The scaling factor should not have any affect of any coordinate system
> or anything else in the protocol. It should only affect the size in
> pixels of the surfaces of the clients. Clients should do any
> transformations of coordinates
For the wl_output case I suggest we add a 'done' event which signals that
the compositor is done sending a batch of events for an wl_output and
related extension objects (which versioned message arguments won't handle).
This would be analogous to wl_surface.commit, only coming from the server
side.
On mån, 2013-05-13 at 13:12 +0300, Pekka Paalanen wrote:
> On Mon, 13 May 2013 11:16:07 +0200
> Alexander Larsson wrote:
>
> > On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote:
> >
> > > Also, we need to figure out how this interacts with the proposed
> > > scaling extension. Information
On mån, 2013-05-13 at 12:19 +0300, Pekka Paalanen wrote:
> On Mon, 13 May 2013 10:23:44 +0200
> Alexander Larsson wrote:
>
> > On ons, 2013-05-08 at 15:40 -0500, Jason Ekstrand wrote:
> >
> > >
> > > In short, I think this is far too complex for what it achieves. In
> > > the case of scaling f
On Mon, May 13, 2013 at 11:56 AM, Alexander Larsson wrote:
> On ons, 2013-05-08 at 22:58 +0200, John Kåre Alsaker wrote:
> > I think we should allow fractional scale factors. Clients which only
> > support integer scale factors should round the scale factor they get
> > to a whole number.
>
> I do
On Mon, 13 May 2013 11:16:07 +0200
Alexander Larsson wrote:
> On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote:
>
> > Also, we need to figure out how this interacts with the proposed
> > scaling extension. Information can be found here:
> > http://lists.freedesktop.org/archives/wayland-d
On ons, 2013-05-08 at 22:58 +0200, John Kåre Alsaker wrote:
> I think we should allow fractional scale factors. Clients which only
> support integer scale factors should round the scale factor they get
> to a whole number.
I don't see how this is useful? The scaling has two main benefits:
1) It d
On Mon, 13 May 2013 10:23:44 +0200
Alexander Larsson wrote:
> On ons, 2013-05-08 at 15:40 -0500, Jason Ekstrand wrote:
>
> >
> > In short, I think this is far too complex for what it achieves. In
> > the case of scaling factor stuff, you can just do it with a second
> > event.
>
> I agree tha
On ons, 2013-05-08 at 14:51 -0500, Jason Ekstrand wrote:
> Is there a way to bypass the scaling? When I'm using the
> mouse in
> a game, I want to know the pixel position of the pointer, with
> no
> scaling applied. I'm going to be drawing the gui at
On ons, 2013-05-08 at 12:07 -0700, Bill Spitzak wrote:
> Output scaling should be merged with the existing "buffer_transform"
> (the 8-value enumeration describing 90 degree rotations/reflections).
In effect they are parts of the same thing, yeah. I don't know if ABI
compat allows us to just chan
On ons, 2013-05-08 at 15:40 -0500, Jason Ekstrand wrote:
>
> In short, I think this is far too complex for what it achieves. In
> the case of scaling factor stuff, you can just do it with a second
> event.
I agree that what I posted have some open issues, and it was mostly
meant as a start of a
43 matches
Mail list logo
