[TAG] Re: Mozilla and FVWM question

[Thomas Adam]

On Mon, Nov 14, 2005 at 10:21:34PM -0500, vsesto at adelphia.net wrote:
>  Hi Tom

I prefer "Thomas".

> Go for it! I will be playing with sometime this week.

Thanks.

> 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

Well, there's a few reasons why I would suggest this is a bad idea:

1.  Such things are really the job of the window manager.
2.  Your C/C++ program is vulnerable from all sorts of idiosyncracies --
    what happens if it dies, for instance?

When you say "death", what do you mean?  It's conceivable, that you can
stop this from happening with soemthing like:

``
Style Mozilla !Closable
''

... which at least stops accidental closure of all mozilla processes
(windows), by making the window not respond to any close or destroy
window events.

> 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?

You can use FvwmEvent -- indeed, I have mentioned this before it seems:

http://fvwm.lair.be/viewtopic.php?t=701

> 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 ...

Heh.  That's a classic FAQ.  Here's my answer in part from:

http://fvwm.lair.be/viewtopic.php?t=772

```
morlaa wrote:
i tried
Code:
+ I exec Eterm StartsOnDesk 4
+ I exec Eterm StartsOnPage  4
+ I exec Eterm StartsOnDesk 0 4


Right -- the "StartsOn{Desk,Page}" stuff can only be done via style lines (although re-read the thread that Johan pointed you at, as I have explained it enough there).

morlaa wrote:

as well as defining Style:

Code:
Style firefox StartsOnDesk 4
Style firefox StartsOnPage 4
Style firefox StartsOnDesk  0 4


Yes, these are the lines that you want -- but remember that in this instance, the LAST style line as you have it there will get used. Remember that a "Desk" is just a container for a number of "Pages" (again, the main FVWM FAQ explains the difference between them.)

morlaa wrote:

coz i am not sure how and where i define if i use desks or pages - forgot the difference, but as i switch them with
Code:
Key 1 A CM GotoDesk 0 0

it must be desks, no ?


In the first instance, yes -- but the second number will also switch to that specified PAGE as well.

morlaa wrote:

but still every startup-application starts on the desk 0 0
why ?


Because you're misunderstanding how things relate. Take Firefox (I have explained this in another thread, BTW). That will either have a class of:

``
Firefox-bin

or:

Gecko
''

The reason you want to match on a window's class in this instance is that it's more specific, and less ambiguous than the title of the window, which might be something like this:

"Fvwm Forums :: Post a reply - Mozilla Firefox".

Of course, some people would naturally match by title, and try a command such as:

``
Code:
Style *Firefox* StartsOnPage 0 4
''

... but this has some issues with it. Since you're matching firefox *anywhere* in the title, it could match erroneous windows, or ones you don't want. So the next thing to try is to match by "Class". To obtain a specific window's class, you can use a few methods. Perhaps the preferred option is using the module "FvwmIdent". Although window manager agnostic commands such as "xwininfo" and "xprop" can also be used. Hence, you'd replace the previous style command with:

``
Code:
Style Gecko StartsOnPage 0 4
''

... you can be fairly well assured that the Class of a window tends to be unique to that application (the exceptions are things like RXVT which sometimes have been known to set their class to that of Xterm.)

Indeed, you might be wondering how style lines know in which order to match. Truth is, they don't _really_ know how to match, however FVWM defaults to cycling through a known series of window attributes. Hence, FVWM will match your window name in a style command thus:

``
Code:

Title --> Class --> Resource
''

So it checks the title of a window first, and if a match is unsuccessful, it will then look at the class, and if that files, it will then look at the resource of that window for a match. By and large, where wildcards are used in style lines -- it's normally the window's title that gets matched in the first instance.

One thing I'd love to see in a future version of FVWM is something like:

Code:
Style (class=Xterm, title=foo) StartsOnPage 0 4


... which would really be quite powerful.
'''

> BTW do you know how to programmatically hide or make transparent the
> mouse pointer/cursor in X11 or in FVWM ?

Such things are a facet of the xserver, however there is a program
called 'unclutter' which is very configurable, and can hide the mouse
after a delay, etc.

Kindly,

-- Thomas Adam

--  
I don't want to stay.  I want to go home.