Re: rounded windows using fvwm
Ranjan Maitra writes: > Hello, > > I was wondering if it is yet possible to get rounded corners on > windows using fvwm. I know that there is an unofficial patch around for > this, but I was looking to hopefully avoid going out of the official > version. > > If it is not possible to get rounded corners on windows using fvwm, are > there any plans for adding this support? If so, soon? Longer? Why not > just adapt the patch? Generally Fvwm only adds frivolous things (like FvwmAnimate), when they don't add bloat to the core of fvwm. I found a file named 09-FluxRoundedCorners.patch It doesn't qualify. > On a somewhat related question: is it possible to have the window > title (the bar at the top of the window, right) not go entirely from > left to right, but only part on the left. So that it looks like kind of > a tab to the window. Would someone know how to do that ? Nope. -- Dan Espen
Re: rounded windows using fvwm
On Sun, 02 Dec 2012 00:14:45 -0500 Dan Espen wrote: > Ranjan Maitra writes: > > > Hello, > > > > I was wondering if it is yet possible to get rounded corners on > > windows using fvwm. I know that there is an unofficial patch around for > > this, but I was looking to hopefully avoid going out of the official > > version. > > > > If it is not possible to get rounded corners on windows using fvwm, are > > there any plans for adding this support? If so, soon? Longer? Why not > > just adapt the patch? > > Generally Fvwm only adds frivolous things (like FvwmAnimate), > when they don't add bloat to the core of fvwm. > > I found a file named > > 09-FluxRoundedCorners.patch > > It doesn't qualify. OK, I am sorry for this naivete, but I don't know what parts in the patch cause the bloat: can they be worked around? (Of course, by that, I mean easily, since after all, anything can possibly be worked around.) > > > On a somewhat related question: is it possible to have the window > > title (the bar at the top of the window, right) not go entirely from > > left to right, but only part on the left. So that it looks like kind of > > a tab to the window. Would someone know how to do that ? > > Nope. So, this is not possible? Many thanks again for the most extensible and stable WM -- this is from a non-sophisticated user of fvwm from the dawn of computer time...:-) Ranjan FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop! Check it out at http://www.inbox.com/earth
Re: rounded windows using fvwm
Ranjan Maitra writes: > On Sun, 02 Dec 2012 00:14:45 -0500 Dan Espen wrote: > >> Ranjan Maitra writes: >> >> > Hello, >> > >> > I was wondering if it is yet possible to get rounded corners on >> > windows using fvwm. I know that there is an unofficial patch around for >> > this, but I was looking to hopefully avoid going out of the official >> > version. >> > >> > If it is not possible to get rounded corners on windows using fvwm, are >> > there any plans for adding this support? If so, soon? Longer? Why not >> > just adapt the patch? >> >> Generally Fvwm only adds frivolous things (like FvwmAnimate), >> when they don't add bloat to the core of fvwm. >> >> I found a file named >> >> 09-FluxRoundedCorners.patch >> >> It doesn't qualify. > > OK, I am sorry for this naivete, but I don't know what parts in the > patch cause the bloat: can they be worked around? (Of course, by > that, I mean easily, since after all, anything can possibly be worked > around.) If that's the complete patch, it's lacking documentation and only works with 2 radiuses, would attempt to curve a 1 pixel border. In short, it looks like a hack. >> > On a somewhat related question: is it possible to have the window >> > title (the bar at the top of the window, right) not go entirely from >> > left to right, but only part on the left. So that it looks like kind of >> > a tab to the window. Would someone know how to do that ? >> >> Nope. > > So, this is not possible? Not that I know of. FvwmTabs does something different. I don't know why I'd want a truncated title leaving an unusable gap. -- Dan Espen
Re: rounded windows using fvwm
Dan Espen writes: > Ranjan Maitra writes: > >> On Sun, 02 Dec 2012 00:14:45 -0500 Dan Espen wrote: >> >>> Ranjan Maitra writes: >>> >>> > Hello, >>> > >>> > I was wondering if it is yet possible to get rounded corners on >>> > windows using fvwm. I know that there is an unofficial patch around for >>> > this, but I was looking to hopefully avoid going out of the official >>> > version. >>> > >>> > If it is not possible to get rounded corners on windows using fvwm, are >>> > there any plans for adding this support? If so, soon? Longer? Why not >>> > just adapt the patch? >>> >>> Generally Fvwm only adds frivolous things (like FvwmAnimate), >>> when they don't add bloat to the core of fvwm. >>> >>> I found a file named >>> >>> 09-FluxRoundedCorners.patch >>> >>> It doesn't qualify. >> >> OK, I am sorry for this naivete, but I don't know what parts in the >> patch cause the bloat: can they be worked around? (Of course, by >> that, I mean easily, since after all, anything can possibly be worked >> around.) > > If that's the complete patch, it's lacking documentation and only works > with 2 radiuses, would attempt to curve a 1 pixel border. In short, it > looks like a hack. Looking again at rounded windows, I notice how they conflict with Fvwm's notion of a border. Fvwm borders come in beveled and flat flavors with variable width. A one or 2 pixel border doesn't lend itself to being rounded. I'm not sure how many pixels are needed before rounding becomes visible, probably around 5. Bevels probably wouldn't work at all. You couldn't just use a shape mask, you'd have to try to make the bevel follow the curve. So far I haven't found a generic method for building the shape mask that would account for the degree of curvature. The patch I looked at, just used 2 different shape masks. I'm not sure how well that approach would work at varying resolutions. Lastly, I found this pretty old Kenton Lee write up: http://www.rahul.net/kenton/perf.html#Shapes Shaped Windows A performance issue related to object shapes is the use of shaped (non-rectangular) windows. Shaped windows are available via the SHAPE X protocol extension. While shaped windows can be useful, they can cause performance problems in many situations. Most importantly, Expose events always return rectangular exposure regions, so if a shaped window is moved or unmapped, the X server must send many Expose events to each exposed window to describe the shaped region. If the client owning the exposed window processes each event, its performance will be significantly affected. In general, you should avoid repeatedly resizing, moving, or unmapping shaped windows owned by your application. Also, if you expect many Expose events caused by shaped windows, you should write your Expose event handlers to compress the events as much as possible. So, I think that pretty much puts the nail in the coffin of shaped windows for me. Rounded windows have visual appeal because the roundness is more visually appealing. But I find fast pretty appealing too. Anyway, comments welcome. -- Dan Espen
Re: rounded windows using fvwm
Hi Dan, Thank you for your detailed comments. While the answer is disappointing, I understand and support the need for speed over trivial aesthetics. But a huge bunch of thanks for looking into this in so much detail! I do wonder however, how something like pekwm handles this. It is pretty fast there (though I have not used it at the same intensity level as fvwm), but of course, does not have the full functionality of fvwm. So, perhaps not a fair comparison. Anyway thinking aloud, nothing more. Thanks again for your time and efforts! Best wishes, Ranjan On Wed, 05 Dec 2012 10:30:20 -0500 Dan Espen wrote: > Dan Espen writes: > > > Ranjan Maitra writes: > > > >> On Sun, 02 Dec 2012 00:14:45 -0500 Dan Espen wrote: > >> > >>> Ranjan Maitra writes: > >>> > >>> > Hello, > >>> > > >>> > I was wondering if it is yet possible to get rounded corners on > >>> > windows using fvwm. I know that there is an unofficial patch around for > >>> > this, but I was looking to hopefully avoid going out of the official > >>> > version. > >>> > > >>> > If it is not possible to get rounded corners on windows using fvwm, are > >>> > there any plans for adding this support? If so, soon? Longer? Why not > >>> > just adapt the patch? > >>> > >>> Generally Fvwm only adds frivolous things (like FvwmAnimate), > >>> when they don't add bloat to the core of fvwm. > >>> > >>> I found a file named > >>> > >>> 09-FluxRoundedCorners.patch > >>> > >>> It doesn't qualify. > >> > >> OK, I am sorry for this naivete, but I don't know what parts in the > >> patch cause the bloat: can they be worked around? (Of course, by > >> that, I mean easily, since after all, anything can possibly be worked > >> around.) > > > > If that's the complete patch, it's lacking documentation and only works > > with 2 radiuses, would attempt to curve a 1 pixel border. In short, it > > looks like a hack. > > Looking again at rounded windows, > I notice how they conflict with Fvwm's notion of a border. > Fvwm borders come in beveled and flat flavors with variable width. > > A one or 2 pixel border doesn't lend itself to being rounded. > I'm not sure how many pixels are needed before rounding becomes visible, > probably around 5. Bevels probably wouldn't work at all. You couldn't > just use a shape mask, you'd have to try to make the bevel follow the > curve. > > So far I haven't found a generic method for building the shape mask that > would account for the degree of curvature. The patch I looked at, just > used 2 different shape masks. I'm not sure how well that approach would > work at varying resolutions. > > Lastly, I found this pretty old Kenton Lee write up: > > http://www.rahul.net/kenton/perf.html#Shapes > > Shaped Windows > A performance issue related to object shapes is the use of shaped > (non-rectangular) windows. Shaped windows are available via the SHAPE > X protocol extension. > > While shaped windows can be useful, they can cause performance > problems in many situations. Most importantly, Expose events always > return rectangular exposure regions, so if a shaped window is moved or > unmapped, the X server must send many Expose events to each exposed > window to describe the shaped region. If the client owning the exposed > window processes each event, its performance will be significantly > affected. In general, you should avoid repeatedly resizing, moving, or > unmapping shaped windows owned by your application. Also, if you > expect many Expose events caused by shaped windows, you should write > your Expose event handlers to compress the events as much as possible. > > So, I think that pretty much puts the nail in the coffin of shaped > windows for me. Rounded windows have visual appeal because the > roundness is more visually appealing. But I find fast pretty appealing > too. > > Anyway, comments welcome. > > -- > Dan Espen > -- Ranjan Maitra FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your desktop! Check it out at http://www.inbox.com/marineaquarium
Re: rounded windows using fvwm
Ranjan Maitra writes: > Hi Dan, > > I do wonder however, how something like pekwm handles this. It is > pretty fast there (though I have not used it at the same intensity level > as fvwm), but of course, does not have the full functionality of fvwm. > So, perhaps not a fair comparison. Anyway thinking aloud, nothing more. Based on this screenshot: https://www.pekwm.org/projects/pekwm They cut off 3 pixels from the top window corner producing a barely visible curve that is not really a curve. The bottom of the window just has 1 pixel removed. That's 6 rectangles per window. Haven't looked at the source code to see if that's the only option. -- Dan Espen
Re: rounded windows using fvwm
On Wed, Dec 05, 2012 at 10:30:20AM -0500, Dan Espen wrote: > Looking again at rounded windows, > I notice how they conflict with Fvwm's notion of a border. > Fvwm borders come in beveled and flat flavors with variable width. Well currently the frame ends up being constructed from four GCs for the border, and four GCs for the handles. As you say, masking out any of the handles doesn't bode well for windows with FvwmBorder set. But I don't think the shadow would matter because by masking out the shaped handles you're going to break it anyway. What worries me more is that in order to shapemask the handles you end up with eight GCs and pixmaps to describe the frame, which to me adds up a lot the more windows you end up opening. -- Thomas Adam
