> <Gulp>? On what grounds? I mean, they both need timing, but what can there
> be common to both? (OTOH, I hardly looked at the sources, and I know
> almost nothing about X programming, so...)
Exactly the timing. Ther rest of the code (the 2 types of placement) has
already been implemented. Now, all we need to do is to connect them
together.
> > Which raises the question, Should there be a
> > placement module? Can there be, if the server is grabbed during
> > placement? Hmmmmm....
> I have no idea regarding the second question... But here's a sad point
> about all this modules stuff: The strongest AIZ that I can find at work
AIZ? I am unfamiliar with this term.
> starts "No more proccesses"ing me after very few clients. I run
> FvwmTaskBar (oh, yeah, didn't I mention it? I use fvwm95 20.42a) so it
> comes to a point I start killing xbiffs and so one by one. This is one
> disadvantage I see for using modules. Another thing is that starting a
> module is still relatively slow. Often it takes 3 to 7 seconds for
> FvwmIdentify to fire up. (This is on a range of machines: Pentium/Linux,
> RS6000/AIX, SGIs/irix, Suns Sparcs & Ultras running SunOS and Solaris).
I have a dual headed Sparc 5, 64megs of RAM, Solaris 2.5. FvwmIdent pops
up almost instantaneously, as do xterms and other small clients. And you
should not run out of processes unless you have LOTS of ram in a very
heavlily loaded machine, or there is some accounting scheme.
It is an accepted fact that the modules should be dynamically loaded
libraries, much like the modules from the linux kernel. It is just that
there is no easy way of doing this in an architecture/compiler indep sort
of way. So multiple processes it is.
> At times it can be very useful, for example, when you spawn a new netscape
> window with button-2, you can resize it to not hide your current reading
> matirial. I also thought about (long ago) a combo move/resize module,
> which will allow one to draw a rectangle on the screen (like you draw a
> rectangle in a drawing program), and this changes a window's geometry at
> once. Much quicker than moving-then-sizing when you want to take an
> annoying window out of the way.
That sounds like a good idea. It would require some major code changes
though...
> Hmm, now that you mentioned xmag, I never quite got the grip of its button
> selections. I would use:
>
> - mouse movement = window movement
>
> - button-1 down = nop
>
> - button-1 release = accept geometry, show window
>
> - button-2 drag = change window size. This moves a point which
> is the original bottom-left corner, although you can make it any
> other corner by dragging it to the right (ahem, left) place.
>
> - button-3 click = I don't care where you put the window. Places the
> window randomally or smartly out of the way.
>
> - button-3 click while button-1 or -2 are down = toggle a flag,
> which will cause the window to iconify as soon as we decide where we want
> it.
Well, your button choices are not what I would have chosen, but they seem
to work. I will take a look, and see what I can do, (in between bursts of
actual work that someone is paying me for.... ). We'll see.
ericb
--
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 Sun Aug 10 1997 - 14:36:44 BST