Post by Thomas Adam# start several pagers
AddToFunc StartFunction
+ I GotoDesk 0 0
+ I FvwmPager minipager 0 11
+ I Wait minipager
+ I GotoDesk 0 0
+ I FvwmPager 0 3
+ I Wait FvwmPager
+ I GotoDesk 0 1
+ I FvwmPager 0 3
+ I Wait FvwmPager
... etc., etc. You seem to have not heeded my very original advise to you
regarding *why* the above is problematic. It doesn't have anything to do
with your problem, BTW, it's just mildly frustrating that you're asking for
help and not doing anything with the advise you're given.
If you speak about the wait function: I *tried* to avoid the
wait function. I wrote another solution using StartsOnDesktop
instead of the wait function. The result was that fvwm
did not keep the current desk + page anymore after
Post by Thomas AdamKey Pause A CM Restart
After each restart, fvwm showed a random desktop and page.
Using the wait function, after a restart, fvwm shows exactly
this desktop and page that was shown before the restart.
This is the reason why I still use the wait function.
So, I do not ignore some advices of you. I just found
out that not every advise works for me and the fact
that I did not have the time to write you that some
advice did not work because it has unwanted side effects
makes you think that I just ignore your advices.
(When I started learning fvwm, there where a lot of
problems I was faced with, so I had to assign priorities
even within my littly project "learning fvwm", and
justifying why I anyway need the wait function
had a low priority, because this construction site
at least worked for me without problems.)
Another advise of you is using the latest version of fvwm.
I use an experimental Linux system to test the problems
at the latest fvwm 2.5.31. It was not so easy to
find out how to update the "2.5.30" to a "2.5.31",
but finally I got the result after finding out
in the hard way that I need to install "libx11-dev",
"libxt-dev" and "libgtkglext1-dev" to get this
package compiled and installed. There is no tutorial
in the web that explains such kind of stuff. I had
to read the error messages, guess the problems,
made an odyssey of trial and error and finally I
had a solution that cost some hours of hard work
and looks as simple as installing three lousy
packages: That is to say "libx11-dev", "libxt-dev"
and "libgtkglext1-dev".
But: Testing something at experimental Linux systems
is one thing. The other thing is that I have to
work with a stable Linux system. And this is
currently Debian Linux Lenny with fvwm "2.5.26",
and this has to work until another Linux system
with newer components becomes stable and I
get the time to customize it. So, also here,
it appears that I ignore an advise of you (using
the latest version of fvwm), but doing this is
simply a risk that I cannot take. All I can do
is making a compromise and test some problems
at my late-breaking test system with the newest
fvwm before I post the problem to the fvwm mailing
list.
Post by Thomas AdamWithout your entire config present, I can't offer an explanation as to why
you get the results you do -- it might very well be that the pager is
closing, but that's different from crashing.
You don't need my entire config. I reduced it and the pager still
disappears (to avoid the term "crash)". I posted all the config
you need to get the minipager disappeared.
What I could do is to remove the second pager: This one that
shows 4 desktops at the same time. If still the remaining minipager
disappears, then it would show that the other pager does not have
something to do with the bug that I found.
Now, I can do these things:
1.) Remove the second pager and prove that the remaining minipager
still disappears, just using this minimum set of config files
that I will post then.
2.) Try out your suggestions about using FvwmButtons, KillModule,
Piperead and so on. This will cost me some extra hours, but
if this gives me a more clean fvwm configuration that still
satisfies my requirements, then I could spend these hours,
learn something and improve the quality of my fvwm config files.
Post by Thomas AdamSo by this point, for each of your defined desks, we have a separate pager
per *page*. Meanwhile, there's only one instance of your minipager running,
it's just sticky. Fine. But if it closes, then it closes completely and
you'll never see it again.
Yeah, but, it is not planned that it closes. It is to run until
I finish the fvwm session and shut down the computer.
Post by Thomas AdamIf it crashed you would get a corefile -- I
promise you that.
I still do not know if my system is able to generate a core
file. The last core file that I saw was sometime around the year 2000
and this was not a Linux system.
Post by Thomas AdamSo I suspect something is closing it.
But, what could it be?
Post by Thomas AdamI don't know what, I *might* be able to tell from looking at
the rest of your configs,
No. The rest is irrelevant. I removed the rest, restarted the
system and reproduced the bug. My fvwm was completely naked,
only using these 3 config files that I posted, without any
comfort.
Post by Thomas Adamand even
an ~/.xsession-error log, if FVWM ever printed anything there.
Good idea. If I find something useful in this file, then I will
post it.
Post by Thomas AdamBut the minipager there is a gratuitous "hack" for what is simply a desk
chooser -- something you can use FvwmButtons for -- and this is ultimately
DestroyModuleConfig foo:*
*foo: Columns x
*foo: Rows y
*foo: (1x1, Title z, Action (Mouse 1) GotoDesk z)
A simple desk chooser. This is what I'm looking for.
And it is to highlight the current desk and print a
number at each desk.
As soon as I have time, I will try out your foo thing
(using FvwmButtons to create an instance with the
name "foo" I suppose).
If this thing would solve my needs, then I could stop
wasting my time proving that FvwmPager is buggy...
Post by Thomas Adam... where: x, y and z, are calculated from $[pages.nx] $[pages.ny], etc.
That's an exercise best left to you to work out -- hint: PipeRead is your
friend here and a simple for(( .....)) loop in sh.
Now -- the part that makes this more interesting is making your requirement
of seeing only four desks per desk for which you're currently on. Well,
DestroyModuleConfig foo2:*
*foo2: new_desk SomeFunc
AddToFunc StartFunction I Module FvwmEvent foo2
DestroyFunc SomeFunc
AddToFunc SomeFunc
+ I KillModule FvwmPager some_alias
+ I PipeRead `[[ $[desk.n] -le 3 ]] && echo \
"Module FvwmPager some_alias 0 3" ||
[[ $[desk.n] -gt 3 ]] && [[ $[desk.n] -le 7 ]] && \
echo "Module FvwmPager some_alias 4 7"`
... etc., etc. Note that I'd use a simple modulo calculation to make this
easier here.
Now -- the interesting part here is that if you made this pager sticky --
you could then also selectively work out within a given range of a desk you
were on, whether you needed to kill the pager or not -- reducing the need to
start it up again each time. But that's just showing off... :)
You think that killing and restarting applications is better
than using the wait function? I'm indetermined, but if you think so,
I could give it a try. At first sight, it looks good. Perhaps
I should post the side effects if I find some instead of dismissing
the whole solution without posting any reason about it, so you
cannot easily blame me for ignoring your advises...
Michael