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
client side decorations
-- 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? > > Kristian > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Add configure option to disable scanner compilation which is helpful for cross-compilation
On Fri, May 6, 2011 at 2:13 AM, wrote: > When cross-compiling Wayland, wayland-scanner should be picked up from the > host system instead of compiling and trying to run e.g. ARM wayland-scanner > on X86. > > This patch adds --disable-scanner option for disabling the scanner from the > build and using existing wayland-scanner instead (from PATH) which should > help in most cross-compilation systems. > > By default everything works as before. Thanks, that's useful, applied. I trimmed the commit message to fit within 80 colums. Kristian > Signed-off-by: Jani Uusi-Rantala > --- > configure.ac | 8 > wayland/Makefile.am | 8 > 2 files changed, 16 insertions(+), 0 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 34b8dbc..7dc8ccb 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -27,6 +27,14 @@ if test "x$GCC" = "xyes"; then > fi > AC_SUBST(GCC_CFLAGS) > > +AC_ARG_ENABLE([scanner], > + [AC_HELP_STRING([--disable-scanner], > + [Disable compilation of wayland-scannner])], > + [], > + [enable_scanner=yes]) > + > +AM_CONDITIONAL(ENABLE_SCANNER, test "x$enable_scanner" = xyes) > + > EXPAT_LIB="" > AC_ARG_WITH(expat, [ --with-expat= Use expat from here], > [ expat=$withval > diff --git a/wayland/Makefile.am b/wayland/Makefile.am > index ed31dfc..fd79eb3 100644 > --- a/wayland/Makefile.am > +++ b/wayland/Makefile.am > @@ -35,9 +35,16 @@ AM_CPPFLAGS = $(FFI_CFLAGS) > AM_CFLAGS = $(GCC_CFLAGS) > > protocoldir = $(top_srcdir)/protocol > + > +if ENABLE_SCANNER > wayland_scanner = $(top_builddir)/wayland/wayland-scanner > +else > +wayland_scanner = wayland-scanner > +endif > + > include $(top_srcdir)/wayland/scanner.mk > > +if ENABLE_SCANNER > bin_PROGRAMS = wayland-scanner > > wayland_scanner_SOURCES = \ > @@ -46,6 +53,7 @@ wayland_scanner_SOURCES = \ > wayland_scanner_LDADD = $(EXPAT_LIBS) libwayland-util.la > > $(BUILT_SOURCES) : wayland-scanner > +endif > > BUILT_SOURCES = \ > wayland-server-protocol.h \ > -- > 1.7.4.1 > ___ > 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 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
