-
Von: Daniel danl...@terra.es
Datum: Mo., Mai. 9, 2011 23:29
Betreff: client side decorations
An: Bill Spitzak spit...@gmail.com
Cc: Høgsberg k...@bitplanet.net, Peng Huang shawn.p.hu...@gmail.com,
Sam Spilsbury smspil...@gmail.com, Mike Paquette
paquette...@gmail.com, wayland wayland-devel
* microcai micro...@fedoraproject.org schrieb:
When app lock up, the wayland can start a remote-thread inside the
client, and this thread can handle move/drag stuff or even terminate the
process. This can be implemented as a signal hander inside
libwayland-client, or no need to start the
On Thu, May 12, 2011 at 10:15:31PM +0200, Michal Suchanek wrote:
That's not really true. Of course, there are things that look awful in
different DPI (or because you happen to have slightly different fonts
than the author) because they were done by braindead people. This
includes but is not
microcai wrote:
They can't care how big a windows is in the pixel, but in the inch.
People should have different monitors with different DPI. Windows should
stay same size regardless the DPI.
Force DPI==96 on every monitor is a stupid idea, and we should avoid it
on the protocol side.
The
On 12 May 2011 19:47, Bill Spitzak spit...@gmail.com wrote:
microcai wrote:
They can't care how big a windows is in the pixel, but in the inch.
People should have different monitors with different DPI. Windows should
stay same size regardless the DPI.
Force DPI==96 on every monitor is a
mccrocai wrote:
That's not true.
DPI is not only used by font size, but also by image size and ther
things
You don't want you 300DPI screen display *tiny tiny font*, will you?
By designing the protocol *DPI aware*, and force the application deal
with the DPI natively, we get better user
On 10 May 2011 05:46, Russell Shaw rjs...@netspace.net.au wrote:
On 10/05/11 07:29, Daniel wrote:
El dg 08 de 05 de 2011 a les 09:47 -0700, en/na Bill Spitzak va
escriure:
Though it is possible, I don't like the idea of clients sending hints
about what areas are the close box or window
On 11/05/11 18:55, Michal Suchanek wrote:
On 10 May 2011 05:46, Russell Shawrjs...@netspace.net.au wrote:
On 10/05/11 07:29, Daniel wrote:
El dg 08 de 05 de 2011 a les 09:47 -0700, en/na Bill Spitzak va
escriure:
Though it is possible, I don't like the idea of clients sending hints
about
Michal Suchanek wrote:
I guess there is one thing that can be done. The compositor could
publish a hint to the application that it takes care of decorating the
windows (even if it is a tiling WM and in fact does not but the user
does not want any decorations in the first place)
Indeed this
I personally does support and only support client side decoration.
Move and resize ? Better be done in the server side.
Average application should never care about where its windows is. The
compositor cares and move them without notify the client.
If the unusual application does care where its
I can't get one thing out of this discussion.
So you are arguing about client side VS server side decorations,
handling of moves/resizes, maybe even buttons scroll bars etc.
But all wayland does is provide a communication channel that enables
clients to draw in the GPU memory, and then
El dg 08 de 05 de 2011 a les 09:47 -0700, en/na Bill Spitzak va
escriure:
Though it is possible, I don't like the idea of clients sending hints
about what areas are the close box or window border, since it implies
there are such concepts as title bar and close box. The compositor
can just
On Sat, May 7, 2011 at 12:52 PM, microcai micro...@fedoraproject.orgwrote:
于 2011年05月08日 00:30, Mike Paquette 写道:
On May 7, 2011, at 8:40 AM, microcai wrote:
I know some basic theory of compositor. But I still have concern about
client window decorations. I think it is very likely an
message -
Von: Peng Huang shawn.p.hu...@gmail.com
Datum: So., Mai. 8, 2011 04:58
Betreff: client side decorations
An: Mike Paquette paquette...@gmail.com
Cc: Kristian Høgsberg k...@bitplanet.net, Sam Spilsbury
smspil...@gmail.com, wayland wayland-devel@lists.freedesktop.org,
mal...@lavabit.com
, 2011, at 9:27 AM, andre.knis...@gmx.de wrote:
Of course it is server side decoration, but it eliminates its main
problem.
- Reply message -
Von: Bill Spitzak spit...@gmail.com
Datum: So., Mai. 8, 2011 18:18
Betreff: Antw.: client side decorations
An: andre.knis...@gmx.de andre.knis
notion of what
client side decorations might be.
You obviously haven't read the previous mails in this thread or even
understand just the basics about how Wayland works. You're replying
with a sad anecdote about how you once used a windows system and
couldn't close the window
and kill them. Client side
decorations have many benefits, so maybe just have some special hotels or
similar for this.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
On 6 May 2011 08:25, Niklas Höglund nhogl...@gmail.com wrote:
so maybe just have some special hotels or similar for this.
Annoying text prediction. Hotkeys, not hotels.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
On 06/05/11 10:18, Bill Spitzak wrote:
I believe client-side decorations are an absolute must.
The amount of code necessary for an application to use an async protocol
to describe how the window border should appear is greatly larger than
that needed to just draw and handle events in the window
On 06/05/11 10:18, Bill Spitzak wrote:
I believe client-side decorations are an absolute must.
The amount of code necessary for an application to use an async protocol
to describe how the window border should appear is greatly larger than
that needed to just draw and handle events in the window
On Fri, May 6, 2011 at 8:18 AM, Bill Spitzak spit...@gmail.com wrote:
I believe client-side decorations are an absolute must.
The amount of code necessary for an application to use an async protocol to
describe how the window border should appear is greatly larger than that
needed to just
On 6 May 2011 09:42, Sam Spilsbury smspil...@gmail.com wrote:
You cannot assume that there will be a universally adopted method to
styling because we see on every single platform that there will *not*
be one. The best way to enforce styling is to enforce it at the window
manager level, so that
? Window group? Parent
Window? Window role? Desktop? Hardly nil. Take a look at how many
pages of stuff is in the freedesktop.org window manager hints.
I really don't think this is an issue to do with client side
decorations. If the window management policy can't handle the Gimp
case correctly
pages of
stuff is in the freedesktop.org window manager hints.
I really don't think this is an issue to do with client side
decorations. If the window management policy can't handle the Gimp
case correctly, then we need to revise our window management policy,
where of course I'm open to ideas
Window management policy should also be client-side. I may not have been
clear about that. The wayland compositer almost NEVER moves or raises or
resizes a window. Clients do this in response to clicks or whatever. This
would have made it TRIVIAL to implement Gimp the way they intended, as at
25 matches
Mail list logo
