Discussion:
FVWM: Title toggling behavior in 2.6.5
Glenn Golden
2016-03-21 17:04:24 UTC
Permalink
When WindowStyle is toggled from Title to !Title, the upper edge of the
window remains where it is and the bottom edge shifts up to make up for
the space lost by removing the title bar. Is there any style option (or
other trick) that would allow this convention to be reversed, i.e. so that
the window remains bottom-anchored rather than top-anchored when the Title
is toggled?

------- version info ---------
$ fvwm --version
fvwm 2.6.5 compiled on May 15 2014 at 22:21:15
with support for: ReadLine, Stroke, XPM, PNG, SVG, Shape, XShm,
SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS
------------------------------
Glenn Golden
2016-03-21 23:11:16 UTC
Permalink
Post by Glenn Golden
When WindowStyle is toggled from Title to !Title, the upper edge of the
window remains where it is and the bottom edge shifts up to make up for
the space lost by removing the title bar. Is there any style option (or
other trick) that would allow this convention to be reversed, i.e. so that
the window remains bottom-anchored rather than top-anchored when the Title
is toggled?
No, I'm afraid not. It's up to you to write a complex function which should
determine if the window needs repositioning after you've toggled the title.
OK, seems to work. It's fast enough not to be visually disturbing too,
so it's a nice clean solution, thanks.
Glenn Golden
2016-05-22 12:01:31 UTC
Permalink
What follows is a long-winded question about a puzzling (to me) interaction
between fvwm, xterm, and libxcursor pointer-theming.

Not suggesting this is a bug or even a problem at all, just seeking an
education as to what's going on.

Version info:

fvwm --version:
fvwm 2.6.5 compiled on May 15 2014 at 22:21:15 with support for:
ReadLine, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text,
Xinerama, XRender, XCursor, XFT, NLS.
(Config file is pretty straightforward, will post if needed.)


xterm -v:
XTerm(324)

Distro:
Arch, synched to repos a few days ago.


So... "Reference case": Under raw X (no WM), start up an xterm like this:

$ xterm -ms COLOR

where COLOR is some color specifier. Behavior as expected: Mouse pointer
shape is the usual X "I beam", with color COLOR. (And the same expected
behavior is obtained via the associated X resource "pointerColor", as
set via "-xr" option, xrdb, etc.)

In particular, the pointer shape and workingness of "-ms" are not affected
by any of the libxcursor theming parameters in the system-wide
default/index.theme file, or the per-user default/index.theme file, or by
the $XCURSOR_THEME envar. This is also as expected (by me, anyway) since
xterm 324 doesn't use libxcursor (at least, afaict according to ldd).


But: Under fvwm (no DE), xterm pointer behavior seems to depend on how the
xterm is started:

* An xterm started via an fvwm menu item, e.g.

"xterm (blue pointer)" Exec exec xterm -ms blue

behaves as it does under raw X. And this is again true regardless of
theming parameters in index.theme files or the (exported) value of
$XCURSOR_THEME in fvwm's environment.

* But: An xterm manually started from the commandline within another
xterm (which in turn was launched via an fvwm menu item, like above)
_is_ evidently affected by the libxcursor theming stuff: For example,
if $XCURSOR_THEME is set to a theme name other than "core", or if one
of the default index.theme files "Inherit"s a theme other than "core",
then the manually-started xterm will have the themed pointer shape
(and the -ms COLOR will be ignored).

I understand that xterm can't color a non-core pointer, so it's not that
I'm expecting -ms to work in the manually-launched case where (for whatever
reason) xterm is paying attention to the theme stuff. The question is: Why
does xterm pay attention to the theme stuff in the manually-launched case but
ignores it when Exec'ed from a fvwm menu? Afaict, the environments and X
resources in both cases seem to be essentially identical.

History (if it matters):

This behavior difference began about a year ago when Arch changed their
libxcursor packaging to include a system-wide default/index.theme file
which inherits a giant tortoise:

[Icon Theme]
Inherits=Adwaita

(Adwaita is also the name of a GNOME pointer theme, but it's more fun to
think of it as a giant tortoise.)

Anyway, prior to that change, xterm pointer behavior was identical in both
fvwm cases (i.e., non-themed, and color per "-ms") evidently because there
was no non-core default theming, so the difference never appeared. But with
the tortoise in there, if you want xterm -ms to work with manually-started
xterms you have to explicitly set XCURSOR_THEME=core (or set up your own
user default/index.theme file with "Inherits=core" (or just "Inherits=").

Again, no big deal, just would like to understand why the two cases differ.

I have a feeling the explanation is very simple and staring me in the face
but can't see it.
Tom Horsley
2016-05-22 12:20:17 UTC
Permalink
On Sun, 22 May 2016 06:01:31 -0600
Post by Glenn Golden
Again, no big deal, just would like to understand why the two cases differ.
No proof, but things like this are often due to the order things
are started it. Perhaps environment variables that point to the
dbus are defined in one case and not in the other?

Loading...