[TAG] Re: Mozilla and FVWM question
vsesto@adelphia.net
vsesto
Tue Nov 15 06:21:34 MSK 2005
Hi Tom
Go for it! I will be playing with sometime this week.
The reason I mentioned mutexes and semaphores below is because I was thinking about having a separate script or perhaps C/C++ program that would monitor the death of either Mozilla profile instance and simply restart it as that is the behavior I am seeking. So, I could have like a waitpid ... once Mozilla dies the script could issue these FVWM functions with FvwmCommand but it could also be protected with a mutex so that we don't try to start two Mozilla instances at the same time ... I think the issue with doing that is one runs the risk of having Mozilla start on the wrong desktop. Or, is there a way to have a Function within FVWM monitor this also?
One thing I wondered about was do we run the risk when using "Style" in our RC file that when an error occurs like from getting a page in Mozilla or whatever and it pops up an error box ... how do we ensure that it actually shows up on the right desktop! I guess what I am saying is that if we are on desk 2 with Mozilla profile1 and surf to a page ... then we switch while it is working on it to desk 3 Mozilla profile 2. Say and error occurs with the fetch ... does FVWM know to display this on desk2 and not desk3? One way to deal with programmatically is if we had an app that "knew" which desk we were on we could adjust the "Style" dynamically via FvwmCommand ...
BTW do you know how to programmatically hide or make transparent the mouse pointer/cursor in X11 or in FVWM ?
Thanks much for your help it is much appreciated!
Vin
---- Thomas Adam <thomas at edulinux.homeunix.org> wrote:
> [ Vin: I've CCed The Answer Gang, part of inuxgazette.net, as I feel my
> answer to you will benefit others. If you'd rather we publish this, but
> anonymise your name, do so. Othwerwise, I'll publish this verbatim,
> with attribution as-is. ]
>
> On Thu, Nov 10, 2005 at 09:23:15PM -0500, vsesto at adelphia.net wrote:
> > Hello Thomas
>
> Hello,
>
> > FvwmCommand 'Style Mozilla* StartsOnDesk 1, SkipMapping' \
> > mozilla -P foo1
> > sleep 5 // Had to do this sort of thing
>
> The sleep ensures that the window has been mapped before you start the
> next instance, such that you were able to change Styles. It's a
> solution, but not a very good one.
>
> > FvwmCommand 'Style Mozilla* StartsOnDesk 2, SkipMapping' \
> > mozilla -P foo2
> >
> > Although this does work ... I kinda don't like the sleep ... I
> > eventually wouldn't mind surrounding this concept with a mutex or
> > semaphore from an app but on to your grand idea! I have a couple of
> > questions below ...
>
> Mutexes and semaphores are only terminology --- they're not employed
> within the context of FVWM when managing windows.
>
> > > Then you could use a function. How about something like this:
> > >
> > > DestroyFunc StartMozilla
> > > AddToFunc StartMozilla
> > > + I Any (Mozilla) PipeRead `[ $[desk.n] == 0 ] && \
> > > Nop || echo "Exec exec mozilla -P foo" && \
> > > echo "Wait Mozilla" && \
> > > echo "Next (Mozilla) MoveToDesk 0"`
> > > + I Any (Mozilla) PipeRead `[ $[desk.n] == 1 ] && \
> > > Nop || echo "Exec exec mozilla -P foo2" && \
> > > echo "Wait Mozilla" && \
> > > echo "Next (Mozilla) MoveToDesk 1"`
> > >
>
> > Could you expand a bit as to how each line works? Like would I still
>
> Sure.
>
> ``
> DestroyFunc StartMozilla
> ''
>
> This line destroys the function from a previous definition (if there was
> one.) It's useful where you want to make FVWM forget about a previous
> definition, especially where variables have been used.
>
> ``
> AddToFunc StartMozilla
> ''
>
> This line adds to an existing function, if it already exists, else it
> just defines it. Assume that we have a defined function: X.
>
> AddToFunc X
> + I Exec exec xmessage hello
>
> If we were to type (into FvwmConsole):
>
> X
>
> ... then xmessage would appear with the word "hello". If we then did:
>
> AddToFunc X I Exec exec xmessage "Another Message"
>
> ... we'd then see two messages. "Hello" and "Another
> Message". The point here though, is that AddToFunc app ends
> to an existing function, so an order of operation is needed.
>
> ``
> + I Any (Mozilla) PipeRead `[ $[desk.n] == 0 ] && \
> ''
>
> ... we're really going into shell teritory here. "Any" matches, well, any
> window which satisfies a given condition. In this case, I'm testing for
> any window which matches "Mozilla". Now, I know you've read the thread
> on the FVWM forums about this [1] -- so you'll know that "Mozilla" might
> match:
>
> ``
> Title -> Class -> Resource
> ''
>
> In this case (and you'll have to check this yourself, since it seems to
> vary) "Mozilla" is the class name. Unlike they keyword "All" -- this
> just macthes any window, and will stop at the first one it finds. What
> happens next with the PipeRead command is that we then evaluate things
> at the shell:
>
> ``
> PipeRead `[ $[desk.n] == 0 ] && \
> ''
>
> PipeRead is a powerful resource, that allows one to evaluate conditions
> at the shell level, and send results back to FVWM for processing. Why
> bother with this? Well, FVWM cannot perform any conditional
> interpolation or perform any comparison of variables by itself [2]. One
> thing you should be aware of is that FVWM internally sets up read-only
> variables for itself. "desk.n" happens to be one of them, and holds (at
> any one time) the current desk number.
>
> So -- this becomes nothing more than sh scripting at this point. Note
> that I say "sh" -- the actual shell that gets used is dependant on the
> following command being set:
>
> ``
> ExecUseShell /bin/sh
> ''
>
> ... FVWM defaults to using /bin/sh if the above is not defined in your
> .fvwm2rc file. Essentially if the current desk is equal to 0 then:
>
> ``
> Nop || echo "Exec exec mozilla -P foo" &&
> ''
>
> ... do nothing (Nop). Yep. That's right. The assumption is that we're
> on another desk. (I just assumed this might be the case...) If
> however, we're not on desk 0 then Mozilla is started with a specific
> profile. The "echo" command is important --- we're sending _back_
> soemthing to FVWM to process. This is the whole point of PipeRead.
> Evaluate and Send. Note though:
>
> ``
> Exec exec
> ''
>
> "Exec" is a FVWM keyword, and forks to a shell. This is one instance,
> in terms of FVWM commands where case matters. The second exec (as it is
> in lower case) is at the shell-level so the command that follows _that_
> will be replaced -- effectively reducing the number of processes.
>
> ``
> echo "Wait Mozilla" && \
> ''
>
> This commands waits for the window to mapped, in the managed state.
> Note that Wait only works for a window's title, so you might want to
> specify something more descriptive.
>
> ``
> echo "Next (Mozilla) MoveToDesk 0"`
> ''
>
> Next matches windows which are next within its ring of windows. FVWM
> internally stores windows. The focused window is the current item in
> the list. Next, as you might expect, looks for the next window. Of
> couse, since we've waited for the window to appear, once the window is
> mapped, it's a prime candidate for the Next command -- and also, since
> it accepts the class/title/resource as a condition. If the window is
> matched (based on the class name, in this case) then it is moved to Desk
> 0.
>
> The whole process is repeated, assuming you were on Desk 1. Now, I have
> to admit to repying initially to you, having just woken up, so I would
> not have taken into account that fact that you probably have more than
> two desks, and also the SkipMapping feature is quite useful.
>
> > need to put the "Style Mozilla" line in the fvwm2rc file or will
> > the code above just work as is? Does the wait actually wait for
>
> The function as I have explained it should Just Work, irrespective of
> your Style lines.
>
> > Mozilla to be viewable? Would I need to reference the StartMozilla
> > & DestroyFunc elsewhere in the file? I know that the SkipMapping
> > feature is something I like because it doesn't cause the instance of
> > Mozilla to force a desktop switch. For instance, when I issue this
> > line from within the rc file ..
> >
> > Style Mozilla* StartsOnDesk 2, SkipMapping
>
> You're using "Mozilla*" --- that's OK, but do heed the caveats [1].
>
> > and if I am on a different desktop doing something else ... the cool
> > thing is that it doesn't cause Mozilla to make itself viewable UNTIL
> > I decide to switch to that desktop. How can your function account for
> > the SkipMapping functionality ... it's quite nice and something I need
> > to be able to do!
>
> Well, what we're going to have to do, is rethink our approach slightly.
> All of this would be easier, if Mozilla actually allowed options to
> change its name prior to the window being mapped. What we could do, is
> go with the _MOZILLA_PROFILE atom. So, how about something like this:
>
> ```
> DestroyFunc StartMozilla
> AddToFunc StartMozilla
> + I All (Mozilla) ThisWindow PipeRead `[[ $[w.desk] -eq 1 && \
> "$(xprop -id $[w.id] '_MOZILLA_PROFILE')" = \
> '_MOZILLA_PROFILE(STRING) = "foo"' ]] || \
> echo 'Style "Mozilla Firefox" StartsOnDesk 1, SkipMapping"' && \
> echo 'Exec exec mozilla -P foo'`
> + I None (Mozilla) PipeRead `echo 'Style "Mozilla Firefox" \
> StartsOnDesk 1, SkipMapping"' && \
> echo 'Exec exec mozilla -P foo'`
> + I All (Mozilla) ThisWindow PipeRead `[[ $[w.desk] -eq 0 && \
> "$(xprop -id $[w.id] '_MOZILLA_PROFILE')" = \
> '_MOZILLA_PROFILE(STRING) = "foo_profile"' ]] || \
> echo 'Style "Mozilla Firefox" StartsOnDesk 0, SkipMapping"' && \
> echo 'Exec exec mozilla -P foo_profile'`
> + I None (Mozilla) PipeRead `echo 'Style "Mozilla Firefox" \
> StartsOnDesk 1, SkipMapping"' && \
> echo 'Exec exec mozilla -P foo'`
> '''
>
> I'll go through this line by line for you. Essentially you can add that
> to your .fvwm2rc file, somewhere.
>
> First part:
>
> ``
> + I All (Mozilla) ThisWindow PipeRead `[[ $[w.desk] -eq 1 && \
> ''
>
> Within the function context "I" is immediate, so the action is implicit
> on invokation in this case. As we have seen before, "All" operates on
> _all_ windows that match the given condition -- in this case a class
> name for Mozilla (this will vary, so use FvwmIdent, or xprop to find
> out the exact name.) This is all well and good, but how do we reference
> each window in turn for a given context? That's where ThisWindow comes
> in.
>
> Again, we'll turn to the shell to do some conditional processing.
> Initially we should check to see whether there are any instances of
> Mozilla running, and on which desk. The "$[w.desk]" variable can tell
> us this. If it equals 1...
>
> ```
> "$(xprop -id $[w.id] '_MOZILLA_PROFILE')" = \
> '_MOZILLA_PROFILE(STRING) = "foo"' ]] || \
> '''
>
> ... and the current window matched (via the windowID -- which is what
> the xprop command uses to match windows) matches the _MOZILLLA_PROFILE
> atom, such that it is matched against profile "foo", then do a negation.
> That's what the "||" does. If the entire test we have just done proves
> to fail, then there's probably a need to start Mozilla. So:
>
> ```
> echo 'Style Gecko StartsOnDesk 1, SkipMapping"' && \
> '''
>
> ... before we can start it though -- we should set a style for the
> window we're about to create. I've gone for class-matching rather than
> by title [1], making it start on desk 1, and to skip warping the
> viewport to the desk it starts on. Assuming that went OK, we can now
> launch Mozilla:
>
> ```
> echo 'Exec exec mozilla -P foo'`
> '''
>
> That's the logic for part one, anyway. But that only works if there's
> some instances of Mozilla open, but they're not using the profile we're
> wanting to use for a particular desk. So we also need to check for the
> opposite of that --- for the likelihood that there are no Mozilla parts
> running. Hence:
>
> ```
> + I None (Mozilla) PipeRead `echo 'Style "Gecko" \
> '''
>
> As I am sure you can guess, "None" matches for no windows for a given
> condition. If it is true, that, there are no windows that match
> 'Mozilla', then we just set the style of application to startup, and
> execute it as before:
>
> ```
> StartsOnDesk 1, SkipMapping"' && \
> echo 'Exec exec mozilla -P foo'`
> '''
>
> The exact same procedure happens for Desk 0 as well.
>
> There are one or two caveats that you will need to be aware of. The
> first one is that this entire function is limiting you to starting
> Mozilla in a certain way. Now it might be that this doesn't bother you.
> But it is inflexible. If you were to add that function to your .fvwm2rc
> file, you have a few choices of launching it:
>
> 1. From a menu:
>
> ```
> AddToMenu <some_menu> "Start Mozilla" Function StartMozilla
> '''
>
> 2. From a key-binding:
>
> ```
> Key F2 M A StartFunction
> '''
>
> ... which is for Alt-F2, in any context.
>
> 3. Via FvwmCommand:
>
> ```
> FvwmCommand 'StartFunction'
> '''
>
> Just typing in "mozilla" at an xterm won't invoke it in the correct way.
> So, the other option is to use FvwmEvent, to detect and then shift the
> mozilla instances to their respective locations. But I might save that
> for a later date.
>
> What you might also find in using that function is race-conditions. So,
> you might have to add a few:
>
> ``
> + I TestRc (NoMatch) Break
> ''
>
> statements, between each of the main lines, to exit once a set feature
> has completed.
>
> > > > So, say I wanted two different profiles ... mozilla -P profile1
> > > > and mozilla -P profile2
> > > >
> > > > How would one enter that in fvwm2rc file?
> > >
> > > See the function above -- the problem is that unlike other non-EWMH
> > > aware applications, you can't change various properties of the
> > > window which would make things easier -- so what I have done is to
> > > base the loading of Mozilla, not for profile, but for whether an
> > > instance of it is running on a particular desk.
> > >
> > > -- Thomas Adam
> > >
> > > -- "Try not to want people to like you too much, you'll just need
> > > more and more flatteries to recharge your batteries." -- Jeffrey
> > > Lewis.
> >
> >
> > I do like the idea of basing it on an instance of Mozilla running
> > already on a desk since I only care about one per desk anyway.
> >
> > The other thing I was thinking about was trying to tie into the
> > _MOZILLA_PROFILE atom setup in X11 as it does tell me which profile is
> > actually running ...
> >
> > Thanks.
> >
> > Vin
>
> See above. I hope it helps you, or inspires you to create a better
> solution.
>
> -- Thomas Adam
>
> [1] http://fvwm.lair.be/viewtopic.php?t=772
>
> [2] This is not so true of FVWM 2.5.14 -- this has "EnvMatch" and
> "EnvIsSet" conditions to the Test command so that one can do:
>
> ``
> SetEnv foo 0
> Test (EnvMatch foo 0) Exec exec xmessage "OMG. It's zero"
> ''
>
> --
> "Try not to want people to like you too much, you'll just need more and
> more flatteries to recharge your batteries." -- Jeffrey Lewis.
More information about the TAG
mailing list