> the way belongs to this.
>
> André
>
> - Reply message -----
> Von: "Daniel"
> Datum: Mo., Mai. 9, 2011 23:29
> Betreff: client side decorations
> An: "Bill Spitzak"
> Cc: "Høgsberg" , "Peng Huang" ,
> "Sam Spilsbury"
* microcai 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 thread at-all.
Wow, what
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
On 13 May 2011 06:05, Bill Spitzak wrote:
> 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 th
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 ex
于 2011年05月13日 01:47, Bill Spitzak 写道:
> 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 ide
On 12 May 2011 19:47, Bill Spitzak 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 stupid
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 re
On 12 May 2011 05:41, microcai wrote:
>
> 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
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
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 loo
On 11 May 2011 12:05, Russell Shaw wrote:
> On 11/05/11 18:55, Michal Suchanek wrote:
>>
>> On 10 May 2011 05:46, Russell Shaw 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
On 11/05/11 18:55, Michal Suchanek wrote:
On 10 May 2011 05:46, Russell Shaw 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
On 6 May 2011 21:14, cat wrote:
>> "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 im
On 10 May 2011 04:52, andre.knis...@gmx.de wrote:
> Actually, I think Iskren made a very important point. To take this one step
> further: with CSD, we can't force the client to stop drawing the decoration,
> we can only tell the client that it should. So we can assume Chrome having a
> decoration
On 10 May 2011 05:46, Russell Shaw 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 border, sin
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 border, since it implies
there are such concepts as "title bar" and "clos
nux on the desktop. Everything the average user wants to
do must be doable within the UI, and closing/moving dead windows out of the way
belongs to this.
André
- Reply message -
Von: "Daniel"
Datum: Mo., Mai. 9, 2011 23:29
Betreff: client side decorations
An: "Bill Spitzak
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
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 "composit
-
Von: "Bill Spitzak"
Datum: So., Mai. 8, 2011 18:49
Betreff: Antw.: client side decorations
An: "andre.knis...@gmx.de"
Cc:
Certainly there should be an easy way to get the "default window decorations".
I think the correct way is for the client to call an client-s
d
so on.
On May 8, 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"
Datum: So., Mai. 8, 2011 18:18
Betreff: Antw.: client side decorations
An: "andre.knis
On May 7, 2011, at 9:30 AM, Mike Paquette wrote:
Like I said, the compositor can call the client unconditional via
signal. No matter it is live or dead lock.
I'm not entirely sure this is a workable idea. Signals are not a
reliable inter-process communications mechanism. There are also
On May 7, 2011, at 12:18 AM, Russell Shaw wrote:
"not use overlapping windows" ?
Many applications use a bunch of top-level windows instead of MDI
windows
within windows. That's a limitation of the widget toolkits. It can
be done
ok with Xlib. If "internal" windows need maximize/minimize b
Of course it is server side decoration, but it eliminates its main problem.
- Reply message -
Von: "Bill Spitzak"
Datum: So., Mai. 8, 2011 18:18
Betreff: Antw.: client side decorations
An: "andre.knis...@gmx.de"
Cc:
On May 8, 2011, at 8:25 AM, andre.knis...@gmx
On May 8, 2011, at 8:25 AM, andre.knis...@gmx.de wrote:
As far as I can tell, the main problem with server side decoration
is that applications cannot modify them and thus they create their
own decoration. Please correct me if I'm wrong.
So why can't we enforce the WM to provide an API for m
before ;)
André
- Reply message -
Von: "Peng Huang"
Datum: So., Mai. 8, 2011 04:58
Betreff: client side decorations
An: "Mike Paquette"
Cc: "Kristian Høgsberg" , "Sam Spilsbury"
, "wayland" ,
, "Bill Spitzak" , "microca
On Sat, May 7, 2011 at 12:52 PM, microcai wrote:
> 于 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 application
On Sat, May 7, 2011 at 12:30 PM, Mike Paquette wrote:
>
> 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 application
> >> becomes unresponsive during resizing. O
于 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 application
>>> becomes unresponsive during resizing. Or a user tires to
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 application
>> becomes unresponsive during resizing. Or a user tires to resize a
>> unresponsive window. In that case,
On Sat, 2011-05-07 at 07:47 -0400, Peng Huang wrote:
> I am sorry if I said something wrong.
>
>
> I know some basic theory of compositor. But I still have concern
> about client window decorations. I think it is very likely an
> application becomes unresponsive during resizing. Or a user tires
uggested in the
> thread, before blabbering out with your preconceived 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
On 07/05/11 05:14, cat wrote:
"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
esize rules? Name? Icon name? Icon? Layer? 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 wind
orner, there are usually no major
issues. I'm using chromium for it's good html5 support, but I really don't
like the client-side decorations and there are thousands out there,
complainging about them, too.
- I don't use a "show desktop" button. When I want to go to my
于 2011年05月07日 06:01, cat Wrote
> -- Forwarded message --
> From: cat
> Date: 2011/5/6
> Subject: Re: client side decorations
> To: Kristian Høgsberg
>
>
>
>
> 2011/5/6 Kristian Høgsberg
>
>> On Fri, May 6, 2011 at 3:14 PM, cat wrote:
-- Forwarded message --
From: cat
Date: 2011/5/6
Subject: Re: client side decorations
To: Kristian Høgsberg
2011/5/6 Kristian Høgsberg
> On Fri, May 6, 2011 at 3:14 PM, cat wrote:
> >> "Window management policy" should also be client-side. I may not
On Fri, May 6, 2011 at 3:14 PM, cat wrote:
>> "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 TR
ion, but I ask that you at least read the other emails in the
thread. I'm not asking you to go read documentation or even code,
just fucking read what other people have already suggested in the
thread, before blabbering out with your preconceived notion of what
client side decorations might be.
>
> "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,
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
Layer? 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 handl
于 2011年05月06日 16:57, Niklas Höglund 写道:
> On 6 May 2011 09:42, Sam Spilsbury 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 wi
r the default behavior.
>
> We addressed this in a couple of interesting ways for a commercial OS using a
> Wayland-style window system. There, we had to support a traditional X
> server as a client, along with Carbon apps, which do client side decorations
> along with windo
On 6 May 2011 09:42, Sam Spilsbury 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 the application
On Fri, May 6, 2011 at 8:18 AM, 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
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 6 May 2011 08:25, "Niklas Höglund" 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
http://lists.freedesktop.org/mai
e if you can move, minimize 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
yle window system. There, we had to support a traditional X server
as a client, along with Carbon apps, which do client side decorations along
with window close, drag/move, and resize, and also Cocoa apps, which came from
a Display PostScript environment where server side code (written in
PostS
Kristian
On Thu, May 5, 2011 at 8:18 PM, 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 t
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 border itself.
In FLTK I would
54 matches
Mail list logo
