From: Thomas L. <ta...@ec...> - 2002-03-26 16:08:21
|
Currently, the 'None' and 'Outline' background types for pinboard icons don't work. This is because we use a shaped window for icons, and these can't be semi-transparent, whereas the AA fonts need to blend with the background. Also, we'll soon have alpha-blended icons. Therefore, we need to have the icons be drawn in the same window as the background image, which means doing one of: - Draw the icons directly onto the root window. - Create a screen-sized window and draw into that. Nautilus uses the second method. It makes the program slightly simpler, but has the drawback that backdrop setting programs, such as Wallpaper and XEarth, no longer work. That means either putting background image stuff in the filer or updating lots of other programs. The first one can fail with window managers using virtual root windows. However, the WM spec allows them to provide a list of virtual windows to draw on, so it might not be a problem. Also, we already draw on the root window when doing the drag highlights... Any thoughts on the best approach? -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Eric G. <ep...@pr...> - 2002-03-26 17:06:33
|
Thomas Leonard <ta...@ec...> writes: > - Draw the icons directly onto the root window. > > - Create a screen-sized window and draw into that. Yuck on both parts. If rox starts using one of these "desktop windows", i'll have to stop using it. I *like* rox's simplicity; i don't want to see it turn into another Nautilus. So this desktop window method buys you more eye candy. So what? I don't want eye candy; i have work to do. If it becomes an option, people who want eye candy can turn it on. But please don't make it the default. Really, it shouldn't even be an option. When the Render extension is completed windows will be able to have true translucency; he got distracted with the font issue for a while, but he has indicated on xpert (and i think the render list too) that once he's fixed font handling in all the apps he uses he will move on. We'll probably have this feature within the next year or two. I'd hate to see this lame hack implemented in yet another program just because people are impatient to get their eye candy. Let them use Enlightenment. -- Eric Gillespie <*> ep...@pr... Conformity is a sin. |
From: Thomas L. <ta...@ec...> - 2002-03-26 17:25:33
|
On Tue, Mar 26, 2002 at 12:06:28PM -0500, Eric Gillespie wrote: > Thomas Leonard <ta...@ec...> writes: > > > - Draw the icons directly onto the root window. > > > > - Create a screen-sized window and draw into that. > > Yuck on both parts. If rox starts using one of these "desktop > windows", i'll have to stop using it. I *like* rox's simplicity; > i don't want to see it turn into another Nautilus. Note that drawing on the root window is actually simpler and faster than what we do now... > So this desktop window method buys you more eye candy. So what? Alpha blending is needed for smooth icons. Currently, icons are shaded assuming that the background is light grey. Thus, if you drag a nice rounded icon from your light grey panel onto your black backdrop you'll get ugly white dots round the edge[1]. It would be a shame to fix this in the rest of the filer and not here... > I don't want eye candy; i have work to do. If it becomes an option, > people who want eye candy can turn it on. But please don't make > it the default. But whichever option we pick, it will be faster than the current system... why default to something slower and uglier? > Really, it shouldn't even be an option. When the Render extension > is completed windows will be able to have true translucency; he > got distracted with the font issue for a while, but he has indicated > on xpert (and i think the render list too) that once he's fixed > font handling in all the apps he uses he will move on. We'll > probably have this feature within the next year or two. I'd hate > to see this lame hack implemented in yet another program just > because people are impatient to get their eye candy. Let them use > Enlightenment. There are three parts to the alpha-blending: - AA fonts (already done) - Other drawing primitives (in progress?) - Semi-transparent windows. The last isn't part of XRender and may never be implemented. This is what would be needed to get the shaped windows system working. Remember, we're not just trying to make the whole icon semi-transparent, we need to be able to set the alpha per-pixel... also, option 3 is incredibly slow and memory hungry, because: 1) You have to redraw every window in the stack when one changes. 2) You have to cache the contents of every window so the application sees it without the transparency... [1] Actually, I rejected some nice alpha-blended icons for this reason and went for slightly worse looking ones that didn't so this, but... -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Eric G. <ep...@pr...> - 2002-03-26 18:40:48
|
Thomas Leonard <ta...@ec...> writes: > Alpha blending is needed for smooth icons. Currently, icons are shaded > assuming that the background is light grey. Thus, if you drag a nice > rounded icon from your light grey panel onto your black backdrop you'll > get ugly white dots round the edge[1]. It would be a shame to fix this in > the rest of the filer and not here... Like i said, so what? I understand this matters to many people. Please be equally understanding that it does not matter to everyone. > But whichever option we pick, it will be faster than the current system... > why default to something slower and uglier? I don't know enough about what you're proposing for drawing directly into the root window to comment. If it will be faster and everything still works (dragging around the icons, not interfering with wm's usage of root window, etc.), i have no objections. > - Semi-transparent windows. > > The last isn't part of XRender and may never be implemented. This is what Are you sure? The Render extension is not complete. Alpha-blending and translucency will be implemented, from what i've heard. I searched the web a bit to make sure i wasn't mis-remembering. Here's what i found: http://www.xfree86.org/pipermail/render/2001-March/000794.html http://xfree86.org/~keithp/talks/KeithPackardAls2000/index.html http://www.eax.com/render/#d4 Definitely check out that last link. It seems that i misunderstood; this translucency stuff is *already* in released versions of XFree86. The unreleased stuff they were referring to was the twm hack. -- Eric Gillespie <*> ep...@pr... Conformity is a sin. |
From: Thomas L. <ta...@ec...> - 2002-03-27 10:04:09
|
On Tue, Mar 26, 2002 at 01:40:41PM -0500, Eric Gillespie wrote: > Thomas Leonard <ta...@ec...> writes: [...] > > - Semi-transparent windows. > > > > The last isn't part of XRender and may never be implemented. This is what > > Are you sure? The Render extension is not complete. Alpha-blending > and translucency will be implemented, from what i've heard. I > searched the web a bit to make sure i wasn't mis-remembering. > Here's what i found: > > http://www.xfree86.org/pipermail/render/2001-March/000794.html > http://xfree86.org/~keithp/talks/KeithPackardAls2000/index.html > http://www.eax.com/render/#d4 > > Definitely check out that last link. It seems that i misunderstood; > this translucency stuff is *already* in released versions of XFree86. > The unreleased stuff they were referring to was the twm hack. From the link: "The X Translucent Window Extension builds on the image composition ideas and mechanisms provided by the X Rendering Extension." A prototype (too slow to be usable) is mentioned. Maybe this has actually been implemented now, though? There's also a hint as to why our current shape system is so slow: "The final problem is that the Shape Extension is implemented by modifying the window clipping regions within the server. These regions are represented as lists of rectangles. Complex bitmap shapes generate clip lists of thousands of rectangles, slowing the server unacceptably." Thinking futher, I don't think drawing to the root window will work, because many window managers don't proxy mouse clicks. We could fix that with some InputOnly windows floating above the icons, but that seems ugly. OTOH, the screen-sized window idea can use ParentRelative for its background and it should then work with XEarth, etc. Also, that puts us in charge of proxying, so it should work with everything... As for not covering icons on maximise, there are better ways to achieve this ;-) -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Eric G. <ep...@pr...> - 2002-03-27 14:47:05
|
Thomas Leonard <ta...@ec...> writes: > > http://www.eax.com/render/#d4 > A prototype (too slow to be usable) is mentioned. Maybe this has actually > been implemented now, though? No, the Translucent Window Extension has not been implemented. But it is not necessary for what you want to do. Check the link i left from my original quote above and compile and run that program. There's a large amount of confusion about this today because people look at the translucent twm screenshot and keithp says that is a hack which has not been released. He's referring to the automatic translucification of popup windows. We can have translucent windows today. > OTOH, the screen-sized window idea can use ParentRelative for its > background and it should then work with XEarth, etc. Also, that puts us in > charge of proxying, so it should work with everything... Are you sure? I worry since the only other two offenders of which i am aware (KDE and Nautilus) don't do this. > As for not covering icons on maximise, there are better ways to achieve > this ;-) Such as? This isn't my only objection (i still think it's a disgusting hack that violates long-standing X tradition for no good reason), but if i could have a way not to cover the icons and still get my other uses of the root window to work (such as xplanet and root-tail), then perhaps i wouldn't be forced into a private fork. -- Eric Gillespie <*> ep...@pr... Conformity is a sin. |
From: Thomas L. <ta...@ec...> - 2002-03-27 16:07:34
|
On Wed, Mar 27, 2002 at 09:46:59AM -0500, Eric Gillespie wrote: > Thomas Leonard <ta...@ec...> writes: > > > > http://www.eax.com/render/#d4 > > > A prototype (too slow to be usable) is mentioned. Maybe this has actually > > been implemented now, though? > > No, the Translucent Window Extension has not been implemented. > But it is not necessary for what you want to do. Check the link > i left from my original quote above and compile and run that program. Well, the program doesn't actually work for me (display doesn't update as you drag it around), but that's probably because 4.1.0 is too old. However, if it did work then it would indeed allow us to use the existing system. Even so, putting everything in one window might still be the cleanest thing to do. > > OTOH, the screen-sized window idea can use ParentRelative for its > > background and it should then work with XEarth, etc. Also, that puts us in > > charge of proxying, so it should work with everything... > > Are you sure? I worry since the only other two offenders of which > i am aware (KDE and Nautilus) don't do this. Well, they both proxy mouse clicks, so at least that should work (even twm's middle-button menu stills appears OK). Parent relative backgrounds are a standard X feature, so I can't see a problem with that... > > As for not covering icons on maximise, there are better ways to achieve > > this ;-) > > Such as? The WM spec allows you to specify a border, different for each edge of the screen, which is reserved and should not be covered. Using the pinboard icons for this sounds very broken and unintended... > This isn't my only objection (i still think it's a disgusting hack that > violates long-standing X tradition for no good reason), Well, it *is* the new standard ;-) > but if i could have a way not to cover the icons and still get my other > uses of the root window to work (such as xplanet and root-tail), then > perhaps i wouldn't be forced into a private fork. xplanet should work. Not so sure about root-tail (although ROX-Session can do something similar, but over all windows instead of behind). The number of programs which draw directly onto the root (rather than just setting the background image) is pretty small... -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Eric G. <ep...@pr...> - 2002-03-27 18:09:49
|
Thomas Leonard <ta...@ec...> writes: > Well, the program doesn't actually work for me (display doesn't update as > you drag it around), but that's probably because 4.1.0 is too old. > However, if it did work then it would indeed allow us to use the existing > system. Strange. It does work for me, and i also have 4.1.0. Are you using Sawfish? Sawfish can be configured not to let a window know it has been moved or resized until the action is complete. This helps with flickering during opaque resize and fake translucent things like eterm with opaque move. Perhaps you have this option enabled? > Even so, putting everything in one window might still be the cleanest > thing to do. I don't think so. > Well, they both proxy mouse clicks, so at least that should work (even > twm's middle-button menu stills appears OK). Parent relative backgrounds > are a standard X feature, so I can't see a problem with that... My question is about the parent relative trick. I am not familiar with it. Does it only solve the problem for programs which set the root window image (as opposed to drawing into the root window)? If so, i don't think this is sufficient. > The WM spec allows you to specify a border, different for each edge of the > screen, which is reserved and should not be covered. Using the pinboard > icons for this sounds very broken and unintended... I'm not sure what you're saying here. It sounds like you're saying you can make rox specify this border (which would help me), but then it sounds like you're saying you think this is an abuse of that hint. If it's the former, what is broken and unintended? If the latter, you still have not provided me a replacement mechanism for keeping the icons visible. > Well, it *is* the new standard ;-) I don't agree with what you're implying here. I like the new wm spec. It gives us a lot of features we didn't have with the ICCCM alone. However, you can't just take this cavalier attitude toward long-standing tradition. The root window has not been removed. Its semantics have not been redefined. I don't see the new spec as carte blanche to cripple the root window. -- Eric Gillespie <*> ep...@pr... Conformity is a sin. |
From: Thomas L. <ta...@ec...> - 2002-03-28 14:44:22
|
On Wed, Mar 27, 2002 at 01:09:37PM -0500, Eric Gillespie wrote: > Thomas Leonard <ta...@ec...> writes: > > > Well, the program doesn't actually work for me (display doesn't update as > > you drag it around), but that's probably because 4.1.0 is too old. > > However, if it did work then it would indeed allow us to use the existing > > system. > > Strange. It does work for me, and i also have 4.1.0. Are you > using Sawfish? Sawfish can be configured not to let a window know > it has been moved or resized until the action is complete. This > helps with flickering during opaque resize and fake translucent > things like eterm with opaque move. Perhaps you have this option > enabled? Nope. If I resize the window, it just keeps getting darker... > > Well, they both proxy mouse clicks, so at least that should work (even > > twm's middle-button menu stills appears OK). Parent relative backgrounds > > are a standard X feature, so I can't see a problem with that... > > My question is about the parent relative trick. I am not familiar > with it. Does it only solve the problem for programs which set > the root window image (as opposed to drawing into the root window)? Correct. And actually, it doesn't work very well, because it doesn't trigger a redraw when the parent's background changes... > > The WM spec allows you to specify a border, different for each edge of the > > screen, which is reserved and should not be covered. Using the pinboard > > icons for this sounds very broken and unintended... > > I'm not sure what you're saying here. It sounds like you're saying > you can make rox specify this border (which would help me), but > then it sounds like you're saying you think this is an abuse of > that hint. I'm saying that using the icons (part of the background) to stop window resizing sounds more like a bug than a feature. Clearly, under normal use, windows should expand over icons. > If it's the former, what is broken and unintended? If > the latter, you still have not provided me a replacement mechanism > for keeping the icons visible. _NET_WM_STRUT, left, right, top, bottom, CARDINAL[4]/32 This property MUST be set by the Client if the window is to reserve space at the edge of the screen. The property contains a 4 cardinals specifying the width of the reserved area at each border of the screen. The order of the borders is left, right, top, bottom. The client MAY change this property anytime, therefore the Window Manager MUST watch out for property notify events. The purpose of struts is to reserve space at the borders of the desktop. This is very useful for a docking area, a taskbar or a panel, for instance. The window manager should know about this reserved space in order to be able to preserve the space. Also maximized windows should not cover that reserved space. Rationale: A simple "do not cover" hint is not enough for dealing with e.g. auto-hide panels. Notes: An auto-hide panel SHOULD set the strut to be its minimum, hidden size. A "corner" panel that does not extend for the full length of a screen border SHOULD only set one strut. Anyway, there seem to be problems with all approaches: - The current system is slow and can't blend the text/icon with the background. - Using the root means we don't get button events from older window managers (ie, clicking on an icon does nothing). Possibly solvable with an InputOnly window. - A desktop-sized window means that existing backdrop changers won't work. Note that we could easily allow pinboard applets, so root-tail would be trivial to get working again. XEarth would still be a pain, though. The one-window option also gets us things like lasso dragging to select multiple icons, pinboard applets and always-working menus. - Using the new alpha system might be even slower, and doesn't work for me or anyone not using XFree86. -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Gregory S. <gs...@fr...> - 2002-03-27 19:36:57
|
On Wed, 27 Mar 2002, Thomas Leonard wrote: > > OTOH, the screen-sized window idea can use ParentRelative for its > background and it should then work with XEarth, etc. Also, that puts us > in charge of proxying, so it should work with everything... And this will break windowmanager root menus, won't it? If you can do it without screwing up WindowMaker's root menu, fine. If not, unacceptable. KDE pulled this crap with their desktop when they switched from using KFM. --g -- Gregory Spath gs...@fr... http://freefall.homeip.net/ irc://freefall.homeip.net/mtb |
From: Jason F. M. <jm...@ca...> - 2002-03-26 19:18:20
|
On Tue, 2002-03-26 at 12:06, Eric Gillespie wrote: > So this desktop window method buys you more eye candy. So what? > I don't want eye candy; i have work to do. If it becomes an option, > people who want eye candy can turn it on. But please don't make > it the default. It wouldn't just be for eye candy; the current X Desktop Group (freedesktop.org) standards recommend this behaviour. This method is simpler to implement, faster, and causes fewer problems with window management than the manage-individual-shaped-windows approach. The only thing it breaks are applications that want to draw directly to the root menu, and according to the wm-spec, they can get a window handle from a root property if they want to draw to the background. Actually, I find the current implementation (lots of small windows) highly annoying, because I have edge-resistance turned on in my window manager, and my maximize button configured to try to fill available space. This means that the placement of icons on my desktop tends to interfere with the placement of windows by the window manager -- very awkward! I'd turn the pinboard off, except that I really do like to have a few icons representing current projects and such available on my desktop for quick reference. Another thing that's sort-of related. One of the things that I really like about ROX is how filesystem-oriented it is (with AppDirs and Choices and such). But why isn't the desktop a directory? It would be a lot simpler and more consistent if the desktop were just a filer window with _NET_WM_WINDOW_TYPE_DESKTOP. Maybe there's some historical reason, or something else I'm not aware of? -- +----------------------------------------------------------------+ | Jason F. McBrayer jm...@ca... | | The scalloped tatters of the King in Yellow must hide Yhtill | | forever. R.W. Chambers _The King in Yellow_ | |
From: Eric G. <ep...@pr...> - 2002-03-26 19:27:17
|
"Jason F. McBrayer" <jm...@ca...> writes: > Actually, I find the current implementation (lots of small windows) > highly annoying, because I have edge-resistance turned on in my > window manager, and my maximize button configured to try to fill > available space. This means that the placement of icons on my desktop > tends to interfere with the placement of windows by the window manager This really proves the adage "To each his own." You just described one of my biggest problems with the desktop window approach: the window manager can't take the icons into account. With the one-window-per-icon approach, new windows never obscure my icons, nor do maximized icons. It doesn't do much good to keep shortcuts on the root window if i can't access them half the time because they're covered up. -- Eric Gillespie <*> ep...@pr... Conformity is a sin. |
From: Gregory S. <gs...@fr...> - 2002-03-26 17:10:17
|
On Tue, 26 Mar 2002, Thomas Leonard wrote: > Currently, the 'None' and 'Outline' background types for pinboard icons > don't work. This is because we use a shaped window for icons, and these > can't be semi-transparent, whereas the AA fonts need to blend with the > background. > > Also, we'll soon have alpha-blended icons. > > Therefore, we need to have the icons be drawn in the same window as the > background image, which means doing one of: > > - Draw the icons directly onto the root window. > > - Create a screen-sized window and draw into that. > > Nautilus uses the second method. It makes the program slightly simpler, > but has the drawback that backdrop setting programs, such as Wallpaper > and XEarth, no longer work. That means either putting background image > stuff in the filer or updating lots of other programs. Do we really care what nautilus does? > > The first one can fail with window managers using virtual root windows. > However, the WM spec allows them to provide a list of virtual windows to > draw on, so it might not be a problem. Also, we already draw on the root > window when doing the drag highlights... > > Any thoughts on the best approach? My vote is for root window. One reason I found ROX in the first place is when KDE switched to one big window. It basically broke my beloved Windowmaker root menu. Not acceptable. Can you still do semi-transparent alpha blended icons on the root window? That would be really nice. -- Gregory Spath gs...@fr... http://freefall.homeip.net/ irc://freefall.homeip.net/mtb |
From: Thomas L. <ta...@ec...> - 2002-03-26 17:14:43
|
On Tue, Mar 26, 2002 at 12:10:18PM -0500, Gregory Spath wrote: > On Tue, 26 Mar 2002, Thomas Leonard wrote: > > > Currently, the 'None' and 'Outline' background types for pinboard icons > > don't work. This is because we use a shaped window for icons, and these > > can't be semi-transparent, whereas the AA fonts need to blend with the > > background. > > > > Also, we'll soon have alpha-blended icons. > > > > Therefore, we need to have the icons be drawn in the same window as the > > background image, which means doing one of: > > > > - Draw the icons directly onto the root window. > > > > - Create a screen-sized window and draw into that. > > > > Nautilus uses the second method. It makes the program slightly simpler, > > but has the drawback that backdrop setting programs, such as Wallpaper > > and XEarth, no longer work. That means either putting background image > > stuff in the filer or updating lots of other programs. > > Do we really care what nautilus does? Yes, insofar as whatever it does will be supported by most window mangers... > > The first one can fail with window managers using virtual root windows. > > However, the WM spec allows them to provide a list of virtual windows to > > draw on, so it might not be a problem. Also, we already draw on the root > > window when doing the drag highlights... > > > > Any thoughts on the best approach? > > My vote is for root window. One reason I found ROX in the first place > is when KDE switched to one big window. It basically broke my beloved > Windowmaker root menu. Not acceptable. > > Can you still do semi-transparent alpha blended icons on the root window? > That would be really nice. Should be able to, since the root is just another window. -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |