Subject: GSFR for "external" modules

From: [email-masked]
Date: Wed, 21 Apr 1999 08:31:44 -0400 (EDT)

Can you give some information on what will be necessary to apply the
GSFR for externally-developed modules (a la tkgoodstuff)?

-- 
Larry Gensch					      [email-masked]

I would really appreciate it if the login command had a better sense of humor.

--
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: Bob Woodside <[email-masked]>
Date: Wed, 21 Apr 1999 13:50:25 -0400

> GSFR for externally-developed modules (a la tkgoodstuff)?

	Be happy to...later this afternoon. I've got a few other (non-FVWM)
things to get out of the way first.

	Larry, are you the one who recently took over TkGoodStuff? Or, if not,
do you have a current url handy? I thought a note was posted to this
list recently about the change in ownership, but I just did a couple of
quick searches that turned up nothing.

	I also need to update the html pages in docs.

- Bob

---

From: [email-masked]
Date: Wed, 21 Apr 1999 15:51:04 -0400 (EDT)

> 	I also need to update the html pages in docs.

1.  Yes.  I have taken over tkgoodstuff, and will be releasing a
    version 8.1 "real soon now" (I was waiting for Fvwm 2.2 to be
    released, and now I have a lot of deadlines coming in at work).

2.  I haven't released 8.1 yet, but I could possibly put together a
    "pre-8.1" release in a day or so.  I'll attach the current change
    log to the bottom of this message.

3.  I am looking for a "home URL" for the new tkgoodstuff.  I believe
    that Mark Crimmins had offered to use his site (which has the 8.0
    "final" version of the program), but I won't have direct control of
    that site.

I'm interested in the GSFR stuff mostly so that I can continue using
the program once I load fvwm 2.3.(GSFR)+ onto my system...!

I would really appreciate it if the login command had a better sense of humor.
8.1: *** New development started by lar3ry gensch
         <[email-masked]>

    - Maintenance
      All maintainable files are under RCS control now.  I also
      converted makefiles to use automake for more GNU compatibility
      (it's still a "foreign" distribution, though).  I'm currently
      considering the use of CVS.

    - Startup
      Added new "Splash Screen" that displays at program startup.

    - WindowList/Fvwm
      Added mini-icon support.  Now enabled via a checkbutton.  If set,
      WindowList ignores its internal array of icon/Window
      associations and uses the mini-icon files specified by fvwm.

    - New Client:  Switcher
      This emulates the Win95/98/NT4 "ALT-TAB" task list.  Only works
      as an fvwm module.  As with WindowList, mini-icon display is
      optional (although I cannot see any reason WHY it would be
      disabled).

    - Added http "preferences" for clients that want to use the
      tcl "http" package (Outside, Markets) -- mostly for supporting
      web proxies for people within firewalls.

    - New directory:  extras/
      These are "extra" programs that are either undocumented, have a
      limited audience or utility, or are untested.  These can be
      installed by using the --with-extras option to the configure
      program.  Even if these aren't used, they can be examined as
      more example clients for people that wish to write their own
      client.

    - Load
      Balloon text is now customizable and can take a %L parameter to
      show current system load.

    - Clock 
      Made the "analog" display more configurable.  You can now set a
      clock format (refer to `man n clock' for a description of the
      format tokens) for the main display, the "hover" display, and
      the balloon text.  Thus, by setting these as follows:

	Time display:		%I:%M %p
	"Hover" display:	%I:%M %p
	Balloon display:	%A, %B %d, %Y

      you can emulate Win95's date/time system tray item.
      
    - Preferences/Clients
      A lot of places where a Unix command was specified, I've added
      options for a Tcl command as well.  I think I am going to
      eventually replace these with an "exec-preprocessor" that will
      either exec a process or run a tcl command, depending on whether
      or not the first "word" in the command is "Tcl".

    - Preferences/Colors
      Balloon window background color may now be specified

---

From: Jason L Tibbitts III <[email-masked]>
Date: 21 Apr 1999 15:34:52 -0500

>>>>> "lg" == larry gensch <[email-masked]> writes:

lg> 3.  I am looking for a "home URL" for the new tkgoodstuff.  I believe
lg> that Mark Crimmins had offered to use his site (which has the 8.0
lg> "final" version of the program), but I won't have direct control of
lg> that site.

I can put it on fvwm.org if you like.

lg> I'm currently considering the use of CVS.

You are also free to use our server.

 - J<

---

From: Bob Woodside <[email-masked]>
Date: Wed, 21 Apr 1999 17:36:50 -0400

> GSFR for externally-developed modules (a la tkgoodstuff)?

	Sure. As I said earlier, I'll need to update the module-writing HTML
pages in the docs directory, but here it is in a nutshell. A few things
are still in a state of flux, so minor changes may yet happen.

	First:

	if (! YourmoduleLooksAt(M_ADD_WINDOW | M_CONFIGURE_WINDOW) {
	  return (NothingToDo);
	  }

	The ADD/CONFIGURE packet is the only one that's changed. The old flags
word (the 9th word, not counting the 4 header words) is now a dummy
placeholder just to preserve alignment: it's always zero (but we might
change that). The window_flags bitfield structure (may be one or two
words depending on your machine architecture) is added to the end of the
old packet structure.

	Your module needs to inclued fvwm.h and vpacket.h, in that order.
vpacket.h defines structure layouts for all the new-style packets (all 1
of them!). If your module has a private structure in which it stores the
flags, these need to be included before your structure definition.

	To access the new packet, map the body of the packet to the
ConfigWinPacket structure defined in vpacket.h. If TkGoodStuff follows
the example of all the standard modules, it probably calls the body
"body", so you'd do something like this:

ConfigWinPacket  *cfgpacket  =  (void *) body;

	If your program copies the flags into a private structure of its own,
you'll have to 1) replace the flags word in your structure with an item
of type window_flags, and 2) replace the simple assignment (usually
something like MyStruct->flags = body[8]) with a memcpy for the length
of the structure - something like

    memcpy(&MyStruct->flags, &cfgpacket->flags,
sizeof(MyStruct->flags)).

	To reference or manipulate the flags, you'll need to use Dominik's
macros, which today are contained in gsfr.h (tomorrow that file may be
renamed to something else). gsfr.h is included by vpacket.h, so you
shouldn't need to change anything if/when the name changes.

	So now all you have to do is to track down all the old-style references
to the flag bits...well, actually, the comnpiler will track them down
quite nicely, you just have to change them. All the lines like

	if (body[8]&ICONIFIED)

need to change to something like

	if (IS_ICONIFIED(cfgpacket))

	The important thing to remember about the macros is that they expect a
window_flags structure to be within a larger structure (like
FvwmWindow).

	That's about all there is to it...unless (heh-heh) the module has a lot
of functions that pass the old flag word around as calling arguments and
return values. In that case, you may have a lot of grungy work cut out
for you. But you may not. I thought that would be the case with
FvwmTaskBar when I first looked at it, but the only flag it actually
cared about was the ICONIFIED flag; so I left its infrastructure intact
and just set an arbitrary bit in its private flags word to indicate
ICONIFIED.

	----------------------------------------------------------------

	Now, as for what's not yet cast in concrete....

	As I said, the gsfr.h header file may undergo a name change.

	Also, we may add a compatibility option for the old flags word to be
emulated, so far as is possible, in that dummy 9th word. Tim did some
magic over the weekend to emulate the old packets, and renamed the
actual ADD/CONFIGURE packets with new id's, so that old modules compiled
before the GSFR could continue to run (probably), and only recompiled
modules would know about the new packets.

	These issues shouldn't concern you in modifying your module. We're
simply trying to provide as much backward compatibility as possible so
that older modules that haven't been recompiled can still hope to run
(unless they care about a flag that no longer exists, like STAYSONTOP).

- Bob

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 22 Apr 1999 00:41:46 +0200

>     "final" version of the program), but I won't have direct control of

Is finding a home at fvwm.org out of the question for you? Both,
fvwm and tkgoodstuff should benefit from this.

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: Bob Woodside <[email-masked]>
Date: Thu, 22 Apr 1999 00:56:52 -0400

On 04/22, Bob Woodside blathered some nosense about:
> 
>         That's about all there is to it...

	Which was true enough, for the average C module; but yours is anything
but average.

	I just took a quick look at the 8.0 final that Mark left on his site.
I'll assume that my remarks still apply to your latest version.

	Passing the flags word as a hex string to Tcl, obviously, is out. This
part of the C-Tcl interface could get ugly...I certainly haven't thought
it out. What you really want to see on the Tcl side is for flags to
become an array in its own right, with members like flags(is_iconic) and
flags(do_window_list_skip), etc. - all the flags defined in
common_flags_type and window_flags in fvwm.h.

	Oh, yeah...watch out for those 4-state bits! (focus_mode is a two-bit
field - no offense intended to the author!  :-)  )

	I haven't had a chance to think it through much further than that, but
I hope I've given you a little help.

- Bob

---

From: [email-masked]
Date: Thu, 22 Apr 1999 10:20:19 -0400 (EDT)

> I'll assume that my remarks still apply to your latest version.

Actually, I changed the tkFvwm.c file (there were some quirks in it and
I wanted to support mini-icons, etc.).  The only states that I think
that tkgoodstuff is interested in is whether a window is iconified or
currently selected (I could be wrong).

In any event, I can make the current sources available on my home
system at:

	http://amberthree.dynip.com/~lar3ry/tkgoodstuff-8.1-rc3.tar.gz

(rc == release candidate)

The coding is complete; the only reason it's not ready for release is
that I have not updated the doco for it, and some things have changed.

> I hope I've given you a little help.

Yes, you have.  Thanks a lot!

---

From: [email-masked]
Date: Thu, 22 Apr 1999 10:29:38 -0400 (EDT)

> fvwm and tkgoodstuff should benefit from this.

Not out of the question at all.  tkgoodstuff is currently suffering the
same problems that plagued Chuck and Brady with fvwm 2.0 -- real life
is getting in the way of the maintainers.  [smile]