On Sat, Sep 15, 2001 at 08:42:21PM +0700, Dmitry Yu. Bolkhovityanov wrote: > On Thu, 13 Sep 2001, Dominik Vogt wrote: > > > On Thu, Sep 13, 2001 at 03:29:20PM +0700, Dmitry Yu. Bolkhovityanov wrote: > > > Hi! > > > > > > First, a pair of questions regarding window decorations. > > > > > > 1. Is it possible to make titlebar buttons appear not side by side > > > to each other and to borders, but at some offset? So that it would be > > > possible to make a setup similar to OpenWindows (where the "window ops" > > > button is at some distance from the left) and to MacOS/Aqua-alikes (where > > > buttons are disjoint)? > > > > Its not possible with vector buttons but can be done with pixmap > > buttons. The following lines come from the > > system.fvwm2rc-sample-95: > > > > ButtonStyle 1 MiniIcon (-- flat) > > > > ButtonStyle all -- UseTitleStyle Flat > > > > AddButtonStyle 2 Pixmap mini.winXX-close.xpm > > > > AddButtonStyle 4 Pixmap mini.winXX-maximize.xpm > > > > AddButtonStyle 6 Pixmap mini.winXX-minimize.xpm > > > > > > Just give the pixmaps a transparent border in the dimensions you > > like. Unfortunatey you'll have to draw a separate pixmap for each > > button state if you need depressed and toggled looks. > > Yes, that's a known solution, but it has at least three > disadvantages. First, as you stated, one has to draw pixmaps for each > state. Second, such buttons aren't scalable (as vector buttons are), so > they wouldn't follow the title font size. Third, such buttons wouldn't > really be offset -- there will be "invisible" areas, which still can be > clicked on, and this is confusing (a similar bug/feature exists in > WinAmp/XMMS, where skin elements are separated from actual mouse handling > code, and it is IMHO very irritating). > > Can an "offset" feature be treated as a TODO item? It doesn't > seem hard to implement.
I was planning to throw away all that BorderStyle, TitleStyle and ButtonStyle stuff because its almost impossible to maintain. The code is one big mess. Other that this, it doesn't require much to add a 'padding' option. But don't underestimate the complexity of the involved code. > > > 2. Somewhere after 2.2.4, the decoration code was changed so that > > > borders became wider. This had several visible effects, all of which are > > > IMHO negative: > > > > > > a) windows occupy more space (with 2.2.4 on 1152x864 > > > screen xterm with lucidatypewriter-12 font could be > > > tall-maximized to occupy exactly full screen with 64 > > > lines, and xterm with lucidatypewriter-10 could be > > > wide-maximized to use exactly full screen width; now > > > there are unused gaps); > > > > The size of the decorations *didn't* change internally in fvwm. > > If things don't fit nicely anymore then either the font in your > > xterms has changed or fvwm's title font (TitleFont foo) or the > > width of the window borders (HandleWidth and BorderWidth styles). > > No. See below and screenshot. Nope, window borders have always been 7 pixels wide, and they are too in 2.2.x. I don't know where this setting is coming from, but it's definitely not the default. You can verify that by running fvwm without a config file > > > b) hilited parts of titlebar buttons stick -- see topmost > > > scanline of buttons ##0,8. > > > > I'm not sure what you mean. Can you perhaps just provide a > > screenshot? > > A screenshot is attached. The left window is fvwm-2.2.4 (RedHat > 6.2), the right is fvwm-cvs-2001-Sep-10 (compiled and run on RedHat 7.1). > Both xterms were run from the same host and on the same X server, with a > command "xterm -fn lucidasanstypewriter-12 -geom 20x5", fvwm configuration > is the same AnotherLevel-1.0.1-1 from RedHat-6.2. > There are several things to notice: > > - 2.4 makes an additional dark border around the window, hence the window > is 2px wider and 1px taller. See my comment above. With an empty config file, borders look the same in 2.4 and 2.2.5. > - 2.4 title is less tall, but percents in vector buttons are somehow > larger (the shapes are thicker); but that indifferent -- both cases are > OK. The gap between the relief and the title seems to be one pixel larger in 2.4 (2 pixels, was 1 in 2.2.x). This was probably an unintentional change, but to mee the new titles look better. > - 2.4's titlebar buttons stick to each other (the topmost bright line runs > from leftmost button to rightmost one uninterrupted), while in 2.2.4 > buttons are separated. Fixed. > - On the upper [right resize corner]=>[vertical part]=>[hilite right > vertical line] runs 1px higher than it should. This reminds a bug I > reported on spring... I see it on your screenshot, but I don't see it here. Could you provide all your border/title/button related config lines, please? > BTW, about two months ago I ran than-current fvwm on a clockwise-rotated > screen under Xvesa (RandR-enabled KDrive server). Xvesa is very slow in > this mode, and I noticed that some pixels (those on the border between > hilited and darkened parts) of the frame are redrawn several times. Hm. Doesn't sound like something I want to debug now ;-) Maybe another time. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
