Subject: Several things

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Thu, 13 Sep 2001 15:29:20 +0700

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)?

	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);
		b) hilited parts of titlebar buttons stick -- see topmost
		   scanline of buttons ##0,8.

(heh, I just liked previous version more ;).

	The question is -- can this be fixed, or, can somebody please
point me to appropriate place in list archives where this change is
discussed?

	Second, Dominik, can bug #732 have a simple "fix" -- since this
effect isn't so fatal with non-animated shading, maybe add something like 
		if (border_width == 0 && has_no_title) steps = 1
to CMD_WindowShade()?

	Third, I've filed a bug report to RedHat, stating that they still
package an old version, and response was that it is too late for next
release, but they'll update in RawHide (see
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=53030).

	_________________________________________
	  Dmitry Yu. Bolkhovityanov
	  [email-masked]
	  The Budker Institute of Nuclear Physics

--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 13 Sep 2001 13:20:01 +0200

> button is at some distance from the left) and to MacOS/Aqua-alikes (where

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.

> 		   wide-maximized to use exactly full screen width; now

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).

> 		   scanline of buttons ##0,8.

I'm not sure what you mean.  Can you perhaps just provide a
screenshot?

> 		if (border_width == 0 && has_no_title) steps = 1

I'll take a look.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked]

---

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Sat, 15 Sep 2001 20:42:21 +0700

> 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.
 
> width of the window borders (HandleWidth and BorderWidth styles).

	No.  See below and screenshot.

> I'm not sure what you mean.  Can you perhaps just provide a

	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.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 16 Sep 2001 00:48:15 +0200

> 	Can an "offset" feature be treated as a TODO item?  It doesn't

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.

> 	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

>   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.

>   larger (the shapes are thicker); but that indifferent -- both cases are

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.

>   from leftmost button to rightmost one uninterrupted), while in 2.2.4

Fixed.

>   vertical line] runs 1px higher than it should.  This reminds a bug I

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?

> 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 ^_^  ^_^

---

From: "Dmitry Yu. Bolkhovityanov" <[email-masked]>
Date: Sun, 16 Sep 2001 18:48:43 +0700

> See my comment above.  With an empty config file, borders look the
[SNIP] 
> provide all your border/title/button related config lines, please?

	Two screenshots are attached, null224.gif is fvwm-2.2.4 (from
ftp.fvwm.org), null24.gif is fvwm-cvs-2001-Sep-10 (cvs checkout, not ftp
snapshot).  Both were made with "./configure --prefix=<dir>; make; make
install", with no other options specified.  Both were run with
<dir>/bin/fvwm2 -f /dev/null.

	While both of these screenshots are 1px less tall than their
yesterday's AnotherLevel-based analogs (due to lack of buttons?), the
picture is the same -- 2.4 is 2px wider and 1px taller than 2.2.4.
However, I didn't check 2.2.5 yet (in fact, I never used it).  The extra
hilited pixel is also there.

	System information:

viper:~% uname -mrsp
	Linux 2.4.2-2 i686 unknown
viper:~% cat /etc/redhat-release 
	Red Hat Linux release 7.1 (Seawolf)
viper:~% rpm -q glibc
	glibc-2.2.2-10
viper:~% rpm -q XFree86-devel
	XFree86-devel-4.0.3-5

(almost a stock RedHat 7.1).

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 16 Sep 2001 18:14:36 +0200

[SNIP]
> hilited pixel is also there.

I can't verify this at all.  2.2.4 looks perfect here as well as
2.2.5.  Are you really 100% no-doubt-about-it *sure* that you
started the correct executable and not some older one lying around
on your disk?  I can at least vaguela remember a problem similar
to the overshooting hilight pixel.

Anyway, I wouldn't worry too much about bugs in old releases that
are fixed today.  If there ever was a default 6 pixel border, it
was *not* the intended behaviour.

Bye

Dominik ^_^  ^_^

---

From: Tim Phipps <[email-masked]>
Date: Mon, 17 Sep 2001 09:54:43 +0100

> hilited pixel is also there.

2.2.5 looks like "Style * mwmBorder" is the default and 2.4 looks like
"Style * FvwmBorder" is the default. COuld you try both of these
versions with the line

Style * mwmBorder

in the config file?

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 17 Sep 2001 13:29:27 +0200

> "Style * FvwmBorder" is the default. COuld you try both of these

No, FvwmBorder has always been the default and this was never
changed.  Anyway, a 7 pixel border is 7 pixels wide regardless of
the border style.

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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-masked].
To report problems, send mail to [email-masked]