On Tue, Apr 30, 2013 at 10:49 PM, Jason Ekstrand wrote:
> On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak wrote:
>
>> I'm not clear on why Wayland's design requires adding 2 dummy objects to
>> the api (in this case the "wl_scalar" factory and the per-surface
>> "wl_surface_scalar") rather than jus
Evening,
On 30.04.2013 22:06, Kristian Høgsberg wrote:
[...]
> diff --git a/src/connection.c b/src/connection.c
> index dca134b..b26402f 100644
> --- a/src/connection.c
> +++ b/src/connection.c
> @@ -324,7 +324,7 @@ wl_connection_read(struct wl_connection *connection)
> msg.msg_flags = 0;
>
Pekka Paalanen wrote:
Hi all,
below is my first draft for a wl_surface scaling and cropping
extension. I called it wl_scaler in the lack of a better name. It is
designed similarly to the other wl_surface extensions wl_shell_surface
and wl_subsurface.
There probably isn't any interesting detai
On Tue, Apr 30, 2013 at 8:33 AM, Pekka Paalanen wrote:
> Hi all,
>
> below is my first draft for a wl_surface scaling and cropping
> extension. I called it wl_scaler in the lack of a better name. It is
> designed similarly to the other wl_surface extensions wl_shell_surface
> and wl_subsurface.
>
On Tue, Apr 30, 2013 at 2:29 PM, Bill Spitzak wrote:
> I'm not clear on why Wayland's design requires adding 2 dummy objects to
> the api (in this case the "wl_scalar" factory and the per-surface
> "wl_surface_scalar") rather than just adding new methods to the wl_surface
> object.
>
> It seems w
Jason Ekstrand wrote:
Can't the client just destroy the scaler?
Good question is whether these sub-objects (or whatever they are called)
should do something when created & destroyed. That does make it harder
to hide their existence and pretend the api is on the parent object.
_
The current thread model assumes that the application or toolkit will have
one thread that either polls the display fd and dispatches events or just
dispatches in a loop. Only this main thread will read from the fd while
all other threads will block on a pthread condition and expect the main
threa
kristof, I'm not sure what help I can be, but I'd like to support your
effort. Both Haskell bindings for Wayland, and another Wayland WM seem like
things that should exist. Have you set up version control for this yet?
- Lucas
___
wayland-devel mailin
Pekka Paalanen wrote:
Normally Wayland does
not allow clients to e.g. randomly raise themselves to top
I hope it allows this.
Otherwise clients are going to resort to destroying/recreating their
surfaces, which is how we work around bugs in Gnome window managers when
click-to-raise is turn
I'm not clear on why Wayland's design requires adding 2 dummy objects to
the api (in this case the "wl_scalar" factory and the per-surface
"wl_surface_scalar") rather than just adding new methods to the
wl_surface object.
It seems wasteful for clients and servers to track this whole
constella
On 30 April 2013 16:37, Rob Bradford wrote:
> I'm not sure whether libunique will ever lose it's X calls. The project
> is long dead and has been replaced by GApplication/GtkApplication.
Agreed. Midori needs to port to GApplication or loose the libunique dep.
Richard.
___
On Tue, Apr 30, 2013 at 9:06 AM, John Kåre Alsaker <
john.kare.alsa...@gmail.com> wrote:
> I'd say we should split the cropping and scaling request into two.
>
How would you suggest doing that? I actually really like the simplicity of
this box maps to that box.
> Specifying a scaling with a NU
On Fri, Apr 26, 2013 at 10:24:03AM +, MoD wrote:
> So technically nothing has changed recently from Midori's perspective;
> we're still just waiting on released versions of dependencies to lose
> their internal Xlib calls.
>
I'm not sure whether libunique will ever lose it's X calls. The proj
On Tue, Apr 30, 2013 at 10:25 AM, Todd Showalter wrote:
> On Tue, Apr 30, 2013 at 9:26 AM, Pekka Paalanen
> wrote:
>
> > unfortunately that is not how Wayland works at all. All clients are
> > isolated from the start, regardless how they are spawned. The idea
> > might be ok, but concepts and pro
On Tue, Apr 30, 2013 at 9:26 AM, Pekka Paalanen wrote:
> unfortunately that is not how Wayland works at all. All clients are
> isolated from the start, regardless how they are spawned. The idea
> might be ok, but concepts and protocol design will be very different.
I had a feeling that might
> I'd like to have a better name for it, and you might want the set
I
checked up the thesaurus and the closest contender was "size", so I guess
you already have the best name :)
> Comments? Is the language clear?
>
>
Should this simply be called "get"? Since the above request i
I'd say we should split the cropping and scaling request into two.
Specifying a scaling with a NULL buffer should still set the surface size,
so we can have surfaces with only an input region.
I don't see a way to disable scaling and cropping, could passing 0 as width
and height do that?
On Tue
On Tue, 30 Apr 2013 08:30:52 -0400
Todd Showalter wrote:
> On 2013-04-30, at 3:29 AM, Pekka Paalanen wrote:
>
> > What an application could actually do when it receives a home button
> > press via the special path is an important question. Since Wayland
> > does not allow random clients to just
On Tue, Apr 30, 2013 at 5:29 AM, Pekka Paalanen wrote:
> you've provided lots of valuable information already. Unfortunately my
> input is left as hand-waving, since I cannot dedicate to designing this
> protocol myself (as in writing the XML spec).
I'm getting set up to write code. Someone
Hi all,
below is my first draft for a wl_surface scaling and cropping
extension. I called it wl_scaler in the lack of a better name. It is
designed similarly to the other wl_surface extensions wl_shell_surface
and wl_subsurface.
There probably isn't any interesting details to debate, right? ;-)
On 2013-04-30, at 3:29 AM, Pekka Paalanen wrote:
> What an application could actually do when it receives a home button
> press via the special path is an important question. Since Wayland does
> not allow random clients to just jump in, you need to specifically
> think how to enable a desired re
On Mon, 29 Apr 2013 21:23:43 -0400
Kristian Høgsberg wrote:
> On Mon, Apr 29, 2013 at 05:23:03PM -0400, Kristian Høgsberg wrote:
> > Looking at the functionality in the server library, it's clear (in
> > hindsight) that there are two different "things" in there: 1) The
> > IPC API, that is, every
Hi Todd,
you've provided lots of valuable information already. Unfortunately my
input is left as hand-waving, since I cannot dedicate to designing this
protocol myself (as in writing the XML spec).
On Mon, 29 Apr 2013 10:17:31 -0400
Todd Showalter wrote:
> On Mon, Apr 29, 2013 at 4:15 AM, Pekk
On Mon, 29 Apr 2013 10:24:54 -0700
Bill Spitzak wrote:
> Pekka Paalanen wrote:
>
> > We had some talk about adding a "window region" or something in the
> > past, that would be used for edge snapping and stuff, or was it
> > deemed that input region was enough; I can't recall.
>
> That was my p
On Mon, 29 Apr 2013 17:10:25 -0700
Sinclair Yeh wrote:
> On Mon, Apr 22, 2013 at 12:48:43PM +0300, Pekka Paalanen wrote:
> > On Fri, 19 Apr 2013 17:49:12 +
> > "Yeh, Sinclair" wrote:
> >
> > > wl_egl_window_destory() distroys the window handle that
> > > dri2_destroy_surface() later uses wh
On Mon, 29 Apr 2013 20:04:12 + (UTC)
Rick Yorgason wrote:
> Todd Showalter writes:
> > I think all gamepad input should be routed to whatever has focus
> > or whatever has grabbed input.
>
> ...and then...
>
> > > I don't think we need a separate event for this, just the normal
> > > b
On Mon, 29 Apr 2013 10:44:17 -0700
Bill Spitzak wrote:
> Has anybody thought about pens (ie wacom tablets)?
Yes, they have been briefly discussed. They need their own interfaces,
just like keyboards and pointers.
- pq
___
wayland-devel mailing list
wa
27 matches
Mail list logo
