Thomas Adam wrote:
> Let's see what I notice first of all:
>
> # 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
I restarted it using this key binding:
> Key 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.
> Without 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.
> So 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.
> If 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.
> So I suspect something is closing it.
But, what could it be?
> I 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.
> and 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.
> But the minipager there is a gratuitous "hack" for what is simply a desk
> chooser -- something you can use FvwmButtons for -- and this is ultimately
> what you *should* be doing. Here:
>
> 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...
> ... 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,
> here's one way of doing it using FvwmEvent:
>
> 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
