Subject: fvwm2 man page doesn't give info on "feedback" window

From: [email-masked]
Date: Tue, 15 Dec 1998 12:35:58 -0600 (CST)

Full_Name: Larry Gensch
Version: 2.1.5
CVS_Date: 
OS: Digital Unix T5.0
X_Server: X11R6.3
Submission from: (NULL) (204.123.2.83)

The "feedback" window that appears during an interactive
Move or Resize operation may appear in one of two places:

* Top left hand corner of the screen
* Centered in the middle of the screen

The location of this window is specified, interestingly
enough, using the un-obvious "MenuStyle" command in the
.fvwm2rc file.

There is NO documentation describing this feature in any
of the MenuStyle, Move, or Resize entries in the man page.

I have submitted a set of patches to fvwm-2.1.4 to add a
"FeedbackWindow" keyword that takes "topleft," "center," or
"menu" as options to allow the user to specify the
desired location.  These patches were apparently rejected.

However, the current behavior still remains undocumented in
fvwm2's man page.  I'm submitting this bug report to request
that the current behavior at least be documented pending
some implementation of better handling of this in a future
(post 2.2) release of fvwm2.

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Tue, 15 Dec 1998 20:50:33 +0100

> desired location.  These patches were apparently rejected.

No, they were not. I think we had a general agreement that
we'd do it as a global option instead of a command on its
own and that an option to turn the feedback windows off
completely should be added. And, least but not least, I was
hoping you would write the update ;-) Unfortunately I'm much
to busy with the real bugs to write patches myself at the
moment :( Your help would be greatly welcome.

> (post 2.2) release of fvwm2.

Bye

Dominik
-- 
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: [email-masked]
Date: Wed, 16 Dec 1998 08:54:21 -0500 (EST)

>> desired location.  These patches were apparently rejected.

[Note:  I wrote that not as a complaint, but to explain WHY the
Jitterbug report was being submitted]
 
> moment :( Your help would be greatly welcome.

I didn't think there was any consensus, and at least one reply
mentioned that such an "enhancement" should be part of the GSFR,
although I don't see the usefulness of having feedback windows be
modifiable on a per-window basis.

Turning off the feedback window is simple enough (the Move and Resize
code make sure that the window is created before writing to it and
mapping it), so that could be easily accomodated (all I'd need to do
is test it!).

If you don't mind this going into the 2.1.x/2.2 stream, could we at
least get a consensus as to what is desired?

Here are some possibilities:

1.  Using a global option:

    GlobalOpts	FeedbackWindowTopLeft
    GlobalOpts	FeedbackWindowCentered
    GlobalOpts	FeedbackWindowOff		# No feedback window
    GlobalOpts	FeedbackWindowDefault		# MenuStyle sets it

    Remarks:	This requires four different GlobalOpts commands to be
		programmed.  Further, the man page indicates that
		GlobalOpts is a TEMPORARY workaround, so it would
		eventually have to be rewritten.

2.  Using a global option with a parameter:

    GlobalOpts	FeedbackWindow {topleft,centered,off,default}

    Remarks:	Only requires one GlobalOpts command to be added.
		GlobalOpts is still supposed to be a TEMPORARY
		workaround, though.

3.  Using AddToDecor:

    AddToDecor	xxx
    + FeedbackStyle	{topleft,centered,off,default}

    Remarks:	The feedback window really is a "decor," but since
		decors are specified on a per-window basis, we'd have
		to rewrite the FeedbackWindow code to allow it to be
		repositioned as necessary.  (Yeeccch!)

4.  Create a new built-in function:

    FeedbackWindow	{topleft,centered,off,default}

    Remarks:	It's a "function" but it has a global effect.  There
		is precedent for this (eg, HighlightColor), but I
		think it is desired to move these sort of things into
		something different.

		This is what my original patch did, by the way.

I would like to see what others think on this before I do any more
work on it.  I personally prefer options (2), (4), and (1) above (in
more or less that order).  If people prefer option (3), I'd say that
it should be deferred until the 2.3.x release stream, since it will
require a much larger, an possibly more error-prone, rewrite.

>> (post 2.2) release of fvwm2.

I guess this would be option (5) -- at least document the current
behavior so we don't need to answer "how do I center that window" on
the FVWM list.

Note that my original code came out based on an attempt to answer that
very question:  it worked one way at home, and another way at work,
and I couldn't figure out why it was different until I examined the
code.  Although having the source is useful, not all users will be
comfortable about looking into source to find such answers.  [smile]

-- 
Larry Gensch					      [email-masked]

               "May I have ten thousand marbles, please?"

---

From: Dan Espen <[email-masked]>
Date: Wed, 16 Dec 1998 09:45:41 -0500

> modifiable on a per-window basis.

I  don't see any  point in tying this  behavior to windows, so I don't
see a relationship to  GSFR, except that GSFR  is slated to be part of
2.3.x.

> least get a consensus as to what is desired?

I can't  stop   this from going  into   2.1.x, but I  would   strongly
recommend that it not go in.  I know its a simple change, and unlikely
to cause  a bug ripple  effect, but long  years of experience  tell me
that unlikely things happen all the time.

It would seem to  me that only  actual bug fixes  should go in at this
point.  Don't despair, I  expect we will go  quickly from 2.2 into 2.3
development.

> 		This is what my original patch did, by the way.

I don't see any problem with this last alternative.

> require a much larger, an possibly more error-prone, rewrite.

See above, my opinion is any non-essential change (non-bug fix)
should be held out for the few weeks 2.2 takes to be released.

> behavior so we don't need to answer "how do I center that window" on

This  is  written  like you  missed  by  updating of the   man page to
document the currrent behavior.  Thats why I moved your second problem
report to the "fixed" category.

Come  to   think  of    it, I   neglected   to  document    where  the
foreground/background  colors come from on a  feedback window.  I don't
want to  encourage anyone to  come up with   pixmap backgrounds to the
feedback window, that really would be going too far.

FeedbackWindow Foreground color, Background color,
               Position topleft|centered|off|default

???

> comfortable about looking into source to find such answers.  [smile]

It wasn't that easy to see in the source.

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Wed, 16 Dec 1998 15:49:31 +0100

> modifiable on a per-window basis.

Well, the consensus was reached by nobody complaining about
the last 'draft' ;-) I didn't understand the GSFR par the
same way as you did.

> 		This is what my original patch did, by the way.

I perfer (1). (2) adds unnecessary complexity to a commands that
will be rewritten anyway some day. Since I find the logic around
Decors sick I wouldn't want it as a decor command (3). And (4)
was agreed upon that it's overkill, wasn't it?

But there's one thing I dont like about all four: the names.
I still can't imagine how someone could have the idea so search
for 'feedback' in the manpage. 'Move' or 'Resize' should
definitely be part of the name. Any suggestions?
Perhaps 'MoveResizeGeometry...'?

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Tim Phipps <[email-masked]>
Date: Wed, 16 Dec 1998 15:43:18 +0000

> see a relationship to  GSFR, except that GSFR  is slated to be part of

I think it might be useful to be able to turn it on/off as a style option. I only
notice the resize numbers when I'm resizing xterms and other text-ty type things.
I only look at the move numbers when I'm debugging a wandering window 8-).

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Wed, 16 Dec 1998 15:47:06 +0000

> Perhaps 'MoveResizeGeometry...'?

I like "feedback", it leaves the door open for providing other forms of feedback
that I can't think of at the moment.  Maybe the Move command should mention the
feedback window.

Cheers,
Tim.

---

From: [email-masked]
Date: Wed, 16 Dec 1998 10:49:59 -0500 (EST)

I'm replying to two messages with this...

> that unlikely things happen all the time.

I have no overwhelming desire to get this into 2.1.x, since I have
already determined how this gets set using the current configuration
file syntax.

I'll take up the task of putting this into 2.3.x, but we may want to
start discussing how such things will be specified.

>                Position topleft|centered|off|default

Let's apply Dominik's suggestion (MoveResizeWindow instead of
Feedback) as well:

    MoveResizeWindowStyle	On | Off

	Enable (default) or disable the Move/Resize feedback window.

    MoveResizeWindowStyle	ForegroundColor {color}

	Set the color of the text in the window.

    MoveResizeWindowStyle	BackgroundColor {color}

	Set the color of the background.

    MoveResizeWindowStyle	Font {font-name}

	The font of the text in the window.

    MoveResizeWindowStyle	Geometry centered|{geometry}

	Specify the location of the window.  Use the word "centered"
	to have the window centered on the display.  Otherwise, use a
	standard X Geometry to specify the location and/or size.  Some
	common examples:

	    Geometry +0+0	# top left corner
	    Geometry -0-0	# bottom right corner

	Refer to X(1) for other geometry values.

    The various keywords may be specified on a single line, separated
    by commas:

    MoveResizeWindowStyle	ForegroundColor black, \
    				BackgroundColor grey, \
				Font fixed, \
				Geometry centered

This syntax gives us maximum configurability, and allows the window to
work as a function (enabling and disabling the feedback window at
will).

Some other notes:

* I prefer keyword parameters over positional parameters (quick... 
  what EXACTLY does parameter 4 in MenuStyle do???).  I think that
  fvwm should move to this for most places where it makes sense, but
  keep the old syntax (deprecated, possibly) for compatibility with
  older config files.

* I would like keywords that specify colors to use the word "color" in
  them (eg, ForegroundColor instead of Foreground).  This makes it
  easier to find color references in a .fvwm2rc file.

* I am only making suggestions right now, I am not going to start work
  on this until I have some idea where the fvwm2 development is heading
  in order to save myself the effort of doing something that will either
  not be included or that will need to be redone in the future.  (In
  other words, I want us all singing from the same score...)

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 16 Dec 1998 17:06:59 +0100

> that I can't think of at the moment.  Maybe the Move command should mention the

MoveResizeGeometryFeedbackWindowStyleIsDependsOnMenuStyle then?
Ok I'm pushing it a bit ;-)
Perhaps MoveResizeGeometryFeedback... (those global opts have
long names anyway).

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 16 Dec 1998 17:13:17 +0100

Now we're treading the path I wanted to avoid. Being able to specify
colours, font, geometry and so on leads to code bloat. I did understand
that you started lookig after this because you didn't understand the
behaviour because it was nowhere explained. But it didn't really bother
you, right? And the only other complaint I heard was that the feedback
window couldn't be switched off.

And Tim already suggested to do it as a Style option. I can only
try to pull the emergency brake here. I I have anything to say
about that, we will not do that (unnecessary work = wasted time,
resources in my eyes).

Bye

Dominik
--

---

From: [email-masked]
Date: Wed, 16 Dec 1998 11:47:30 -0500 (EST)

> window couldn't be switched off.

Being able to specify colors, font, geometry and so on also leads to
better configurability.

One of the daunting tasks facing a newcomer to fvwm2 is figuring out how
to get the look and feel that he or she wants.  That's where something
like fvwm.themes.org comes in handy.  Giving fvwm2 maximum
configurability makes more sophisticated themes possible.

One way to minimize code bloat would be to move the code into its own
module, creating, say, FvwmFeedback.  If the module isn't running,
there's no feedback window.  If it's running, it could get its
configuration options (colors, font, geometry) and track interactive
moves and resizes.  This may require some additions to the fvwm2 module
protocol, though.

Right now, the current behavior is for the feedback window to inherit
the MenuStyle.  Right now, fvwm2 puts up only a few "windows" of its
own (not counting windows that modules may put up):

	Feedback window
	Menus
	Icons
	WindowList
	Pager

Of these, the last two can be replaced by modules for maximum
configurability.  Icons can get their font from the IconFont function.
Menus have a whole range of style options.  The feedback window is the
only fvwm2-generated window that the user cannot currently control
directly.

> about that, we will not do that (unnecessary work = wasted time,

I also think that adding it as a Style option is overkill.  Having the
ability to interactively turn it on and off (using FvwmTalk, for
instance) could give Tim the same effect without having the Move and
Resize commands have to check the current window style.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 16 Dec 1998 18:03:34 +0100

> configurability makes more sophisticated themes possible.

I can't imagine anyon has ever thought about the geometry, font,
colour etc. of such a window. In fact in day to day life you
should see it only a few seconds a day. The next step we will have
are colour gradients, fancy animations and a mouse-avoiding
feedback window. Nobody will use it however. That's what I mean
with code bloat. This feature is so subtle that most people will
never realise it's there. I myself became aware of it when this
discussion started. All this doesn't warrant more than half
a day of work and mo more than 500 bytes of code. My opinion.

> Resize commands have to check the current window style.

I didn't mean the Style option when I said overkill but the whole
idea of working on this feedback window (apart from the small
discussed changes).

Bye

Dominik

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 22 Dec 1998 02:50:45 +0100

This topic is resolved. The feedback window can be controlled
with the commands Emulate fvwm/mwm, DefaultFont and DefaultColors.

Bye

Dominik