Re: client side decorations
Nothing has been said on this thread in some time, but I'd like to raise another issue. Clients have a menu or other means by which they access window manager functions. Things like "move to desktop 2". However this assumes a *lot* about the desktop model being used by the compositor, and fixes it to whatever the toolkits decide. It would not be possible to cleanly make a compositor which used any other way to manage windows. Tiling is one good example, the tasks used in kde4 are another. I was a strong believer in CSD until I realized I don't want to have to change the toolkit to make a new compositor feature usable/visible. On Mon, May 9, 2011 at 10:52 PM, 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 for example, what shouldn't be possible in a tiling WM. > Together with the other things he said, it would be almost impossible to > get a useable/useful tiling WM with CSD. > To the shortcuts discussion: do you really want every user to remember > shortcuts to use his desktop? This would be a huge step backwards for the > process of getting Linux 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" > Cc: "Høgsberg" , "Peng Huang" , > "Sam Spilsbury" , "Mike Paquette" < > paquette...@gmail.com>, "wayland" , < > mal...@lavabit.com>, , "microcai" < > micro...@fedoraproject.org> > > > 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 have clicks anywhere raise and move the non-responsive > > window, and lots of clicks (indicating user frustration) pop up a box > > offering to kill the program. On Linux, since it is standard, > > compositors can also have Alt+click always raise/move windows, and alt > > +right click pop up a menu of compositor-side window actions. > > > > This would be actually a good way to handle it. Use an special mode or > tool, a la xkill, to deal with stuck applications. It can take the form > of an special key/mouse combination, gestures, or as I said before, an > external tool like xkill. Note that it needs not be limited to killing, > but could do any other thing, like minimizing, sending to another > virtual desktop, etc. > > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
* 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 a reliable proposal. Server relies on client not doing bad things. When the client locks up, it's normally far too late to do anything useful there ... > So the libwayland-client must juse one signal internally. But there is > no problem here. GUI app usually don't use signals. Really ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 limited to > > - many web sites > - (some?) Adobe and HP software > - OS X (which actually prevents changing the DPI in the first place > leaving you with ridiculous font sizes) ... so, pretty much everything, then. Can we please move on? Thanks. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 the application deal >> with the DPI natively, we get better user experience. > > I think I didn't explain the problem right. I agree that it would be nice if > programs were DPI-aware. > > The problem is that the idiots doing both X and windows built in > DPI-awareness to only *PART* of the graphics api. Font sizes were chosen in > "points". EVERY OTHER GRAPHIC was measured in pixels. > > A graphics api where everything is measured in points (ie paying attention > to the DPI) would make sense. One where everything is measured in pixels > would also make sense. But this combination is a stupid idea and we are > paying for it today with the inability to scale graphics. In Wyland everything is measured in pixels, Wayland has no fonts. Problem solved. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 experience. I think I didn't explain the problem right. I agree that it would be nice if programs were DPI-aware. The problem is that the idiots doing both X and windows built in DPI-awareness to only *PART* of the graphics api. Font sizes were chosen in "points". EVERY OTHER GRAPHIC was measured in pixels. A graphics api where everything is measured in points (ie paying attention to the DPI) would make sense. One where everything is measured in pixels would also make sense. But this combination is a stupid idea and we are paying for it today with the inability to scale graphics. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
于 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 idea, and we should avoid it >> on the protocol side. > > The reason this had to be done was due to the incredibly stupid idea > that only *fonts* are measured in points, and every other graphic is > measured in pixels. This strange idea was on both X and Windows, likely > due to the initial programs being terminal emulators where there was no > graphics other than text. What this really means is that there are two > different coordinate systems for all the graphics, and programmers just > assumed these two systems always lined up exactly like they did on their > screen. 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 experience. > > After a lot of awful looking output on screens with different DPI, both > Windows and then X resorted to just forcing the DPI to 96, thus making > the systems obey the programmer's assumptions. Bad DPI settings are > still a bug on X, producing ridiculous large and tiny font sizes > unexpectedly, and this is NEVER wanted. > > The correct solution would have been to specify all coordinates in the > same units, likely 1 unit in the CTM. For practical reasons on > current-day screens this wants to be a pixel by default, but there is no > reason a program can't read the DPI and set the CTM to draw actual-size > graphics. > >> I suggest, DPI should also be windows specific, so that compositor can >> *scale it*. > > If I understand it right, a Wayland window has both a rectangle measured > in screen coordinates, and a source image that can be a different size. > The compositor is expected to transform the source image (scale it) to > fit in the rectangle. No, if the compositor want to *scale* it with eye candy, the client must scale it . not the compositor. The compositor change the DPI, then the client will scale it automatically. signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 idea, and we should avoid it >> on the protocol side. > > The reason this had to be done was due to the incredibly stupid idea that > only *fonts* are measured in points, and every other graphic is measured in > pixels. This strange idea was on both X and Windows, likely due to the > initial programs being terminal emulators where there was no graphics other > than text. What this really means is that there are two different coordinate > systems for all the graphics, and programmers just assumed these two systems > always lined up exactly like they did on their screen. > > After a lot of awful looking output on screens with different DPI, both 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 limited to - many web sites - (some?) Adobe and HP software - OS X (which actually prevents changing the DPI in the first place leaving you with ridiculous font sizes) Note that very first UIs were virtually bitmap-free and all the WM buttons and borders were vector graphics or generated on the spot from a few user-specified parameters (Windows 3.1, old stuff like mwm, olwm, fvwm, ..) and could be scaled to any size you specified. Then bitmaps were used heavily and made their way to stuff like window borders because the level of complexity people desired for their eye-candy could not be done with simple vector graphics anymore, and complex vector graphics required more power than people were willing to sacrifice for window borders. Still GTK bitmap themes have provisions for scaling the bitmaps to suit any text sizes in window captions and buttons. The button border will be relatively thinner to the text size (or thicker for smaller text) but will still render as intended, and people are free to choose a different theme. Similarly in Windows you can set different border sizes or font sizes if you accept that tons of braindead software breaks (eg. Adobe CS or HP scanner dialogs). Also Windows bitmapped window buttons look terribly on non-default sized borders but vector buttons are still available. The web is a problem because due to the specs being how they are they are not really friendly to people conscious about the look of their sites and many effects can't be achieved in a portable way without setting the element sizes exactly in pixels. You can say it's a defect in the specs or an error on the side of the people who are trying to stretch them to make their sites look flashy at the expense of usability but it's totally offtopic here. > Windows and then X resorted to just forcing the DPI to 96, thus making the > systems obey the programmer's assumptions. Bad DPI settings are still a bug > on X, producing ridiculous large and tiny font sizes unexpectedly, and this > is NEVER wanted. > > The correct solution would have been to specify all coordinates in the same > units, likely 1 unit in the CTM. For practical reasons on current-day > screens this wants to be a pixel by default, but there is no reason a > program can't read the DPI and set the CTM to draw actual-size graphics. Well, they can't on systems where DPI is always forced to be 96 regardless of the actual screen physical properties. Also this is reportedly[1] done so that people don't get ridiculously small text on TVs but it is at the expense of getting ridiculously small DPI on most netbooks and high-end notebooks so this is not really a good tradeoff IMHO. Thanks Michal [1] https://bugs.freedesktop.org/show_bug.cgi?id=23705 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 reason this had to be done was due to the incredibly stupid idea that only *fonts* are measured in points, and every other graphic is measured in pixels. This strange idea was on both X and Windows, likely due to the initial programs being terminal emulators where there was no graphics other than text. What this really means is that there are two different coordinate systems for all the graphics, and programmers just assumed these two systems always lined up exactly like they did on their screen. After a lot of awful looking output on screens with different DPI, both Windows and then X resorted to just forcing the DPI to 96, thus making the systems obey the programmer's assumptions. Bad DPI settings are still a bug on X, producing ridiculous large and tiny font sizes unexpectedly, and this is NEVER wanted. The correct solution would have been to specify all coordinates in the same units, likely 1 unit in the CTM. For practical reasons on current-day screens this wants to be a pixel by default, but there is no reason a program can't read the DPI and set the CTM to draw actual-size graphics. I suggest, DPI should also be windows specific, so that compositor can *scale it*. If I understand it right, a Wayland window has both a rectangle measured in screen coordinates, and a source image that can be a different size. The compositor is expected to transform the source image (scale it) to fit in the rectangle. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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. > > If the unusual application does care where its windows is , go and ask > the compositor. > > > And how big? > > They can't care how big a windows is in the pixel, but in the inch. > The application draws a bitmap so it must care about pixels but should also care about DPI. You could do it the other way around if you were drawing in vector graphics. For that go to OS X, or NEXT, those are the only two that support vector graphics natively AFAIK. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 windows is , go and ask the compositor. And how big? 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. I suggest, DPI should also be windows specific, so that compositor can *scale it*. signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 looks like a good idea. In fact doing some sketches it appears to be necessary for the compositor to tell the client to delete the decorations on each edge independently. and the client could publish a hint that it does draw decorations and its windows should not be decorated by the compositor (or it does not want decorations because it is a clock window and decorating it makes no sense). I don't think the compositor should ever decorate the windows so I very much disagree with any idea like this. It cannot draw into the texture for the window, as that memory belongs to the client. If the client is doing internal double-buffering, the compositor does not even have a pointer to the texture! Therefore the compositor would have to add extra surfaces that are the decorations. This could either be a larger underlay window, an overlay with a big transparent hole, or thin windows placed around the edges. The problem here is that resizing the window needs to be an atomic operation so the user never sees a partial update. This means that both windows must resize and have their image replaced in the same operation, while the images are produced by two different processes! This sounds very complex and difficult. When you add to this the insane amount of little details that clients need to send to control the decorations (such as whether there should be a resize box, etc) I think it is nonsense to ever consider such things. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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, 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 have clicks anywhere raise and move the non-responsive > window, and lots of clicks (indicating user frustration) pop up a box > offering to kill the program. On Linux, since it is standard, > compositors can also have Alt+click always raise/move windows, and alt > +right click pop up a menu of compositor-side window actions. > This would be actually a good way to handle it. Use an special mode or tool, a la xkill, to deal with stuck applications. It can take the form of an special key/mouse combination, gestures, or as I said before, an external tool like xkill. Note that it needs not be limited to killing, but could do any other thing, like minimizing, sending to another virtual desktop, etc. >>> >>> Keeping track of dead clients could be done like this: >>> >>> A client program opens a socket connection to the window server, >>> and the window server determines the PID of the client via a >>> means that the client has no control over (some kind of kernel >>> call that can determine the client using that socket). >>> >>> The client also sends the window server the title bar area >>> that contains the maximize/minimize/close buttons. >>> >>> All clients must handle an "is_alive" probe event from the window >>> server at any time, replying with something unspecified to confirm >>> it is not dead. >>> >>> Whenever the mouse is clicked in the title bar, the window server >>> can expect the client to send it an "is_alive" notification within >>> say 1 second. If it doesn't, the window server can send the client an >>> "is_alive" probe event. If there's no response after a certain time, >>> the window server can kill the client. Alternatively, it could pop up >>> a gui task manager window for the user to manually kill stuff. >> >> Clearly it's up to the user to decide if an application is stuck or not. >> >> The is_alive request may look like a nice idea at the first glance but >> it is not very reliable. >> >> How long timeout is allowed before the application is marked >> 'unresponsive'? This is clearly application and system specific. Any >> timeout based protocol is inherently unreliable. > > In X, dragging or resizing a window is instantaneous. The proposed > scheme was to allow a 1000 millisecond delay before assuming the > client was stuck. Far from it. Sometimes the application is actually doing something, not only idly waiting for the user to resize it. Sometimes it is swapped out and has to be swapped in to resize. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 box or window border, since it implies there are such concepts as "title bar" and "close box". The compositor can just have clicks anywhere raise and move the non-responsive window, and lots of clicks (indicating user frustration) pop up a box offering to kill the program. On Linux, since it is standard, compositors can also have Alt+click always raise/move windows, and alt +right click pop up a menu of compositor-side window actions. This would be actually a good way to handle it. Use an special mode or tool, a la xkill, to deal with stuck applications. It can take the form of an special key/mouse combination, gestures, or as I said before, an external tool like xkill. Note that it needs not be limited to killing, but could do any other thing, like minimizing, sending to another virtual desktop, etc. Keeping track of dead clients could be done like this: A client program opens a socket connection to the window server, and the window server determines the PID of the client via a means that the client has no control over (some kind of kernel call that can determine the client using that socket). The client also sends the window server the title bar area that contains the maximize/minimize/close buttons. All clients must handle an "is_alive" probe event from the window server at any time, replying with something unspecified to confirm it is not dead. Whenever the mouse is clicked in the title bar, the window server can expect the client to send it an "is_alive" notification within say 1 second. If it doesn't, the window server can send the client an "is_alive" probe event. If there's no response after a certain time, the window server can kill the client. Alternatively, it could pop up a gui task manager window for the user to manually kill stuff. Clearly it's up to the user to decide if an application is stuck or not. The is_alive request may look like a nice idea at the first glance but it is not very reliable. How long timeout is allowed before the application is marked 'unresponsive'? This is clearly application and system specific. Any timeout based protocol is inherently unreliable. In X, dragging or resizing a window is instantaneous. The proposed scheme was to allow a 1000 millisecond delay before assuming the client was stuck. It was assumed the user could also bring up a task manager with crtl-alt-delete and kill a client manually if needed. The application may have a separate thread to fulfill this "is_alive" requirement and the rest may still be stuck. The application may be running but in undesirable state which is not something the compositor can decide. An utility like xkill resolves all of the above. You don't like the application so you get rid of it. The compositor can resize or hide the application window at any time without any cooperation from the application. The application may publish hints as to how it wants the window content treated when it does not match the size of the displayed window and the compositor may use these to present the window in a reasonable way until the application resizes the content. This requires that the compositor notifies the application when the window is resized. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 implement Gimp the way they intended, as at no >> time would an image window raise above their toolbars, since they control >> both of them. > > > I wouldn't use wayland if thats the case, the kind of security risk this > creates is massive. you could have clients that refuse to cooerate and There is no security risk in allowing the Gimp to position its window relative to each other. You can see a half-hearted example of this on OS X. You can click the dock icon of a running application to raise all its windows above other applications but the z-order among the windows of the single application is preserved. > always take up the entire screen, or worse, rendering your computer useless. This is completely possible regardless of allowing z-order changes. AFAIK there is nothing stopping any application from creating several windows per second which will automatically get on the top in z-order and nothing stopping it from creating so large windows it will effectively kill the compositor (either by means of OOM killer or by means of swapping it out and having it run on swap. > also I never like muti window apps like the gimp, or openoffice. they draw > your attention away from what your doing to rearrange these little windows, > and what ever you do don't close them or would could spend the next hour > trying to get them back. there sould always be central system for making > windows behave or they won't The problem with multi-window applications is that multi-window UI is not really well supported neither in Windows nor in X-windows so you always get bad experience. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 for example, what shouldn't be possible in a tiling WM. > Together with the other things he said, it would be almost impossible to get > a useable/useful tiling WM with CSD. 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) and the client could publish a hint that it does draw decorations and its windows should not be decorated by the compositor (or it does not want decorations because it is a clock window and decorating it makes no sense). Either way you may end up with double decorations if both the application and the compositor insist on drawing decorations. The place to decide this is in the compositor (and user references specified in there) but you can't really stop applications from drawing anything they want in their windows. BTW you really do want server side decorations in some form to attach security labels to the applications so that you can eg. tell applications running as root or as different user or on different system apart from each other and the local applications. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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, since it implies >>> there are such concepts as "title bar" and "close box". The compositor >>> can just have clicks anywhere raise and move the non-responsive >>> window, and lots of clicks (indicating user frustration) pop up a box >>> offering to kill the program. On Linux, since it is standard, >>> compositors can also have Alt+click always raise/move windows, and alt >>> +right click pop up a menu of compositor-side window actions. >>> >> >> This would be actually a good way to handle it. Use an special mode or >> tool, a la xkill, to deal with stuck applications. It can take the form >> of an special key/mouse combination, gestures, or as I said before, an >> external tool like xkill. Note that it needs not be limited to killing, >> but could do any other thing, like minimizing, sending to another >> virtual desktop, etc. > > Keeping track of dead clients could be done like this: > > A client program opens a socket connection to the window server, > and the window server determines the PID of the client via a > means that the client has no control over (some kind of kernel > call that can determine the client using that socket). > > The client also sends the window server the title bar area > that contains the maximize/minimize/close buttons. > > All clients must handle an "is_alive" probe event from the window > server at any time, replying with something unspecified to confirm > it is not dead. > > Whenever the mouse is clicked in the title bar, the window server > can expect the client to send it an "is_alive" notification within > say 1 second. If it doesn't, the window server can send the client an > "is_alive" probe event. If there's no response after a certain time, > the window server can kill the client. Alternatively, it could pop up > a gui task manager window for the user to manually kill stuff. Clearly it's up to the user to decide if an application is stuck or not. The is_alive request may look like a nice idea at the first glance but it is not very reliable. How long timeout is allowed before the application is marked 'unresponsive'? This is clearly application and system specific. Any timeout based protocol is inherently unreliable. The application may have a separate thread to fulfill this "is_alive" requirement and the rest may still be stuck. The application may be running but in undesirable state which is not something the compositor can decide. An utility like xkill resolves all of the above. You don't like the application so you get rid of it. The compositor can resize or hide the application window at any time without any cooperation from the application. The application may publish hints as to how it wants the window content treated when it does not match the size of the displayed window and the compositor may use these to present the window in a reasonable way until the application resizes the content. This requires that the compositor notifies the application when the window is resized. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 "close box". The compositor can just have clicks anywhere raise and move the non-responsive window, and lots of clicks (indicating user frustration) pop up a box offering to kill the program. On Linux, since it is standard, compositors can also have Alt+click always raise/move windows, and alt +right click pop up a menu of compositor-side window actions. This would be actually a good way to handle it. Use an special mode or tool, a la xkill, to deal with stuck applications. It can take the form of an special key/mouse combination, gestures, or as I said before, an external tool like xkill. Note that it needs not be limited to killing, but could do any other thing, like minimizing, sending to another virtual desktop, etc. Keeping track of dead clients could be done like this: A client program opens a socket connection to the window server, and the window server determines the PID of the client via a means that the client has no control over (some kind of kernel call that can determine the client using that socket). The client also sends the window server the title bar area that contains the maximize/minimize/close buttons. All clients must handle an "is_alive" probe event from the window server at any time, replying with something unspecified to confirm it is not dead. Whenever the mouse is clicked in the title bar, the window server can expect the client to send it an "is_alive" notification within say 1 second. If it doesn't, the window server can send the client an "is_alive" probe event. If there's no response after a certain time, the window server can kill the client. Alternatively, it could pop up a gui task manager window for the user to manually kill stuff. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 for example, what shouldn't be possible in a tiling WM. Together with the other things he said, it would be almost impossible to get a useable/useful tiling WM with CSD. To the shortcuts discussion: do you really want every user to remember shortcuts to use his desktop? This would be a huge step backwards for the process of getting Linux 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" Cc: "Høgsberg" , "Peng Huang" , "Sam Spilsbury" , "Mike Paquette" , "wayland" , , , "microcai" 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 have clicks anywhere raise and move the non-responsive > window, and lots of clicks (indicating user frustration) pop up a box > offering to kill the program. On Linux, since it is standard, > compositors can also have Alt+click always raise/move windows, and alt > +right click pop up a menu of compositor-side window actions. > This would be actually a good way to handle it. Use an special mode or tool, a la xkill, to deal with stuck applications. It can take the form of an special key/mouse combination, gestures, or as I said before, an external tool like xkill. Note that it needs not be limited to killing, but could do any other thing, like minimizing, sending to another virtual desktop, etc. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 have clicks anywhere raise and move the non-responsive > window, and lots of clicks (indicating user frustration) pop up a box > offering to kill the program. On Linux, since it is standard, > compositors can also have Alt+click always raise/move windows, and alt > +right click pop up a menu of compositor-side window actions. > This would be actually a good way to handle it. Use an special mode or tool, a la xkill, to deal with stuck applications. It can take the form of an special key/mouse combination, gestures, or as I said before, an external tool like xkill. Note that it needs not be limited to killing, but could do any other thing, like minimizing, sending to another virtual desktop, etc. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 "compositors" display this memory the way they want to on screen. So, in my understanding there can be compositors drawing stuff around the windows (because they have all screen's content and they can mix it in whatever way they want), handle common shortcuts for close, move etc. And there can be other compositors that don't do anything like that. And both of these will be "wayland compositors". Or are you actually arguing to put some additional stuff to the wl protocol that will enable more "compositor side" actions (what is X currently doing)? And why is everybody talking about titlebars and close buttons? I think this is also part of the brain-damage, that years of using windows and mac has brought us. I'm using a tiling window manager, and I really can't understand why would anybody want titlebars & buttons on them, unless he/she really enjoys spending half of the time moving windows around so he can see them (if they "wobble" it is so much fun, I agree). And how do the tiling WMs in X fit the client vs server discussion. If it was all client side I assume no one cares about tiling windows anymore (no application developer), so simply there would be no tiling at all? There are things that should be common for all windows. Like closing, moving, resizing. Of course, because I'm using tiling window manager, this is all done through kb shortcuts, implemented in the server (I'm not sure if this fits the client vs server discussion, because this does not involve drawing "decorations" but certainly puts some overhead in the server to manage windows). I cant imagine anybody using his computer if these operations, are done through GUI and are done differently depending on the window. Of course this can be "solved" outside wayland by making GTK+, Qt more alike or creating additional communication channels between the clients and the servers. But this then tends to another discussion we had about screen locking, security, and vnc :) which was basically weather wl should make the protocol handle these things, or hardcode the "strange" parts (like a locking app) inside the compositor and use dbus or similar to link client and server for those out-of-core-wayland issues. (The discussion led to nowhere, as this one is also headed to). So what are you actually arguing about :) I mean -- just both sides explain in more detail what they want implemented where (in client, in server, in 3rd party), because otherwise it is going nowhere. Cheers, Iskren ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
The problem with this is this huge workaround talk we have right now. If we use server side decorations, this whole talk is useless, and as said before, the client could still do any modification to the decoration it wants (with the few wanted restrictions of course). - Reply message - 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-side "appearance library" that can draw these, tell the client about the sizes, and also can draw all the buttons and scroll bars and 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...@gmx.de" > Cc: > > > > 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 modifying the > > > > decorations? If a WM wouldn't implement it, we'd use some default > > > > decoration for applications that need to use the API. Chrome could > > for > > example get a surface to draw its tabs from KWin, and KWin > would > ensure > > the tabs don't overlap with the buttons, etc. > > I hope this wasn't proposed in the thousands of CSD posts before ;) > > No. What you are describing *IS* server-side decorations. I fully > agree > with the majority here that client-side is the way to go. > > > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 limits as to what state can be safely modified from within a signal handler. Non-async-signal-safe functions cannot be invoked from a signal handler. That would include functions that alter graphics state. A normal thread of execution within a client may not be coded to anticipate asynchronous modification of the current graphics state. I do not think the intention was to use a signal to communicate complex ideas to the client. It was just a last-ditch "wake up" before the client is killed for non-responsiveness, right? The solution to lock-up is for the clients themselves to use a ui thread that is different from any blocking operations. This is needed so that buttons and other controls don't "lock up". It is odd that people here put so much importance on resizing or closing apps when in reality users are just as frustrated when buttons inside the app don't respond. A client-side solution will fix all of these at once, and using the same code, reducing complexity. Now of course some apps are not going to do this, or do it incorrectly. Clients are expected to echo the handling of events back to the compositor (they can also indicate they ignored the event, allowing the compositor to send it elsewhere). If the client does not echo in a reasonable amount of time, the compositor can assume the client is locked up. It can then render the client window differently to indicate this (ie grayed out like Gnome does). It can also decide to do something with the events itself, such as move and raise or lower the window, or offer the user the chance to kill the program. This killing may be a signal that toolkits can decide to catch if they have some idea how to internally kill whatever is locking up, otherwise the program exits on the signal. 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 have clicks anywhere raise and move the non-responsive window, and lots of clicks (indicating user frustration) pop up a box offering to kill the program. On Linux, since it is standard, compositors can also have Alt+click always raise/move windows, and alt +right click pop up a menu of compositor-side window actions. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 buttons on a title bar, the application or widget toolkit will need to draw and manage them itself. I am not talking about MDI. On both X and Windows, it is impossible for an application to make windows A, B, and T (where T is a "toolbox" for instance) where T remains atop A *and* B at all times, while also T acts like a regular window in that other applications can appear atop it. "Solutions" have typically been to make "layers" where T remains atop everything. X also tried "window groups" which is what Gimp tried and tried to use, but had problems in that window managers never implemented them, partly because no programs used them but also because of stupidly complex design. If Gimp could completely control the front-to-back order of it's windows, the api it wants would be so trivial it is hard to believe. Gimp has tried to do this for years and has finally given up. Commercial software, especially stuff for Windows, gave up long ago. Everybody has reverted to a single window where all the toolboxes are "tiles" inside it. This is simply the result of the fact that they cannot control the window stacking, but thousands have been brainwashed into thinking that this method of avoiding system bugs is some kind of "feature". Layers are a very annoying and a security problem, and it is odd that some here are trying to claim these security problems caused by server- side window management will actually be a problem with client-side (in fact both will have problems but client-side is so much much simpler that I think it is easier to solve that way). I NEVER said Gimp could keep it's windows on top under client-side window management. It just can enforce T above both A and B, it cannot force T above windows it does not own. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 > >>> becomes unresponsive during resizing. Or a user tires to resize a > >>> unresponsive window. In that case, I don't know if compositor can draw > an > >>> updated title bar or just stretch the outdated window context to the > new > >>> size. At same time how the compositor calculate rectangles' size and > >>> position for title bar and buttons? > >>> > >>> Peng > >>> > >> > >> 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 limits as > to what state can be safely modified from within a signal handler. > Non-async-signal-safe functions cannot be invoked from a signal handler. > That would include functions that alter graphics state. A normal thread of > execution within a client may not be coded to anticipate asynchronous > modification of the current graphics state. > > > > The use of a lock to guard the graphics state is insufficient here. If > the graphics state is guarded by a lock, common when multiple asynchronous > threads are sharing a graphics state, then the signal handler must also > honor that lock. This can lead to a contention problem should the signal > handler be invoked on the thread already holding the lock. > > > > An application becoming unresponsive during app window resizing is an > application design problem, and is best addressed at the application level, > not as pat of the window server and compositor design. The window server > design should provide mechanisms, but strive to be as free of policy as > possible. Usability issues such as an unresponsive application are better > handled as part of the user interface policy mechanisms, implemented as part > of the toolkits and desktop management logic. > > > > The window server can provide the mechanisms to move, hide, show, and > resize windows. Decisions as to how to handle unresponsive applications and > present UI regarding these applications is best done at a higher level. > > > > Mike Paquette > > Just notify the client if it's alive. But if the client is sure to be > dead locking in some place (by checking the waiting channel of the > client), call it via signal. > > Since win2k.sys is in the kernel, so windows really does this logic. > > > But, if wayland is going to use client-side decoration, then we should > think more carefully, because we got zero help from the kernel side. > > Even so , client side decoration is still better than server side. > > Peng, client side decoration != client side window management. > Sorry. I don't understand how to use signals to resolve those kind of problems. When an application is locked, it is very likely with memory corruption too. I think libwayland should be a user space library. Its memory is not protected system, and it may be corrupted too. To resolve this problem, you have to find a way to protect the memory used by wayland library. As I know, only two solutions, putting code in kernel or in a separated process. Peng ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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. Or a user tires to resize a > >> unresponsive window. In that case, I don't know if compositor can draw > an > >> updated title bar or just stretch the outdated window context to the new > >> size. At same time how the compositor calculate rectangles' size and > >> position for title bar and buttons? > >> > >> Peng > >> > > > > 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 limits as to what > state can be safely modified from within a signal handler. > Non-async-signal-safe functions cannot be invoked from a signal handler. > That would include functions that alter graphics state. A normal thread of > execution within a client may not be coded to anticipate asynchronous > modification of the current graphics state. > > The use of a lock to guard the graphics state is insufficient here. If the > graphics state is guarded by a lock, common when multiple asynchronous > threads are sharing a graphics state, then the signal handler must also > honor that lock. This can lead to a contention problem should the signal > handler be invoked on the thread already holding the lock. > > An application becoming unresponsive during app window resizing is an > application design problem, and is best addressed at the application level, > not as pat of the window server and compositor design. The window server > design should provide mechanisms, but strive to be as free of policy as > possible. Usability issues such as an unresponsive application are better > handled as part of the user interface policy mechanisms, implemented as part > of the toolkits and desktop management logic. > I think when the system has high work load, and user try to resize an application, it is very likely the application will become unresponsive for several seconds (because high CPU load or need read some memory pages from swap). In this case, I don't know what will be the user experience of wayland. The user can not resize the application at all, or user can resize it, but the decoration and window context is outdated. In current X system, at least the decoration is updated and clickable. In another case. I find many applications which do some synchronized work (writing or downloading file, updating package, encoding, rendering and etc) in ui thread. That causes ui unresponsive. Although I know it is not good, but it is very easy way for not experienced developers. Writing async or multi-thread code is not easy for everyone. Those applications are not unusual, so wayland should try to provide better UX for them. At last, I want to ask how wayland draw focused and unfocsed window. If it draws different style decorations for them, it may cause mess when some windows are unresponsive. Probably users will find two focused window or can not find focused window on desktop. Peng > > The window server can provide the mechanisms to move, hide, show, and > resize windows. Decisions as to how to handle unresponsive applications and > present UI regarding these applications is best done at a higher level. > > Mike Paquette ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
于 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 resize a >>> unresponsive window. In that case, I don't know if compositor can draw an >>> updated title bar or just stretch the outdated window context to the new >>> size. At same time how the compositor calculate rectangles' size and >>> position for title bar and buttons? >>> >>> Peng >>> >> >> 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 limits as to what > state can be safely modified from within a signal handler. > Non-async-signal-safe functions cannot be invoked from a signal handler. > That would include functions that alter graphics state. A normal thread of > execution within a client may not be coded to anticipate asynchronous > modification of the current graphics state. > > The use of a lock to guard the graphics state is insufficient here. If the > graphics state is guarded by a lock, common when multiple asynchronous > threads are sharing a graphics state, then the signal handler must also honor > that lock. This can lead to a contention problem should the signal handler > be invoked on the thread already holding the lock. > > An application becoming unresponsive during app window resizing is an > application design problem, and is best addressed at the application level, > not as pat of the window server and compositor design. The window server > design should provide mechanisms, but strive to be as free of policy as > possible. Usability issues such as an unresponsive application are better > handled as part of the user interface policy mechanisms, implemented as part > of the toolkits and desktop management logic. > > The window server can provide the mechanisms to move, hide, show, and resize > windows. Decisions as to how to handle unresponsive applications and present > UI regarding these applications is best done at a higher level. > > Mike Paquette Just notify the client if it's alive. But if the client is sure to be dead locking in some place (by checking the waiting channel of the client), call it via signal. Since win2k.sys is in the kernel, so windows really does this logic. But, if wayland is going to use client-side decoration, then we should think more carefully, because we got zero help from the kernel side. Even so , client side decoration is still better than server side. Peng, client side decoration != client side window management. signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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, I don't know if compositor can draw an >> updated title bar or just stretch the outdated window context to the new >> size. At same time how the compositor calculate rectangles' size and >> position for title bar and buttons? >> >> Peng >> > > 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 limits as to what state can be safely modified from within a signal handler. Non-async-signal-safe functions cannot be invoked from a signal handler. That would include functions that alter graphics state. A normal thread of execution within a client may not be coded to anticipate asynchronous modification of the current graphics state. The use of a lock to guard the graphics state is insufficient here. If the graphics state is guarded by a lock, common when multiple asynchronous threads are sharing a graphics state, then the signal handler must also honor that lock. This can lead to a contention problem should the signal handler be invoked on the thread already holding the lock. An application becoming unresponsive during app window resizing is an application design problem, and is best addressed at the application level, not as pat of the window server and compositor design. The window server design should provide mechanisms, but strive to be as free of policy as possible. Usability issues such as an unresponsive application are better handled as part of the user interface policy mechanisms, implemented as part of the toolkits and desktop management logic. The window server can provide the mechanisms to move, hide, show, and resize windows. Decisions as to how to handle unresponsive applications and present UI regarding these applications is best done at a higher level. Mike Paquette ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 to > resize a unresponsive window. In that case, I don't know if compositor > can draw an updated title bar or just stretch the outdated window > context to the new size. At same time how the > compositor calculate rectangles' size and position for title bar and > buttons? > > Peng The client resizes itself. You can't "try to resize" an unresponsive client. In fact, it won't even show a resize cursor if the client isn't telling Wayland to as that is also done completely in the client. The simplest solution to moving windows when they're unresponsive is to simply define a WM key like you have in many X WMs (Hint: it's Alt). ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
2011/5/6 Kristian Høgsberg > On Fri, May 6, 2011 at 2:50 PM, Peng Huang > wrote: > > I still remember some old windows systems which use client side > decoration. > > When applications have some problems, you can not use close button to > close > > them. Any the whole decoration will not be repainted anymore, just leave > > users the background color. That is a really bad UX. > > I think server side decoration is a better solution. At same time, > wayland > > should allow an application to disable it, and draw its decoration by > self. > > Peng > > Listen, this is not OK. You're welcome to contribute to the > discussion, 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. > 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 the application didn't repaint. I'm > sure that was traumatizing, but it's not relevant to this discussion. > You're not helping anybody here, you're just spreading misinformation. > > I could suggest that you go back and read my suggestions, but that's > probably too much too ask, so I'll repeat them here: > > - the client can specify a rectangle (typically the title bar) where > the should interpret click-and-drag as a window move operation. This > lets the compositor move unresponsive windows around and is similar to > what Mike Paquette described. > > - the client can specify another kind of rectangle (typically the > close button), where the compositor should expect a certain response > (window going away, for example) within a few seconds or so. This > will let the compositor pop up a "Window didn't respond, force quit?" > dialog either immediately or on the second click attempt. > > - unresponsive windows wont go blank, the compositor has the contents > of the window and can repaint from that. The window contents will > stop updating, but the compositor doesn't rely on the apps being > responsive to repaint the screen. This is a key feature of composited > window systems. > 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 to resize a unresponsive window. In that case, I don't know if compositor can draw an updated title bar or just stretch the outdated window context to the new size. At same time how the compositor calculate rectangles' size and position for title bar and buttons? Peng > This was a flame. I don't do that often, but I'm fed up with all the > uninformed me-too that always happens in all the > client-side-decoration threads. > > Have a good weekend, > Kristian > > > On Fri, May 6, 2011 at 1:32 PM, Bill Spitzak wrote: > >> > >> Sam Spilsbury wrote: > >> > >>> Actually, I'm pretty sure in 99% of the cases out there the amount of > >>> code required for individual applications to have a window border > >>> using decorations done on the window manager side is going to be > >>> pretty much nil. > >> > >> Size? Resize 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 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 here. > >> > >> "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 no > >> time would an image window raise above their toolbars, since they > control > >> both of them. > >> > >> I think it is disgusting that for 30 years now we have been forced to > not > >> use overlapping windows, primarily due to the idiotic idea that the > system > >> should implement "click to top" (especially idiotic because of the > >> incredible triviality of making the client do that). Every major > application > >> (including Gimp...) has been forced to use a single window with a > "tiled" > >> interior, and perhaps some pop-up "child" windows, because of this bug > and > >> am really really hoping Wayland will finally fix it. > >> > >> To handle locked windows the compositor certainly can move, raise, lower > >> and unmap them. It can do
Re: client side decorations
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 implement Gimp the way they intended, as at no time would an image window raise above their toolbars, since they control both of them. I wouldn't use wayland if thats the case, the kind of security risk this creates is massive. you could have clients that refuse to cooerate and always take up the entire screen, or worse, rendering your computer useless. also I never like muti window apps like the gimp, or openoffice. they draw your attention away from what your doing to rearrange these little windows, and what ever you do don't close them or would could spend the next hour trying to get them back. there sould always be central system for making windows behave or they won't A bad gui is no different to a non-gui app with bad code. Either fix it, fork it, or don't install it. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
On 07/05/11 03:32, Bill Spitzak wrote: Sam Spilsbury wrote: Actually, I'm pretty sure in 99% of the cases out there the amount of code required for individual applications to have a window border using decorations done on the window manager side is going to be pretty much nil. Size? Resize 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 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 here. "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 no time would an image window raise above their toolbars, since they control both of them. I think it is disgusting that for 30 years now we have been forced to not use overlapping windows, primarily due to the idiotic idea that the system should implement "click to top" (especially idiotic because of the incredible triviality of making the client do that). Every major application (including Gimp...) has been forced to use a single window with a "tiled" interior, and perhaps some pop-up "child" windows, because of this bug and am really really hoping Wayland will finally fix it. "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 buttons on a title bar, the application or widget toolkit will need to draw and manage them itself. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
sorry for forgetting the subject, I had one first but then kmail2 beta failed to send the mail and I forgot about the subject when using webmail On Thu, 5 May 2011 05:18:23 PM Bill Spitzak wrote: > The claim that users are confused by mismatched window borders is not > backed by evidence either. It is pretty clear users can operate their > media players and games despite them bypassing the system window > borders, and are not having trouble with Chromium either. This is not exactly true. As long as applications keep the convention of minimize-maximize-close in the right upper corner, 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 desktop, I minimize all maximized windows first, clicking the area of the minimize button. Chromium's minimize button is in a slightly different place, consequently, I'm missing it. - Chromium resizes maximized windows when clicking the titlebar. KWin resizes maximized windows, when dragging the titlebar down. This is a really annoying inconsistency I needed to get used to. Especially in combination with the problem described above - it can happen that you click an empty space instead of a button. When you like your titlebar buttons on the left, that's when things really start to get ugly... And this is just with two different decorations, if wayland provides no way to get uniform decorations, it's going to look a lot worse. As for the case of games an media players, I think you are referring to Windows. Windows has a default decoration who's behaviour the vast majority of applications with custom decorations copy. A desktop is likely to be running GTK+ and Qt applications. X applications will be common, at least in the beginning. Some people use wine, which will eventually be ported to Wayland, too. Let's say, you are playing around with 3D design using blender. And there is this game, you like to play, that isn't using full screen. That makes six different decorations (five if there is a way to make GTK+ und Qt look alike), that won't possibly agree on common sizes and positions for borders and buttons, context menus, areas to grab for resizing and what to do when clicking on the titlebar. So please, for usabilities sake, provide a way (possibly outside of wayland, but inside would be better to make it a commonly accepted standard) to use a highly themable, default decoration with themes being able to use any toolkit so that a toolkit (or third party) can provide a theme that matches it's default decoration. This would result in two different decorations for most desktops (one if there is a way to make Qt and GTK+ look alike). Malte E. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
于 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: >>>> "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 no >>>> time would an image window raise above their toolbars, since they >> control >>>> both of them. >>> >>> >>> I wouldn't use wayland if thats the case, the kind of security risk this >>> creates is massive. you could have clients that refuse to cooerate and >>> always take up the entire screen, or worse, rendering your computer >> useless. >>> also I never like muti window apps like the gimp, or openoffice. they >> draw >>> your attention away from what your doing to rearrange these little >> windows, >>> and what ever you do don't close them or would could spend the next hour >>> trying to get them back. there sould always be central system for making >>> windows behave or they won't >> >> I don't know what window system you're currently using, but if you're >> using X, hit Ctrl-Alt-Backspace now, because it has all the same >> problems. >> > > that key combination has been disabled in Xorg by default for a while, which > is extreamly annoying because X runs rather well without a config. also a > new problem is that programs that lock up like to take focus and the only > way to recover then is the magic sysrq keys. really I have just gone back to > using the power button. atleast that still cut off power after 4 seconds. > > > And you should go read my reply to Peng, because it applies to you too. >> > I like some of the suggestions that have been put forward. but Bill made > sound as though wayland clients should do everything by themselves. why then > use the compositor? > I know that, Windows push every windows stuff to client. They had default toolkit called DefWindowProc. And now, they think they made a mistake. Then they are trying to recover, to do things like compiz. Client side windows management does not help much. The windows get help from the *kernel*, and still can't do things better. The wayland? We don't have kernel module to help us force the policy to the client! If the client refuse to cooperate, then everything is gone. You think windows can do it in client way, so do wayland? NO! They got help from the kernel! They had something called LPC, so dead lock app can still run DefWindowProc if the kernel want it response the message. As for wayland, we are not so lucky. Think of it, how do you suppose to close the misbehaved window? To move the dead window? So, client side window management is wrong unless you got help from the kernel side. But client side window decoration is not wrong. non-uniform looking? EM. they use the toolkit, but the toolkit in return use libwayland! libwayland can do the drawing. For the sake of app developers, libwayland drawing is no much different than compositor drawing. But, hey, wait a second! In fact , windows do not even have decorations ! decorations is just another sub window created *automatically* when you call CreateWindowEx . The close button? another subwindow belongs to the decoration. This way, they simplify the windowing system for not treating decorations specially. signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 TRIVIAL to implement Gimp the way they intended, as at no >> time would an image window raise above their toolbars, since they control >> both of them. > > > I wouldn't use wayland if thats the case, the kind of security risk this > creates is massive. you could have clients that refuse to cooerate and > always take up the entire screen, or worse, rendering your computer useless. > also I never like muti window apps like the gimp, or openoffice. they draw > your attention away from what your doing to rearrange these little windows, > and what ever you do don't close them or would could spend the next hour > trying to get them back. there sould always be central system for making > windows behave or they won't I don't know what window system you're currently using, but if you're using X, hit Ctrl-Alt-Backspace now, because it has all the same problems. And you should go read my reply to Peng, because it applies to you too. Kristian ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
On Fri, May 6, 2011 at 2:50 PM, Peng Huang wrote: > I still remember some old windows systems which use client side decoration. > When applications have some problems, you can not use close button to close > them. Any the whole decoration will not be repainted anymore, just leave > users the background color. That is a really bad UX. > I think server side decoration is a better solution. At same time, wayland > should allow an application to disable it, and draw its decoration by self. > Peng Listen, this is not OK. You're welcome to contribute to the discussion, 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. 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 the application didn't repaint. I'm sure that was traumatizing, but it's not relevant to this discussion. You're not helping anybody here, you're just spreading misinformation. I could suggest that you go back and read my suggestions, but that's probably too much too ask, so I'll repeat them here: - the client can specify a rectangle (typically the title bar) where the should interpret click-and-drag as a window move operation. This lets the compositor move unresponsive windows around and is similar to what Mike Paquette described. - the client can specify another kind of rectangle (typically the close button), where the compositor should expect a certain response (window going away, for example) within a few seconds or so. This will let the compositor pop up a "Window didn't respond, force quit?" dialog either immediately or on the second click attempt. - unresponsive windows wont go blank, the compositor has the contents of the window and can repaint from that. The window contents will stop updating, but the compositor doesn't rely on the apps being responsive to repaint the screen. This is a key feature of composited window systems. This was a flame. I don't do that often, but I'm fed up with all the uninformed me-too that always happens in all the client-side-decoration threads. Have a good weekend, Kristian > On Fri, May 6, 2011 at 1:32 PM, Bill Spitzak wrote: >> >> Sam Spilsbury wrote: >> >>> Actually, I'm pretty sure in 99% of the cases out there the amount of >>> code required for individual applications to have a window border >>> using decorations done on the window manager side is going to be >>> pretty much nil. >> >> Size? Resize 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 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 here. >> >> "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 no >> time would an image window raise above their toolbars, since they control >> both of them. >> >> I think it is disgusting that for 30 years now we have been forced to not >> use overlapping windows, primarily due to the idiotic idea that the system >> should implement "click to top" (especially idiotic because of the >> incredible triviality of making the client do that). Every major application >> (including Gimp...) has been forced to use a single window with a "tiled" >> interior, and perhaps some pop-up "child" windows, because of this bug and >> am really really hoping Wayland will finally fix it. >> >> To handle locked windows the compositor certainly can move, raise, lower >> and unmap them. It can do this if the user holds down certain keys, or if it >> detects the application is locked up, or if the user picks menu items. >> >>> On windows all we see is that applications can draw widgets inside the >>> existing window border style. This works well in every case I've seen >>> it - chromium, firefox, office, you name it. >> >> No on Windows an application can add drawings to the title bar. It is >> pretty clear that applications are assuming the default Vista colors and >> button sizes and layouts when making these drawings, thus defeating theming. >> >>> We still have the problem of not having a universal toolkit to handle >>> these things, and the reality of the matter is that a lot of >>> proprietary applicat
Re: client side decorations
> > "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 no > time would an image window raise above their toolbars, since they control > both of them. > I wouldn't use wayland if thats the case, the kind of security risk this creates is massive. you could have clients that refuse to cooerate and always take up the entire screen, or worse, rendering your computer useless. also I never like muti window apps like the gimp, or openoffice. they draw your attention away from what your doing to rearrange these little windows, and what ever you do don't close them or would could spend the next hour trying to get them back. there sould always be central system for making windows behave or they won't ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
I still remember some old windows systems which use client side decoration. When applications have some problems, you can not use close button to close them. Any the whole decoration will not be repainted anymore, just leave users the background color. That is a really bad UX. I think server side decoration is a better solution. At same time, wayland should allow an application to disable it, and draw its decoration by self. Peng On Fri, May 6, 2011 at 1:32 PM, Bill Spitzak wrote: > Sam Spilsbury wrote: > > Actually, I'm pretty sure in 99% of the cases out there the amount of >> code required for individual applications to have a window border >> using decorations done on the window manager side is going to be >> pretty much nil. >> > > Size? Resize 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 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 here. >> > > "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 no > time would an image window raise above their toolbars, since they control > both of them. > > I think it is disgusting that for 30 years now we have been forced to not > use overlapping windows, primarily due to the idiotic idea that the system > should implement "click to top" (especially idiotic because of the > incredible triviality of making the client do that). Every major application > (including Gimp...) has been forced to use a single window with a "tiled" > interior, and perhaps some pop-up "child" windows, because of this bug and > am really really hoping Wayland will finally fix it. > > To handle locked windows the compositor certainly can move, raise, lower > and unmap them. It can do this if the user holds down certain keys, or if it > detects the application is locked up, or if the user picks menu items. > > > On windows all we see is that applications can draw widgets inside the >> existing window border style. This works well in every case I've seen >> it - chromium, firefox, office, you name it. >> > > No on Windows an application can add drawings to the title bar. It is > pretty clear that applications are assuming the default Vista colors and > button sizes and layouts when making these drawings, thus defeating theming. > > > We still have the problem of not having a universal toolkit to handle >> these things, and the reality of the matter is that a lot of >> proprietary applications are not going to want to use these toolkits. >> > > I have no idea why you think that making the window borders match is all > that is needed. What about the buttons and menus and toolbars and scroll > bars and how editing is done? If this is important I would much rather see a > solution that addresses all of these, rather than somehow saying the window > borders are "special". > > > 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 applications on the system actually obey >> what the user wants them to do, not some crazy idea that the >> application developer had. >> > > And this is true on X and Windows today. People bypass the system and draw > their own window borders. And the result is far worse than if the system was > designed for this from the start. Lets not repeat these mistakes. > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
Sam Spilsbury wrote: Actually, I'm pretty sure in 99% of the cases out there the amount of code required for individual applications to have a window border using decorations done on the window manager side is going to be pretty much nil. Size? Resize 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 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 here. "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 no time would an image window raise above their toolbars, since they control both of them. I think it is disgusting that for 30 years now we have been forced to not use overlapping windows, primarily due to the idiotic idea that the system should implement "click to top" (especially idiotic because of the incredible triviality of making the client do that). Every major application (including Gimp...) has been forced to use a single window with a "tiled" interior, and perhaps some pop-up "child" windows, because of this bug and am really really hoping Wayland will finally fix it. To handle locked windows the compositor certainly can move, raise, lower and unmap them. It can do this if the user holds down certain keys, or if it detects the application is locked up, or if the user picks menu items. On windows all we see is that applications can draw widgets inside the existing window border style. This works well in every case I've seen it - chromium, firefox, office, you name it. No on Windows an application can add drawings to the title bar. It is pretty clear that applications are assuming the default Vista colors and button sizes and layouts when making these drawings, thus defeating theming. We still have the problem of not having a universal toolkit to handle these things, and the reality of the matter is that a lot of proprietary applications are not going to want to use these toolkits. I have no idea why you think that making the window borders match is all that is needed. What about the buttons and menus and toolbars and scroll bars and how editing is done? If this is important I would much rather see a solution that addresses all of these, rather than somehow saying the window borders are "special". 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 applications on the system actually obey what the user wants them to do, not some crazy idea that the application developer had. And this is true on X and Windows today. People bypass the system and draw their own window borders. And the result is far worse than if the system was designed for this from the start. Lets not repeat these mistakes. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
于 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 window >> manager level, so that the applications on the system actually obey >> what the user wants them to do, not some crazy idea that the >> application developer had. > > Isn't the point of free software that we allow people to do what they want? > > Yes, some application might do something you really don't agree with, > but you don't need to use that application. USE, not NOT TO USE, this is windows way, not our way. Our way, is not just a choise to use , but a control over how it runs. signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
于 2011年05月06日 12:50, Mike Paquette 写道: > > On May 5, 2011, at 6:10 PM, Kristian Høgsberg wrote: > >> Also, the concern about not being able to close and moving hung apps >> just seems blown out of proportion. Yes, it's a neat feature that X >> WMs can deal with this, but it's just about the only good thing in >> that approach and it comes at the cost of all the complexity of trying >> to sync the look and feel of two apps living in the same window. And >> realistically, how often is this really a problem? I can't remember >> when I last had to deal with an unresponsive application, and I think >> I might have killed it form the panel or command line instead. And >> it's possible to work around this to some extent, by letting the app >> specify a rect where the compositor should grab button 1 and start a >> move, for example. Perhaps a rectangle (ie, the close button) where >> the application has to acknowledge buttons clicks within a second or >> so, or it will be assumed unresponsive and the compositor can pop up >> the "This guy is not responding, force quit?" dialog. 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. So the libwayland-client must juse one signal internally. But there is no problem here. GUI app usually don't use signals. This can simply the protocol. Client don't need to say, hey, this is the rectangle for balabala Even some app can still provide it's own signal hander for great control over 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 window close, drag/move, and resize, and also Cocoa apps, which > came from a Display PostScript environment where server side code (written in > PostScript!) handled event processing and window close, drag/move, and resize > operations independent of the apps. > > We were dropping server-side drawing operations with the move away from > Display PostScript, but there was still a desire to be able to move app > windows, and at least order them off-screen, even if an app wasn't > responsive. To provide this we allowed apps to describe a drag shape > (Graphics Gems II, p. 31-45 as a starting point) within which a server-side > drag loop would be invoked when the designated mouse drag button was down. > Any app toolkit that set this shape could have it's windows dragged > asynchronously with respect to the app. A 'WindowDidMove' event is posted on > the mouse-up ending the drag loop that the client app toolkit could subscribe > to. > > We also allowed for the idea of a 'universal window owner,' a specially > designated client that would be permitted to do limited manipulation of the > windows of other apps. This 'universal owner' property is used by desktop > manager processes to order windows off-screen if needed, as well as to handle > some specialized operations such as multiple workspace management. > > There is also a mechanism that can detect when an app isn't picking up > pending events, which was introduced a couple decades back to trigger the > dreaded wait cursor (Spinning Pizza of Death). This mechanism can also be > used to spot unresponsive applications. A special event can be sent to a > desktop manager process to let it know when an app is hung, allowing it to > alter the appearance of the UI. Unity might, for example, be extended to > turn the running app indicator red, or a menu item 'Quit' could change to > 'Force Quit.' > > Mike Paquette > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel signature.asc Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 applications on the system actually obey > what the user wants them to do, not some crazy idea that the > application developer had. Isn't the point of free software that we allow people to do what they want? Yes, some application might do something you really don't agree with, but you don't need to use that application. -- Niklas ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 draw and handle events in the window border itself. In FLTK I > would estimate the ICCCM code for the window object is about 5 times larger > than the code for an otherwise similar MDI-like frame where FLTK draws > everything. Handling resize and other events cleanly is a real mess, too, > due to the async nature of them. Actually, I'm pretty sure in 99% of the cases out there the amount of code required for individual applications to have a window border using decorations done on the window manager side is going to be pretty much nil. What we currently have is a situation where applications are re-parented at an offset into frame windows (which is a good idea for a number of other window management policy reasons) and all those applications ever need to care about is drawing their content. With the solution I proposed, we're going to have the situation where either (a) windows don't claim to support the window manager drawing their background, so we just revert to the old behaviour of re-parenting the application in at an offset to make room for the decoration or (b) the application claims to support the specification, and does NOT draw it's background (only widgets on a transparent surface), specifies either a background pixmap or uses the default and gets reparented into the frame window at 0x0 so it can draw whatever it wants in the titlebar area. I really don't think lines of code is a fair comparison here, especially for ICCCM window objects since this specification handles a lot more than just decorations (it also handles a lot of the client-to-window manager communication, which are really just work-a-rounds for broken design in X). I would imagine that in most cases, most clients are only going to want a simple decoration, consistent with everything else to provide a close, minimize and maximize button and then call it a day. It's only in extremely rare cases where we have clients the try to differentiate themselves by "optimizing" the chrome in ways that they think fits the UX. And even in this case, I believe it is the role of the window manager to confine how much this should be done and how much consistency there is for the user. Sure, chromium is easy to use these days because the chromium developers are interested in ensuring that there is consistency in their application. However, there are still applications which present a broken user experience to the user (canonical example: windows media player), OR there are times when the window manager wishes to change policy on how things are positioned (eg, the famous "buttons on the left" case) and then we need to wait on every single application to play catch-up to be consistent. Even if we had a separate library to describe and even draw the decorations, there is no way that we can enforce applications to use this library, and the chances are that there are going to be popular applications that will *not* use this library. > > Also such designs lock the user interface ideas into whatever existed at > that time, an excellent example is Gimp's being forced to give up any > attempt to make multiple windows because of window managers failing to > implement the many controls it would need. Whether Gimp's idea is right or > wrong, it would have been trivial to implement it if Gimp itself could > control the appearance and raising and mapping of windows without the window > manager messing with it. 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 here. > > Attempts to make this api expandable makes things worse. On Windows it is > possible to add some icons to them, and programs are doing so, but those > icons are not obeying the "style" at all, and are making assumptions about > the dimensions and colors of what is there, so the end result is that it is > *less* possible to customize the window border appearance. On windows all we see is that applications can draw widgets inside the existing window border style. This works well in every case I've seen it - chromium, firefox, office, you name it. > > As for making them all look alike, this can and should be solved by whatever > mechanism is used to make the buttons and scroll bars inside applications > look alike. An "appearance library" that reads user configuration and has > calls to draw buttons, window borders, etc, would work for this. Obviously > the api complexity and inability to innovate problems would be there but at > least they would synchronous! Also there would be many levels of access, > allowing new api ideas to be impleme
Re: client side decorations
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 border itself. In FLTK I would estimate the ICCCM code for the window object is about 5 times larger than the code for an otherwise similar MDI-like frame where FLTK draws everything. Handling resize and other events cleanly is a real mess, too, due to the async nature of them. Also such designs lock the user interface ideas into whatever existed at that time, an excellent example is Gimp's being forced to give up any attempt to make multiple windows because of window managers failing to implement the many controls it would need. ... Any program could manage the internals of their own "desktop" window, acting like a sub window manager for other windows belonging to that program. The program would need to draw its own maximize/minimize/close buttons. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 border itself. In FLTK I would estimate the ICCCM code for the window object is about 5 times larger than the code for an otherwise similar MDI-like frame where FLTK draws everything. Handling resize and other events cleanly is a real mess, too, due to the async nature of them. Also such designs lock the user interface ideas into whatever existed at that time, an excellent example is Gimp's being forced to give up any attempt to make multiple windows because of window managers failing to implement the many controls it would need. ... Any program could manage the internals of their own "desktop" window, acting like a sub window manager for other windows belonging to that program. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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/mailman/listinfo/wayland-devel
Re: client side decorations
On 6 May 2011 02:10, "Kristian Høgsberg" wrote: > I can't remember > when I last had to deal with an unresponsive application I had this happen to me in Windows XP yesterday. To be fair, I was pushing the machine by running two VMs, one of which was running Windows update. Chrome may have been paged out. When I clicked in it it didn't respond, and when I tried to minimize it that locked up window operations in the whole desktop. Nothing responded to clicks and I couldn't switch active windows. After about a minute it came back into life. Probably when things had gotten paged back in. It's not a nice situation. I see badly behaved apps often in Linux as well. I think its important that you can switch active windows and move other windows on top of unresponsive ones, so that you can say start a process monitor and kill it. It's also nice 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
Re: client side decorations
On May 5, 2011, at 6:10 PM, Kristian Høgsberg wrote: > Also, the concern about not being able to close and moving hung apps > just seems blown out of proportion. Yes, it's a neat feature that X > WMs can deal with this, but it's just about the only good thing in > that approach and it comes at the cost of all the complexity of trying > to sync the look and feel of two apps living in the same window. And > realistically, how often is this really a problem? I can't remember > when I last had to deal with an unresponsive application, and I think > I might have killed it form the panel or command line instead. And > it's possible to work around this to some extent, by letting the app > specify a rect where the compositor should grab button 1 and start a > move, for example. Perhaps a rectangle (ie, the close button) where > the application has to acknowledge buttons clicks within a second or > so, or it will be assumed unresponsive and the compositor can pop up > the "This guy is not responding, force quit?" dialog. 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 window close, drag/move, and resize, and also Cocoa apps, which came from a Display PostScript environment where server side code (written in PostScript!) handled event processing and window close, drag/move, and resize operations independent of the apps. We were dropping server-side drawing operations with the move away from Display PostScript, but there was still a desire to be able to move app windows, and at least order them off-screen, even if an app wasn't responsive. To provide this we allowed apps to describe a drag shape (Graphics Gems II, p. 31-45 as a starting point) within which a server-side drag loop would be invoked when the designated mouse drag button was down. Any app toolkit that set this shape could have it's windows dragged asynchronously with respect to the app. A 'WindowDidMove' event is posted on the mouse-up ending the drag loop that the client app toolkit could subscribe to. We also allowed for the idea of a 'universal window owner,' a specially designated client that would be permitted to do limited manipulation of the windows of other apps. This 'universal owner' property is used by desktop manager processes to order windows off-screen if needed, as well as to handle some specialized operations such as multiple workspace management. There is also a mechanism that can detect when an app isn't picking up pending events, which was introduced a couple decades back to trigger the dreaded wait cursor (Spinning Pizza of Death). This mechanism can also be used to spot unresponsive applications. A special event can be sent to a desktop manager process to let it know when an app is hung, allowing it to alter the appearance of the UI. Unity might, for example, be extended to turn the running app indicator red, or a menu item 'Quit' could change to 'Force Quit.' Mike Paquette ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
Bill, Thanks, you've basically made all my points for me. I would add that there are also lower level benefits to having the clients render the decorations: when the entire window is in one texture, gl can do bilinear filtering along the edge between the decorations and the window contents, and we avoid jagged edges when the window is transformed. Also, the concern about not being able to close and moving hung apps just seems blown out of proportion. Yes, it's a neat feature that X WMs can deal with this, but it's just about the only good thing in that approach and it comes at the cost of all the complexity of trying to sync the look and feel of two apps living in the same window. And realistically, how often is this really a problem? I can't remember when I last had to deal with an unresponsive application, and I think I might have killed it form the panel or command line instead. And it's possible to work around this to some extent, by letting the app specify a rect where the compositor should grab button 1 and start a move, for example. Perhaps a rectangle (ie, the close button) where the application has to acknowledge buttons clicks within a second or so, or it will be assumed unresponsive and the compositor can pop up the "This guy is not responding, force quit?" dialog. These ideas are still somewhat ad-hoc, clumsy, but still a lot simpler than all the mechanisms we have now to enable the out-of-process decorations model. 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 to just draw and handle events in the window border itself. In FLTK I > would estimate the ICCCM code for the window object is about 5 times larger > than the code for an otherwise similar MDI-like frame where FLTK draws > everything. Handling resize and other events cleanly is a real mess, too, > due to the async nature of them. > > Also such designs lock the user interface ideas into whatever existed at > that time, an excellent example is Gimp's being forced to give up any > attempt to make multiple windows because of window managers failing to > implement the many controls it would need. Whether Gimp's idea is right or > wrong, it would have been trivial to implement it if Gimp itself could > control the appearance and raising and mapping of windows without the window > manager messing with it. > > Attempts to make this api expandable makes things worse. On Windows it is > possible to add some icons to them, and programs are doing so, but those > icons are not obeying the "style" at all, and are making assumptions about > the dimensions and colors of what is there, so the end result is that it is > *less* possible to customize the window border appearance. > > The claim that users are confused by mismatched window borders is not backed > by evidence either. It is pretty clear users can operate their media players > and games despite them bypassing the system window borders, and are not > having trouble with Chromium either. > > As for making them all look alike, this can and should be solved by whatever > mechanism is used to make the buttons and scroll bars inside applications > look alike. An "appearance library" that reads user configuration and has > calls to draw buttons, window borders, etc, would work for this. Obviously > the api complexity and inability to innovate problems would be there but at > least they would synchronous! Also there would be many levels of access, > allowing new api ideas to be implemented. > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: client side decorations
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 estimate the ICCCM code for the window object is about 5 times larger than the code for an otherwise similar MDI-like frame where FLTK draws everything. Handling resize and other events cleanly is a real mess, too, due to the async nature of them. Also such designs lock the user interface ideas into whatever existed at that time, an excellent example is Gimp's being forced to give up any attempt to make multiple windows because of window managers failing to implement the many controls it would need. Whether Gimp's idea is right or wrong, it would have been trivial to implement it if Gimp itself could control the appearance and raising and mapping of windows without the window manager messing with it. Attempts to make this api expandable makes things worse. On Windows it is possible to add some icons to them, and programs are doing so, but those icons are not obeying the "style" at all, and are making assumptions about the dimensions and colors of what is there, so the end result is that it is *less* possible to customize the window border appearance. The claim that users are confused by mismatched window borders is not backed by evidence either. It is pretty clear users can operate their media players and games despite them bypassing the system window borders, and are not having trouble with Chromium either. As for making them all look alike, this can and should be solved by whatever mechanism is used to make the buttons and scroll bars inside applications look alike. An "appearance library" that reads user configuration and has calls to draw buttons, window borders, etc, would work for this. Obviously the api complexity and inability to innovate problems would be there but at least they would synchronous! Also there would be many levels of access, allowing new api ideas to be implemented. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
