Subject: FVWM: X11::Fvwm

From: "Randy J. Ray" <[email-masked]>
Date: Fri, 21 Mar 1997 14:15:58 -0700

Well, I have only heard from one person thus far about the initial alpha. I
don't know how many people are looking at this API, but if you are I could use
some feedback. If no one is yet, I can make the proposed changes without
remorse! :-)

If you are not a Perl programmer, you won't be interested in the rest of this..

There are two major changes I am considering for alpha-2. The first is in
the parameters that get sent to packet handler routines. Currently, the list
is the packet type followed by three or more args, depending on the packet
type. In this current means, there is no way for a packet to have access to
the X11::Fvwm object itself, unless (a) the object is a global variable, or
(b) the handler is created as a closure (an anonymous subroutine), and as
such you can refer to the object, since it will be visible to the lexical
scope of the closure. I don't like (a). A big part of the reason for doing
this object-oriented is to avoid a glut of globals within the package itself,
so I'm not about to advocate that programmers using my API use globals if they
don't want. As for (b), well, it's not a bad thing, really. But it is not my
place to dictate to the programmer that all packet handlers be closures. Plus,
if I do, then it hamstrings my efforts to develop X11::Fvwm::Defaults.pm, a
collection of simple default packet handlers for packets such as M_ERROR
(without Tk, it uses Perl's carp() to report the error, which includes a
subroutine-trace for debugging aid. Under Tk, would pop up a dialog reporting
the error and giving the user choice of Quit or Continue). Since these pre-
defined routines would not be closures, I can't rely on the scoping to give
me access to either an X11::Fvwm instance, or a Tk object instance.

Which leads in to the second issue. Rather than having the X11::Fvwm class
looking specifically for Tk to be loaded (or defaulting to a simpler event
loop), I find that it might be better to separate the Tk hooks from the general
Fvwm API code. That is, the routine/method X11::Fvwm::eventLoop should only
be running the simple loop. I think it better to have X11::Fvwm::Tk as a 
subclass. The subclass would then define eventLoop to be the Tk one. It would
also have an extra instance variable, for tracking the Tk object that acts as
a TopLevel for this application (so that event handlers such as M_ERROR have
a Tk object from which to derive Dialog boxes, etc). What would this gain?
Well, the one response I did get to my posting of the alpha version was someone
interested in using X11::Fvwm, but would rather use the Perl interface to
XForms instead of Tk. Under this proposed model, that would be as easy as
writing X11::Fvwm::XForms.pm.

Randy
--
===============================================================================
Randy J. Ray -- U S WEST Technologies IAD/CSS/DPDS         Phone: (303)595-2869
                Denver, CO                                     [email-masked]
"It's not denial. I'm just very selective about the reality I accept." --Calvin
===============================================================================
--
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: "Barry A. Warsaw" <[email-masked]>
Date: Fri, 21 Mar 1997 16:24:49 -0500

>>>>> "RJR" == Randy J Ray <[email-masked]> writes:

    RJR> Well, I have only heard from one person thus far about the
    RJR> initial alpha. I don't know how many people are looking at
    RJR> this API, but if you are I could use some feedback. If no one
    RJR> is yet, I can make the proposed changes without remorse! :-)

I haven't gotten that much feedback about my Python FVWM module
either.  I just suspect that there aren't that many (new) module
writers out there.

-Barry

---

From: Jason L Tibbitts III <[email-masked]>
Date: 21 Mar 1997 18:17:57 -0600

>>>>> "BAW" == Barry A Warsaw <[email-masked]> writes:

BAW> I haven't gotten that much feedback about my Python FVWM module
BAW> either.  I just suspect that there aren't that many (new) module
BAW> writers out there.

I suspect that most people believe it's an extremely advanced subject.  I
don't believe it is, but perhaps some good example code would help.  I
think something like FVWMTile would be a great thing to clone.

I'd really like to play with the Perl module but I just don't have any free
time as I'm currently embroiled in rewriting Majordomo.

 - J<