Subject: FVWM: New guy

From: Jacco van Schaik <[email-masked]>
Date: Wed, 18 Jun 1997 13:12:31 +0200 (METDST)

Hi all,

I've been using fvwm2 (and fvwm1 before) for some years now and I've
just subscribed to this here mailing list. I thought I'd take the
opportunity to contribute some questions/comments.

Why are the Color and HilightColor commands so different? The syntax is
different ("color1 color2" vs. "color1/color2"), the places where they
can be used (in a Style vs. at the top-level), the one doesn't accept
an "rgb:rr/gg/bb" color spec and the other does, the one can be split
into a BackColor and a ForeColor and the other can't. I end up having
to specify normal and hilighted colors in different places and in
different ways, which looks really awkward.

I want my multiple icon boxes back! Part of my desktop used to look like
this:

+-------+-------+   First IconBox 1 would fill up, and then it would
|       |       |   "spill over" into IconBox 2. With 2.0 that's no
| Icon- |       |   longer possible (other than defining different
| Box 1 | Icon- |   icon boxes for different programs, which I don't
|       | Box 2 |   want). I also don't want to use the IconBox
+-------+       |   module because it takes up desktop space with
|Xfaces |       |   its own window.
+-------+-------+

I would like to be able to define shortcuts for menu entries at
the same time as I define the menu entries themselves, with the
AddToMenu function. Now they are defined in different places,
which doesn't help in keeping them consistent.

Regards,				- Jacco

--
                              | IRL: Jacco van Schaik
Those who can, do.            | @ Work: [email-masked]
Those who can't               | @ Home: [email-masked]
      write user requirements.| See also http://www.nlr.nl/NARSIM.html

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Richard Lister <[email-masked]>
Date: Wed, 18 Jun 1997 10:41:30 -0400

On Wed, 18 Jun 1997 13:12:31 +0200 (METDST)
Jacco van Schaik <[email-masked]> 
> different ways, which looks really awkward.

I think this is historical. The HilightColor command existed long
before Style "*" Color was created. I agree with you that it is
not very intuitive. Now we have the new decors it is possible to
get some strange and counterintuitive interactions between
BorderStyle, Color and HilightColor.

In my opinion this should all be rewritten as part of the
Great Style Flag rewrite. And so I come to a proposal I'd like
to put to Chuck and the others.

I think fvwm-2.0.45 is pretty stable (more stable than a lot of software
I use!). How about freezing the features and releasing it as 2.1,
then having parallel releases: 2.x will just be bug fixes for the
current feature set, while 3.x (or whatever) will have all the
code rewrites people have been planning for so long. People adding
features will be encouraged to add them to the cleaner code
of the 3.x betas.

It strikes me that Chuck spends a lot of time adding and debugging
all the great new features that people keep writing, and we'll
never get to 2.1 and begin the GSFR at this rate.

Just my 2c. Comments?

Ric

Richard J Lister, Georgetown Institute for Cognitive and Computational Sciences
Georgetown University Medical Center, Washington, DC.
Phone: 202-687 2878
Email: [email-masked] 
Web: http://www.giccs.georgetown.edu/
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "David Jones" <[email-masked]>
Date: Wed, 18 Jun 1997 13:53:03 -0400

> features will be encouraged to add them to the cleaner code
I disagree with the statement that fvwm-2.0.45 is pretty stable. I'm still
using fvwm 1.x because of a bug in the FvwmButtons module. I've written to the
list before about this, and got no response, other than from other people with
the same problem. The problem is that I can't get FvwmButtons to appear, quite
a fundamental problem with fvwm I would say. The only advice I've been able to
get is use the FvwmButtons module from 2.0.41. Unfortunately, this didn't work
for me, so I'm still using fvwm 1.x.

-- 
=================================================================

Any views, opinions, facts etc. expressed within this mailing are 
totally mine, and do not necessarily reflect those of my employer.

David Jones
-----------

CFD Methods R & D Group          Phone:    (416) 375 3492
deHavilland Inc., MS N18-06      Fax:      (416) 375 3777
Garratt Blvd, Downsview.
Ontario, CANADA M3K 1Y5          Internet: [email-masked]

=================================================================

---

From: "Charles Hines" <[email-masked]>
Date: Wed, 18 Jun 1997 16:02:27 -0400

>>>>> "Richard" == Richard Lister <[email-masked]> writes:

Richard> On Wed, 18 Jun 1997 13:12:31 +0200 (METDST) Jacco van Schaik
Richard> <[email-masked]> wrote concerning 'FVWM: New guy':
....
>> different ways, which looks really awkward.

Richard> I think this is historical. The HilightColor command existed long
Richard> before Style "*" Color was created. I agree with you that it is
Richard> not very intuitive. Now we have the new decors it is possible to
Richard> get some strange and counterintuitive interactions between
Richard> BorderStyle, Color and HilightColor.

Correct.

Richard> In my opinion this should all be rewritten as part of the
Richard> Great Style Flag rewrite. And so I come to a proposal I'd like
Richard> to put to Chuck and the others.

Yes I agree that a fair amount of the rc syntax needs cleaning up...

Richard> I think fvwm-2.0.45 is pretty stable (more stable than a lot
Richard> of software I use!). How about freezing the features and
Richard> releasing it as 2.1, then having parallel releases: 2.x will
Richard> just be bug fixes for the current feature set, while 3.x (or
Richard> whatever) will have all the code rewrites people have been
Richard> planning for so long. People adding features will be
Richard> encouraged to add them to the cleaner code of the 3.x betas.

Whether the next beta after 2.1 is 2.2 or 3.0 depends on the scope of
the changes - what you are mentioning above perhaps falls about
halfway between what I imagine would be a 2.2 and a 3.0 version (which
path to take I've been oscillating on).  I'll explain more below
(briefly).

Richard> It strikes me that Chuck spends a lot of time adding and debugging
Richard> all the great new features that people keep writing, and we'll
Richard> never get to 2.1 and begin the GSFR at this rate.

More or less correct...  I've been trying to limit features to help
get 2.1 out easier, but incorporating patches is always a pain because
my development level usually changes shortly after I release a beta
version and patches often overlap files & throw off lines (sometimes
overlap lines too).  Plus as some people have noticed, I like to
reimplement things sometimes...

Richard> Just my 2c. Comments?

My thoughts - I would like to get at least one more beta out before
2.1.  Then what to do for the next beta after that?

(This is all breifly written, because I have to get back to work and
typing this note between working on things is becoming distracting)

I've toyed with the idea of the next one being a big rewrite, beyond
just what I had in mind for the GSFR (this would be 3.x).  Clean more
stuff up, change rc syntax again (built in language, but add ways to
change to other scripting languages for the folks who would like
that), change module stuff (dynamic loading instead of or in addition
to a cleaned up socket communications protocol), etc.  Essentially
redesign it.  Scary thought, no?

What I had in mind initially for 2.2.x was the GSFR and various
associated cleanups, maintaining essentially the same rc syntax but
clean up parts of it (mostly for consistency between commands), add
some new features & bugfixes that are currently needed (eventually
including some of those that would be for 3.x).  Then 2.3 official
could be releases, and then probably move on to 3.x...

What does everyone else think?  The latter is probably safer, but I
find the former more appealing...

Most important for me to do in the immediate future is to actually
finish up the next beta... :) Sorry it's taking so long (again).

>>>>> "David" == David Jones <[email-masked]> writes:

David> I disagree with the statement that fvwm-2.0.45 is pretty
David> stable. I'm still using fvwm 1.x because of a bug in the
David> FvwmButtons module. I've written to the list before about this,
David> and got no response, other than from other people with the same
David> problem. The problem is that I can't get FvwmButtons to appear,
David> quite a fundamental problem with fvwm I would say. The only
David> advice I've been able to get is use the FvwmButtons module from
David> 2.0.41. Unfortunately, this didn't work for me, so I'm still
David> using fvwm 1.x.

Hm...  I have to say that I think fvwm itself is relatively stable and
usable (am I biased?), but there will always be bugs and there will
often times be ones that some people see that others don't (and if one
of those others happens to be me, as it often is, then debugging some
problems is difficult).

Various people have had different problems with FvwmButtons,
especially since I accepted Jarl's rewrite - it doesn't handle the
older syntax well sometimes and this is often the problem.

Can you get a *simple* FvwmButtons example to work?  Something like a
single button (no pixmap) that beeps?  Just copy these two into
FvwmTalk and see if it works:

  *SimpleButtons(Title beep Action Beep)
  FvwmButtons SimpleButtons

If it does work ok, then work your way up through more complex
examples.  Perhaps this will help you figure out what's wrong.  Or
perhaps you can post to the list what your rc file was trying to do
and some kind soul who has some time might be able help.

Other alternatives - try FvwmGoodStuff (which is the pre-rewritten
FvwmButtons), FvwmScript, or tkgoodstuff.  The first two are in the
extras dir in the 2.0.45 distribution.

[On a side note, eventually (3.x?) I'd like to combine features of
FvwmButtons, FvwmForm, & FvwmScript to make one super usable module
(FvwmGUI or something like that)...]

Ok, this has all taken way too long to type - gotta go.  Hopefully
everything I've written here is coherent and actually what I meant. :)

Chuck

*******************************************************************************
Charles K. Hines <[email-masked]>
IBM Logic Synthesis Developer [BooleDozer (TM)]
Martial Arts Instructor [Modern Arnis, Presas Style Filipino Martial Arts]

         "Go back to sleep, Chuck.  You're just havin' a nightmare
             -- of course, we ARE still in Hell." (Gary Larson)
*******************************************************************************
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Richard Lister <[email-masked]>
Date: Wed, 18 Jun 1997 17:10:58 -0400

On Wed, 18 Jun 1997 13:53:03 -0400
"David Jones" <[email-masked]> 
> for me, so I'm still using fvwm 1.x.

I've been using fvwm2 for two years now, supporting many users
running a large variety of configurations on lots of platforms:
Linux 1.x and 2.x, Irix 5.3 and 6.x, Solaris 2.3-2.5, even an Acorn
RISCiX box (how many of you have seen one of those? :-). I'm very
happy with the stability of the code.

Why not send your config for FvwmButtons again and I'll try to
reproduce the problem.

Also, FvwmButtons is a module. I don't think the window manager
releases should be held up because any modules are still in
beta. That's one of the advantages of having a module interface.
Would you suggest mwm wasn't a stable window manager? It doesn't
have a buttons module at all!

Ric

---

From: Chris Laas <[email-masked]>
Date: Wed, 18 Jun 1997 22:41:44 -0400 (EDT)

> redesign it.  Scary thought, no?

Well, I was thinking as I read this that you're precisely describing
the GIMP's (version 0.99 beta) PDB (procedural database).  (Except for
the part about dynamic loading, since the PDB uses pipes.)  I don't
claim to know well FVWM's module subsystem, but I know the GIMP's
plug-in system pretty well, and it might just be possible to bolt in
some code from the GIMP to FVWM.  Problem is, the GIMP's GPL'ed, so you
run the risk of infecting your own code. *sigh*

Anyway, the GIMP's home site is
http://www.xcf.berkeley.edu/~gimp/gimp.html , if you're interested. 
That's my $1/50th.

--Chris

-- 
WORDS IN THE HEART CAN NOT BE TAKEN.
	-- Terry Pratchett, "Feet of Clay"
______________________________________________________________________
Chris Laas:  out-of-work programmer  / mailto:[email-masked]
< Unix, C/C++, Java, Perl, Tcl/Tk > / http://www.cybercom.net/~chrisl/

---

From: Stefan Stille <[email-masked]>
Date: Thu, 19 Jun 1997 16:27:27 +0200 (MET DST)

Hi,

I want to ask whether there are any plans to make fvwm compliant to 
X11R6's session management. I think that there is a great
perspective for new functionality when fvwm was extended. New modules
could take advantage of the additional information xmsp provides (unique
identification of windows across sessions, grouping of windows according
to application instances,...). Even the session manager itself could be a
module which might use the module interface to restore geometry of windows
when sessions are restarted. 

We are currently developing a similar module for a research project which
will enable users to manage task-related groups of windows instead of
single windows. Also, we have patched or will patch our local copy of fvwm
to inegrate multi window operations like "move group of windows", "resize 
group of windows" etc. So I'd like to ask the members of this list what
they think about such kinds of modifications and what feature requests for
task-related window manipulations they might have.

Due to our local patches to fvwm (which are for version 2.0.43), I cannot
promise that we are able to provide a module for the baseline
version of fvwm but would appreciate any comments. 

Thanks,

Stefan. 

______________________________________________________________________________

Stefan Stille                           

TU Braunschweig                                 
Inst. fuer Datenverarbeitungsanlagen            Tel:   (0531) 391-3731
Hans-Sommer-Str. 66                             Fax:             -4587
38106 Braunschweig                              email: [email-masked]

"Not from the stars do I my judgement plug, 
and yet methinks I have astronomy!"
 
                                            ---    Will Shakespeare
______________________________________________________________________________

---

From: "Bradley T. Hughes" <[email-masked]>
Date: Thu, 19 Jun 1997 16:46:36 -0500 (CDT)

perhaps you should let us know what the problem with FvwmButtons is 
before condemning it and the whole of fvwm2.

i use fvwm2.0.45 with the included FvwmButtons and it works perfectly...

Brad Hughes / nyztihke  -  1997
		- i've become something so horrid and evil - 
     - i can't stand to walk around in public without feeling my hatred - 
 - makes me want to end the suffering of the "good" people i see around me -

---

From: Dan Espen <[email-masked]>
Date: Fri, 20 Jun 1997 16:19:15 -0400

> find the former more appealing...

What do we think about what?  I think just about any of the fvwm2 beta
releases could have been released without the word "beta" attached.  I
think most people have caught  on and realize that  fvwm2 is not  beta
quality, its fully functional.

I think  releasing  fvwm2  as a   non-beta  release will   gather some
attention and may even get someone to contribute patches for the GSFR.

As far as the changes you describe, I would lean toward maintaining rc
file  compatibility unless   there was a  really  big  payoff for  the
change.  Shared  libraries (dynamic loading) would  be nice,  but most
users wouldn't even notice.

> finish up the next beta... :) Sorry it's taking so long (again).

Hey, until we start paying you, how can we complain?

In fact no one's complaining, everyone here loves fvwm2 even if it is
perpetually beta.

--
Dan Espen                                    Phone: (908) 699-5570
[email-masked]
444 Hoes Lane  Room RRC 1C-214
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" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Brady Montz <[email-masked]>
Date: 20 Jun 1997 16:34:53 -0700

> users wouldn't even notice.

They would sure notice if it allowed the writing of even more cool modules,
like modules that would change the "look and feel" of fvwm, like afterstep and
fvwm95 did, but without having to split the source.

-- 
 Brady Montz
 [email-masked]

---

From: cron <[email-masked]>
Date: Sat, 21 Jun 1997 11:32:44 -0400

Hi Everyone

I've been experimenting with fvwm2 and have really enjoyed it.  I need a
little help with a few points that I can't seem to clear up.

First, I have not benn sucessful in getting FVWM buttons to swallow a
digital clock (month/day/date - red on black background).  Second, I
haven't been able to get buttons to swallow a pager (any
configuration).  These pager function has been included in several
example .fvwm2rc's I have found - unfortunately none of these work on my
machine.

One last problem.  I keep getting messages to the effect that the
colormap is full.  I've tried using the command for colormap focus
following the mouse and the focus - no positive results.  I'm running a
cheap 2 meg trident tgui card at 1024 x 768.  When I try to remove the 8
bit depth entry from XF86Config - X complains that the default depth
entry is missing and refuses to engage.

Any solutions would be greatly appreciated.

---

From: Richard Lister <[email-masked]>
Date: Mon, 23 Jun 1997 10:40:53 -0400

On Sat, 21 Jun 1997 11:32:44 -0400
cron <[email-masked]> 
> digital clock (month/day/date - red on black background).  Second, I

I used to use this, before I switched to asclock (available from
http://rif3.iiic.ethz.ch:1313/spiff/asclock/):

*FvwmButtons(5x1, Frame 0, Swallow "xclock" "Exec xclock -d -update 1
-bg Black -fg LimeGreen -padding 4
-fn '-adobe-helvetica-medium-r-*-*-12-*-*-*-*-*-*-*' &")

Note: I've inserted carriage returns for readability ... remove them before
use. 

> example .fvwm2rc's I have found - unfortunately none of these work on my

How about something like this:

*FvwmButtons(3x2, Frame -2, Back #908090, Swallow "FvwmPager" "FvwmPager 0 0")

> following the mouse and the focus - no positive results.  I'm running a

Something's eating all your colours. Netscape is a frequent offender.
Try 'netscape -install'. It could also be lots of multicoloured icons
being used by fvwm2.

> entry is missing and refuses to engage.

I don't know about the capabilities of your card. You can try replacing
the 8 with 16 (or even 24). You may need to reduce the resolution to
get it to work. Try to find out what resolutions and depths are
supported by your card. 

Ric

---

From: Larry Gensch <[email-masked]>
Date: Mon, 23 Jun 1997 11:48:54 -0400 (EDT)

> -fn '-adobe-helvetica-medium-r-*-*-12-*-*-*-*-*-*-*' &")

The problem with using xclock in this way is that the digital clock
isn't very configurable... you cannot select exactly how the digital
display will be viewed.  I also remember problem with resizing the
window and not having the display center properly.  Yet another
limitation is that the clock has no interaction... it cannot be used
to launch an application or do anything useful.

In the past, I have found that when I want something (like a
programmable "biff") that isn't already a standard utility, the
fastest way to create such a facility is with tcl/tk.

So, I created a useful digital clock using tcl/tk and FvwmCommand. 
Feel free to use this, modify it, and do anything you want with it.

******* start of date.tk *********

    #! /bin/sh
    #
    # *-tcl-* \
	exec wish4.2 $0 $*

    # Configuration:

    # cmd_1     Command to execute when Mouse Button 1 is pressed
    # cmd_3     Command to execute when Mouse Button 3 is pressed
    # format    Format of time display (see 'man n clock')
    # mask      Mask to use for initial display of data
    # bg	Background color of the label
    # font	Font to use to display the time

    set cmd_1	{FvwmCommand {warp-or-run "tkrat" Exec /usr/lar3ry/bin/tkrat}}
    set cmd_3	{FvwmCommand {Menu SystemMenu Nop}}
    set format	"%I:%M %p"
    set mask	"00:00 PM"
    set bg	"#c0c0c0"
    set font	"-*-helvetica-medium-r-normal-*-*-100-*-*-*-*-*-*"

    global insideClick cmd_1 cmd_3 format

    set insideClick 0

    proc getTime {args} {
	global format

	set secs [clock seconds]
	.lab configure -text [clock format $secs -format $format]
	after 10000 getTime
	update
    }

    proc click1 {} {
	global insideClick cmd_1

	if $insideClick return

	set insideClick 1

	eval exec $cmd_1

	set insideClick 0
    }

    proc click3 {} {
	global insideClick cmd_3

	if $insideClick return

	set insideClick 1

	eval exec $cmd_3

	set insideClick 0
    }

    label .lab -font $font -text $mask -bg #c0c0c0
    pack .lab -anchor c -fill both -expand yes
    bind .lab <Button-1> click1
    bind .lab <Button-3> click3
    getTime

******* end of date.tk *********

-- 
(void) lar3ry();                                      [email-masked]

     "Sometimes it happens.  People just explode.  Natural causes."

---

From: [email-masked] (Nikita Imennov)
Date: Tue, 24 Jun 1997 14:53:10 EDT

Hi everybody,
I'm trying to minimize my time, while trying to maximize my I/O (:-)).
I'm so used to Wintel's Alt+Space shortcut to show
Window-Ops I;m trying to implement it in Linux.
I issued a command:

Key Space	A	M	Menu Window-Ops

I also looked into /usr/include/X11/keysymdef.h and I think
(thought) I found a key for that -- `space` I tried -it didn't
work.  I checked to see if the whole combination was
right, I substitutted F1 for space -- it worked.
And now I have a plea to anyone that uses `space` short
cut -- *** what key do you use ??? ***

Please reply.

Nikita

---

From: Dan Espen <[email-masked]>
Date: Tue, 24 Jun 1997 15:46:50 -0400

> Key Space	A	M	Menu Window-Ops

On my Solaris machine, the work "space" had to be in lower case.

---

From: "William J. Stotts" <[email-masked]>
Date: Tue, 24 Jun 1997 20:13:03 -0400 (EDT)

Hi all,
This works on my system 

Key space	W  	M	Popup "Window-Ops2"

It pops the menu anywhere over the window, but the keyboard
shortcuts work OK from there!

>cut -- *** what key do you use ??? ***

********************************************************************************
[email-masked]
All Linux...all the time!                                                       
     
..except of course when I _HAVE_ to use  NT4 WorkStation with a real           
                 
posix shell (GNU) over it that makes it tolerable

********************************************************************************
Friends don't let friends do Micro$loth! (except for NT4 on occasion)
********************************************************************************
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].