Subject: CVS domivogt: * FvwmProxy changes: - Backed out XFillRectangle patch that disabled color sets.

From: FVWM CVS <[email-masked]>
Date: Mon, 18 Nov 2002 04:41:15 -0600

CVSROOT:	/home/cvs/fvwm
Module name:	fvwm
Changes by:	domivogt	02/11/18 04:41:15

Modified files:
	.              : ChangeLog 
	fvwm           : move_resize.c 
	modules        : ChangeLog 
	modules/FvwmProxy: ConfigFvwmProxyDefaults FvwmProxy.c 

Log message:
* FvwmProxy changes: - Backed out XFillRectangle patch that disabled color sets.
- Changed some defaults (not META_L binding by default; no default font; use
mouse selection).
- Cleaned up option parsing (use ParseToggleArgument() to scan for boolead
options instead of strcmp).
- Put window title in center of proxy when no mini icon was defined for a
specific window.
* Do not send M_CONFIGURE_NOTIFY when the window did not move in __move_loop().

--
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: [email-masked]
Date: Mon, 18 Nov 2002 12:34:03 -0800

> * FvwmProxy changes: - Backed out XFillRectangle patch that disabled color sets.

Does it show you the background color of the select colorset when
the proxy is selected?  If so, help me figure out what I've got set up
wrong.

> - Changed some defaults (not META_L binding by default; no default font; use

Does everyone actually want the proxies to be auto-selected by moving the mouse
over them and not even clicking them?  I found it really annoying, but I'd be
willing to put it up for a vote.

> - Cleaned up option parsing (use ParseToggleArgument() to scan for boolean

Ok.

> - Put window title in center of proxy when no mini icon was defined for a

I suppose.  Less uniform, though.

> * Do not send M_CONFIGURE_NOTIFY when the window did not move in __move_loop().

Oops.

-- 
  _
 ( \      _  \    /_ /  _ _  Jason Weber                  (503) 380-7424
  \|(\/)()))  \/\/(-/_)(-/(  Infinite Monkeys Inc.        Aloha, Oregon
  //                         http://www.imonk.com/baboon  [email-masked]
 (/     [email-masked]        [email-masked]

     "Canister contains at least 50% recycled material; 15%
      post-consumer content."
   -- Pringles Fat-Free (side of can)
--
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: Tue, 19 Nov 2002 10:44:38 +0100

> the proxy is selected?  If so, help me figure out what I've got set up

Yes, it does.  Without your config I can't say what goes wrong.

> willing to put it up for a vote.

I just thought it was a better default.  Of course you can still
disable it in your personal config.

[snip]

> > * Do not send M_CONFIGURE_NOTIFY when the window did not move in __move_loop().

That had nothing to do with FvwmProxy.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 19 Nov 2002 11:04:26 +0000

On 18 Nov 2002 12:34:03 -0800, [email-masked] wrote:
> 
> > - Changed some defaults (not META_L binding by default; no default
> > font; use mouse selection).
> 

If you speak about ConfigFvwmProxyDefaults, it is only an example
configuration, it may include anything to help a user to understand the
usage, but it is not going to be included (read forced) for everyone,
just like we don't include any configuration for our 30 other modules.

I suppose Dominik only temporarily forced this file for everyone.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Nov 2002 12:35:32 +0100

> I suppose Dominik only temporarily forced this file for everyone.

Actually, no.  In the case of FvwmProxy, I wanted to provide a
neat interface for module/fvwm communication.  We can hardly
expect that a normal user can write this on her own or copy it
from the man page.  Think of it as part of the deafult interface.

  ----------------------- snip ---------------------
  AddToFunc FvwmProxyShowFunc
  + I UnsetEnv FvwmProxy_S
  
  ...
  
  AddToFunc FvwmProxy_Mark
  + I SendToModule FvwmProxy mark $w
  
  AddToFunc FvwmProxy_Circulate
  + I WindowId $[FvwmProxy_S] $0 $1 FvwmProxy_Mark
  + I CondCase (Error) $0 $1 FvwmProxy_Mark
  ----------------------- snip ---------------------

But that does not mean I want this for every module.

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 19 Nov 2002 12:12:59 +0000

> But that does not mean I want this for every module.

As much as one likes some module (FvwmAnimate, FvwmBanner, FvwmTheme,
FvwmBacker, FvwmProxy) fvwm should be able to start naked without
requiring/configuring anything like this. The more configuration we force
for everyone the more an experienced user should undo for his own setup.

It is also unexpecting that the man page says something about the defaults
and a user gets something different. If FvwmProxy can't work without
defining some functions, it should ask fvwm to create them, but if these
functions are optional and configurable, one example implementation should
not be forced for everyone. I think the good solution is to mention in
the man page that to get one predefined FvwmProxy configuration a user
may include 2 lines to his config (but do not force these lines for him):

  Read ConfigFvwmProxyDefaults
  AddToFunc StartFunction I FvwmProxy

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 19 Nov 2002 13:46:49 +0100

On Tue, Nov 19, 2002 at 12:12:59PM +0000, Mikhael Goikhman wrote:
> and a user gets something different.

That's exactly what we have in the fvwm core already.  Some
documented defaults just come from ConfigFvwmDefaults and do not
work when executed without it.  The idea is to hard code only the
settings that are absolutely necessary and rely on a proper
installation to get the rest.

> If FvwmProxy can't work without
> defining some functions, it should ask fvwm to create them,

That does not work.  A module can not guess what fvwm has already
defined.

> but if these
> not be forced for everyone.

It is only the default.  With the same reasoning, FvwmAuto should
not provide a default behaviour (raise on focus), and neither
FvwmAudio, FvwmWinList, FvwmTaskBar, FvwmIconMan, FvwmIconBox and
probably other modules that I am missing.  I postulate that every
module should come with a default configuration that allows using
the module.  In case of FvwmProxy you will still have to set up
some key or mouse bindings, but that should be all.

> I think the good solution is to mention in

To be usable for anybody but experts, FvwmProxy *needs* that
configuration.  I would have hard coded it into FvwmProxy, but it
needs interaction with fvwm.  Of course not everybody needs these
functions, but on the other hand not everybody needs
WindowListFunc or UrgencyFunc either.  Unfortunately these configs
have to be executed at startup in order to not overwrite user
modified functions.

Bye

Dominik ^_^  ^_^

---

From: [email-masked]
Date: Tue, 19 Nov 2002 12:05:40 -0800

> Yes, it does.  Without your config I can't say what goes wrong.

Umm, the whole thing is quite the lot.  I'm digging through it now.
Maybe it has something to do with some Style * ops.

> disable it in your personal config.

I wanted the defaults to be optimum setup.  That's why I tried to put
press/release Alt into the defaults, sort of like how WinList Alt-Tab
is in ConfigFvwmDefaults.  It shouldn't hurt when you don't use
FvwmProxy and it does something other than absolutely nothing when
FvwmProxy is run without any user config.

When I press Alt, my mouse is all over the place: move window, resize window, etc.
I don't want whatever window proxy I happened to swing over last to pop forward
after I finish resizing some other window.  If the whole point of swinging my mouse
over the proxy was to raise the window, I can press left mouse when I get there.

Now, maybe we should have config functions for selection by various mouse buttons like
we have for a Hide after a Next/Prev.  Right now it's hard coded to raise/lower.
I guess that would be like:
*FvwmProxy: Action  Click1  Raise
*FvwmProxy: Action  Click3  Lower

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 19 Nov 2002 22:45:24 +0000

> is in ConfigFvwmDefaults.  It shouldn't hurt when you don't use

But it does hurt everyone. Try a mere:

  Key -Alt_L A A Nop

and see how Alt stops to work in xterm.
Actually I managed to make no keyboard work at all after this command and
some manipulations, only Restart using a mouse helped.

> *FvwmProxy: Action  Click3  Lower

I don't worry about the exact FvwmProxy defaults as long as they are
private to a module.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Tue, 19 Nov 2002 23:48:16 +0000

On 19 Nov 2002 13:46:49 +0100, Dominik Vogt wrote:
> > > > configuration, it may include anything to help a user to
> > > > understand the usage, but it is not going to be included (read
> > > > forced) for everyone, just like we don't include any configuration
> > > > for our 30 other modules.
> > > > 

First of all ConfigFvwmProxyDefaults is incorrect, it should include
DestroyFunc and DestroyModuleConfig to be ready to be included twice.

Second, I don't think the way you took is the best one. There are more
clean ways without requiring anything to be defined for every user.
And more intuitive for a user to define.

If we take FvwmEvent as an example you require now to include a file
that defines 40 functions (as the number of events) that look like:

  # this is the default for FvwmEvent callbacks, but a user may change it
  AddToFunc FvwmEvent_new_page
  + I echo new_page

  AddToFunc FvwmEvent_add_window
  + I echo add_window $w

Compare this to the way FvwmEvent works now, which is better?
I really hope you understand my point, because I don't want to expand it.
What is the reason to have AbortCommand if you don't expect a user to use
it to change the defaults? Here is how I would solve it.

The module keeps the default commands internally, if he needs a function
(this is not really needed, but anyway) such function with a name like
_FvwmProxyDefaultAbortFunc may be created on FvwmProxy startup, the names
of these functions don't need to be documented, because a user should not
use them (they will be overridden). Instead a user should define his own
function or maybe just include the full command inline:

  *FvwmProxy: HideCommand UnsetEnv FvwmProxy_S
  *FvwmProxy: MarkCommand WindowListFunc $w
  *FvwmProxy: AbortCommand MyAbortFunc

The default callbacks should be hardcoded in FvwmProxy.c.

Another possible solution/addition would be to have something like
*FvwmProxy: UseDominiksDefaults  that sets alternative defaults.

Regards,
Mikhael.

---

From: [email-masked]
Date: Tue, 19 Nov 2002 16:34:37 -0800

> some manipulations, only Restart using a mouse helped.

Ah, ok.  I guess I don't use Alt constructs except for the WM.
Let's see ... ok, I guess I've locked out the Alt key.

For the other issue, if there is a Config default, which it's sounding like
there shouldn't, I feel the default EnterSelect should be false.

> I don't worry about the exact FvwmProxy defaults as long as they are

Part of the question was, for people interested in what the defaults are,
what should they be?  But everyone should be interested in making/following
precedence on how things are configured, ie. is the Action syntax a good
or bad thing?  It looks good to me.

I've just implemented the FvwmProxy Action command for Click(1|2|3),
pending checkin.

I vote that we don't run ConfigFvwmProxyDefaults by default and
let any defaulting live in the .c file itself.  I'm not quite sure
how to turn it off.

So then, what is ConfigFvwmProxyDefaults for, a sample that's redundant with
the man page?  Should I get rid of the things that have .c defaults?

I'm not really sure what FvwmProxy_Circulate does.  I don't think I'm using it.
All the other config Funcs seem to support it except SelectFunc, which I guess
I am using.

For consistancy, couldn't we just use the Action syntax, something like:

AddToFunc MySelectFunc
+ I WindowId $w Iconify off
+ I WindowId $w FlipFocus
+ I WindowId $w Raise
+ I WindowId $w WarpToWindow 50 50

*FvwmProxy: Action  Select  MySelectFunc

I'm not sure about "Iconify off", since FvwmProxy current ignores all
iconified windows anyhow.

Also, I figured out the background problem.  The background was only properly
reconfigured with the use of MarkProxy().  Since I wasn't using the Mark
script functions, I guess I never marked.  So, I switched Next/Prev to
reuse the same functionality as the Mark.

One little question about Next/Prev, spcecifically to where it continues
relative to where it left off on a previous Show.  I had it so that it
starts back on the last selected proxy and then moves on from there.
But looking at an MS box, I see the first Alt-Tab moves on to the next window
immediately.  Is this the preferred functionality (convention vs. my intuition)?

  _

---

From: Dan Espen <[email-masked]>
Date: Tue, 19 Nov 2002 22:15:32 -0500

> the man page?  Should I get rid of the things that have .c defaults?

The original purpose of  the ConfigFvwm files  for modules was for use
by the Setup Form.  (Accessed thru "Menu MenuFvwmRoot".)

The form puts a copy of the file(s) into the users $HOME/.fvwm directory
for customizing and creates a .fvwm2rc that contains Read commands
for the config files.

-- 
Dan Espen                           E-mail: [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 20 Nov 2002 11:36:46 +0100

[snip]

As there was too much discussion to answer everything explicitly,
let me explain the logic behind the current FvwmProxy setup.

1) ConfigFvwmProxyDefaults contains essential configuratios that
   are meant to make the module usable for a beginner.  It is
   *never* included twice and thus the functions do not have to be
   destroyed.  Exactly like everything in ConfigFvwmDefaults.

2) In the design I have in mind, FvwmProxy does *nothing* by
   itself.  Every action is configurable via complex functions.
   There are no hard coded function defaults like "Click button 1
   = Raise".  Instead, there is a set of functions that are called
   at various times:

   Called by FvwmProxy:
   
     FvwmProxyShowFunc:
       executed when the windows are initially shown

     FvwmProxyHideFunc:
       executed when the windows are removed (implies execution of
       FvwmProxySelectFunc)

     FvwmProxyAbortFunc:
       executed when the the windows are removed

     FvwmProxyMarkFunc:
       executed when a window is hilighted

     FvwmProxySelectFunc:
       executed when a window is selected; same default as
       WindowListFunc

   These functions are *meant* to be modified by an intermediate
   user.  They are *not* hidden internal FvwmProxy settings but
   the correct place to configure module actions.  Why?  FvwmProxy
   needs to store the notion of a selected window in fvwm memory.
   This is necessary to make use of the conditional window
   selection commands.

   When we add different actions for the various mouse buttons,
   they should use FvwmProxyMarkFunc.  If that is not enough, add
   more "Mark" functions, a la FvwmProxyMark2Func, ...Mark3Func
   etc.  The idea is to keep all action definitions in the same
   place.

   The normal user is *not* supposed to use the
   "*FvwmProxy: ...Command" to configure FvwmProxy.  She should
   add lines to the complex functions instead.

   Called by the user (convenience functions to ease writing
   the config):

     FvwmProxy_Mark:
       mark a window, triggered by fvwm, e.g. by
         key f1 a s FvwmProxy_Mark $FvwmProxy_S

     FvwmProxy_Circulate:
       Use any of the usual window selection commands to mark the
       next window.  For example:
         key f2 a s FvwmProxy_Circulate Next (currentpage)
       The idea is that fvwm does the window selection and just
       tells FvwmProxy what to do next.  This obsoletes the "Next"
       and "Prev" logic built into FvwmProxy.

   These are convenience functions only.  It makes little sense to
   modify them.

3) Overriding any settings at module startup is evil.  It will
   *really* annoy users.  Never do this.  The only time settings
   may be forced is before the config file is read.  I agree that
   it's not such a hot idea to force configs that are used by
   perhaps 10% of the users.  It's just that I can't think of a
   method to trigger reading the defaults when either the module
   is started for the first time, any FvwmProxy config line is
   encountered or any of the default config is modiufied.

4) Comparing FvwmProxy with FvwmEvent.  That comparison is not
   valid.  After all, FvwmEvent is a module that is meant for
   various magic and scripting tasks.  Only experts should try
   using it without assistance.  FvwmProxy is quite the opposite.
   It is a high-level, user friendly GUI module that is supposed
   to come with usable and sensible defaults.  Even a beginner
   should be able to make good use of it.  Hence it requires a
   nice default configuration.  Just writing it in the man page
   and telling the user to cut and paste is not good enough.

5) About the individual defaults:  The defaults should be chosen
   in a way that allows a user to do something useful with
   FvwmProxy with the bare minimum of adding two configuration
   lines:

     AddToFunc StartFunction I Module FvwmProxy
     Mouse 1 R M SendToModule FvwmProxy Show

   Then:

     (M-Click1):   Show proxies
     (Move mouse): Select a proxy with visual feedback
     (Click1):     Raise the window and hide the proxies
   
   And perhaps:

     (Click2):     Lower the window
     (Click3):     Something

   (I know there is still way to go before this works).  Of course
   we can discuss about the proper defaults, but the module should
   be usable with a minimal configuration.

6) Hard coding the defaults.  I think they should not be hard
   coded in the FvwmProxy executable because some require complex
   functions and some do not.  This makes configuring it a pain.
   For example, if you have this default:

     *FvwmProxy: MarkCommand <something>

   And the user wants to add "Focus", she has to issue:

     AddToFunc MyFvwmProxyRaiseFocus
     + I <something>
     + I Focus

     *FvwmProxyMarkCommand: Function MyFvwmProxyRaiseFocus

   Note that the user has to look up the current default in the
   man page first and add them manually to the new function.  With
   the current code she can just say:

     AddToFunc FvwmProxyMarkFunc
     + I Focus

   It is shorter and easier to use.  You do not have to look up
   any defaults in the man page.

7) My recommendations on the implementation of some new/current
   features:

     Next/Prev command:

       Remove them.  With the FvwmProxy_Circulate function they
       are no longer necessary.  Fvwm does a much better job of
       selecting windows as it is mobre versatile and has more
       available information.

     Click button <n> actions:

       Implement them just like the "Mark" command.  Add resources
       *FvwmProxy: Click<n>Command and default to 

         *FvwmProxy: Click1Command Function FvwmProxyClick1Func
         AddToFunc FvwmProxyClick1Func
         + I Raise

         *FvwmProxy: Click2Command Function FvwmProxyClick2Func
         AddToFunc FvwmProxyClick2Func
         + I Lower

         ...

   Overall, ad as little functionality to FvwmProxy as possible.
   Fvwm has most of the code anyway, so program the actual
   behaviour into complex functions.  This reduces maintenance of
   the module dramatically.

8) The initial idea behind ConfigFvwmDefaults was *not* to include
   them from the setup script.  The idea was to take the
   non-critical default settings from the fvwm source code and put
   them in a file that can be modified by the sysadmin.  I don't
   know what the other ConfigFvwm... files are good for, though.

--

To summarize the crucial point of the discussion:

What Mikhael does not like (correct me if I am wrong) is that
configuration lines (the contents of ConfigFvwmProxyDefaults) that
use up cpu and memory are forced upon every user.  I do not like
that either.  Present a reliable method to only include these
defaults only when FvwmProxy is actually used and I will use it.
Otherwise we have to weigh resource consumption against ease of
use.  I tend to prefer usability here, but I am not decided yet.

Bye

Dominik ^_^  ^_^