On 05 Nov 2002 19:06:33 -0500, Richard Lister wrote:
>
> I've added optional page and desk-level resolution and some
> documentation to the script. I've attached it here.
Nice, it is already pretty configurable. I see several possible
enhancements, not urgent though. And it is persistent. I thought
more about a transient module (yes, slower), this may be an option.
FvwmLister is a really good name for me, but maybe FvwmWindowLister?
You would probably prefer FvwmRichardLister, but this is close enough. :)
I will also reformat it to be more like FvwmPerl.
> As far as I understand it the trackers will make most of the stuff
> I've done in handlers redundant. Is that correct?
Yes, in theory your module will not need to handle any of your current 13
fvwm events itself, except for M_STRING commands. It will just load 3
trackers instead. In practive, for now M_ICONIFY/M_DEICONIFY will be
needed too until perllib may reliably parse window flags (Sticky/Iconic)
given in M_CONFIGURE_WINDOW.
There will be a lot of decisions to make for trackers and you may help.
Just to give you another idea. A user may implement his own trackers.
For example, "ColorsetForcer", something that verifies that bg of Colorset
5 is always "green" or synchronizes 2 colorsets when one is changed.
Another example may be "VisibleWindows" that forces windows to never be
fully off the screen. Then a user may reuse these user defined trackers
in his numerous modules by adding this (only the first line is needed):
my $tracker = $module->track("VisibleWindows", offset => 10);
print "Recovered old window: $_\n" foreach $tracker->recovered;
$tracker->trap(sub { print "Recovered new window: $_[0]\n"; });
Or a one time tracker that recovers the lost windows only once:
my $grabber = $module->grab("VisibleWindows", offset => 10);
print "Recovered old window: $_\n" foreach $grabber->recovered;
As you see, this implementation not only recovers windows internally (by
sending Move commands), but also optionally reports about such windows.
The problem is to decide what is the synchronous part (when these calls
return) and what is asynchronous. This is individual for every tracker.
There is no any problem if different trackers or a user himself decide to
listen to the same packets. Trackers are fully transparent for a user,
they just do their work (in your case they automatically collect an info).
> A bug in my script ... sticky windows are only listed on the desk
> where they originated (were made sticky). This is not a problem
> when changing page, as there seems to be a M_CONFIGURE_WINDOW packet
> sent for each window in that case and I set the desk from that handler.
> But these packets are not send for a change desk event. Why is that?
> I could probably get round this by doing a Send_Windowlist when
> M_NEW_DESK is caught, but that seems clunky :-)
I have no debts that M_NEW_PAGE / M_NEW_DESK are inconsistent and pretty
unusable sometimes. The sooner we unite these to one M_NEW_DESK_PAGE the
better. A side note, the PageInfo tracker API will probably not be changed
when such packet change happens, just its internal implementation.
Regards,
Mikhael.
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
