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.
> > 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.
> > 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.
- 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.
- 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.
- 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...
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.
_________________________________________
Dmitry Yu. Bolkhovityanov
[EMAIL PROTECTED]
The Budker Institute of Nuclear Physics
fvwm_decors.gif
Description: GIF image
