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 rjray_at_uswest.com
"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 majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Fri Mar 21 1997 - 15:16:30 GMT