start program in another window? (alt-2 alt1)

Using applications, configuring, problems
Post Reply
Message
Author
User avatar
divisionmd
Posts: 606
Joined: Sat 14 Jul 2007, 20:42

start program in another window? (alt-2 alt1)

#1 Post by divisionmd »

Hello,

- Is it possible to start a program in "ALT-1" window? while user is in ALT-3 window?

- And doing this from a bash script.. .

Thanks,

Best regards,
Johan

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#2 Post by npierce »

To make JWM launch a program on Desktop 1, add this to your /root/.jwmrc file (in the section where you see other groups):

Code: Select all

<Group>
<Name>yourprogname</Name>
<Option>desktop:1</Option>
</Group>
[CORRECTION:, 2013-Mar-24: In the Puppy world, the JWM user configuration file, /root/.jwmrc, often gets overwritten. A better file to add your changes to is the /root/.jwm/jwmrc-personal file. If you have no groups already defined in that file, a good place to add one is just before the closing </JWM>.]

If there are times that you don't want it to launch on Desktop 1, then create a symlink. For instance, if your program is in your /root/my-applications/bin/ directory:

Code: Select all

ln -s yourprogname /root/my-applications/bin/yourprogname_d1
And use the link's name in /root/.jwmrc, instead of the program's name.

Then restart JWM.

Once you have done that, nothing special is needed to start it from a script. This should be enough:

Code: Select all

#!/bin/bash
yourprogname_d1 &
[EDITED, 2013-Mar-24 to suggest a better configuration file to use.]
Last edited by npierce on Sun 24 Mar 2013, 13:19, edited 1 time in total.

User avatar
tallboy
Posts: 1760
Joined: Tue 21 Sep 2010, 21:56
Location: Drøbak, Norway

#3 Post by tallboy »

Thank you for that question, divisionmd, and thank you for the answer, npierce! That function is what I missed the most from the fvwm2 in my big debian!

Q: When it start a program in another window, that window also get focus (for those unsure of what that means; it also changes your view to that window). Is there a way to make it start in another window 'in the background', i.e. without the window gettng focus? Then I can drop my Firefox script into /root/Startup, and have it open and ready on desktop 4, when I choose to go there.

Q: Where do you find these programming bits for jwm, I have searched wihout finding much, I don't think the jwm home page is very useful in that respect.

tallboy
True freedom is a live Puppy on a multisession CD/DVD.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#4 Post by npierce »

You're welcome.

First, I should make a correction. I briefly forgot that I am now living in the twenty-first century and the world is full of little utilities that like to overwrite user configuration files. While .jwmrc is the proper place for JWM user configuration, in the Puppy world you should use the /root/.jwm/jwmrc-personal file, if not your changes may not survive for long.

If you have no groups already defined in that file, a good place to add one is just before the closing </JWM>.

tallboy wrote:When it start a program in another window, that window also get focus . . .
That's interesting. It doesn't do that for the version I am using. I still see the same desktop after starting the program and have to manually switch to the other desktop to see the program window.

But I have an old version: JWM vsvn-505

What version are you running?

I wonder if adding the nofocus option to the group would help?

Code: Select all

<Option>nofocus</Option>
tallboy wrote:Q: Where do you find these programming bits for jwm, I have searched wihout finding much, I don't think the jwm home page is very useful in that respect.
I'm not sure what page you are looking at. I generally find JWM to be quite well documented. Configuration info is on this page:
http://www.joewing.net/projects/jwm/config.shtml

More specifically, the section describing groups is here:
http://www.joewing.net/projects/jwm/config.shtml#groups

Those pages are currently for the v2.2. release, which is a work in progress. For the v2.1 release see:
http://www.joewing.net/projects/jwm/config-2.1.shtml

User avatar
tallboy
Posts: 1760
Joined: Tue 21 Sep 2010, 21:56
Location: Drøbak, Norway

#5 Post by tallboy »

npierce wrote:I briefly forgot that I am now living in the twenty-first century...
Uhh, when did that happen, I don't understand what you mean... :shock:

I forgot that one of the first lines in /root/.jwmrc is:

Code: Select all

IMPORTANT, ONLY EDIT /etc/xdg/templates/_root_.jwmrc
:oops:

tallboy

EDIT: I cannot make it work! I have tried to modify /root/.jwmrc, /etc/xdg/templates/_root_.jwmrc. as well as /root/.jwm/jwmrc-personal (in separate sessions , of course), I have restarted jwm, I have restarted X; nothing happens!
I use LupuPlus_5.2.8, the jwm version is the default vsvn_500.

EDIT II: Not entirely true! I can make some programs do as intended, and open in another desktop, but others fail to do so. An example: I have installed the diagram drawing program Dia, and the genealogy program Gramps. The command to open Dia is 'dia-normal', but I often forget, so I have made a symlink /usr/bin/dia. If I enter 'dia-normal' into the code lines in /root/.jwm/jwmrc-personal, 'Dia' open in another desktop, also by clicking the desktop icon. If I enter 'dia' in the code, nothing happens. It says in the description of the function, that it also understand *, but if I use 'dia*' in the code, nothing happens. If I use 'gramps', nothing happens, the same with 'firefox' or 'defaultbrowser'. Why do jwm behave differently with different programmes?

divisionmd, did you make it work? Which puppy?
True freedom is a live Puppy on a multisession CD/DVD.

User avatar
divisionmd
Posts: 606
Joined: Sat 14 Jul 2007, 20:42

#6 Post by divisionmd »

Hello Tallboy and npierce,

thanks for answers and comments, questions.

i did not get jwm to work (starting a program hidden) - however i know this works actually did this a few years ago... just need to find my old notes...

or if someone has a working example of this .jwmrc


best regards,
Johan

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#7 Post by npierce »

tallboy wrote:Why do jwm behave differently with different programmes?
Sorry, when you mentioned Firefox a little light should have gone on in my head, reminding me that you might need more details. The actual process that runs for mozilla browsers and creates the window is rarely, if ever, the same as the process that a user runs to start the browser.

It is the process that creates the window that determines the name that must match the <Group><Name> field.

I don't know what the order of events is when starting Firefox in LupuPlus_5.2.8, but as an example, here is the order for starting SeaMonkey in Racy 5.2.2:

defaultbrowser (/usr/local/bin/defaultbrowser) runs
mozstart (/usr/local/bin/mozstart), which runs
mozilla (/usr/bin/mozilla), which is a symlink to
/usr/bin/seamonkey which is a symlink to
/usr/lib/seamonkey/seamonkey, which is a symlink to
/usr/lib/seamonkey-2.3.2/seamonkey, which runs
/usr/lib/seamonkey-2.3.2/run-mozilla.sh, which runs
/usr/lib/seamonkey-2.3.2/seamonkey-bin

Yes, it goes through all that just to start a browser. Nothing is simple anymore. (Could convoluted stuff like that help to explain the decline in enrollment for Computer Science majors? :) )

Anyway, I figured that the correct value for the <Group><Name> field would be "seamonkey-bin". But that didn't work.

Looking at the source code for JWM 2.1.0, I see that the <Group><Name> field actually needs to match the application's resource name. Normally that is the same thing as the name of the executable file, but an application can change it. SeaMonkey apparently does. I haven't yet figured out what SeaMonkey changes it to.

So it is time to change tactics. JWM also supports a <Group><Class> field. That field needs to match the application's resource class. Typically that is the same as the executable file name with the first letter capitalized (or sometimes the first two letters, if the first letter is 'x'). But, like the resource name, an application can change it to something else.

Well, "Seamonkey-bin" didn't work for the <Group><Class>, nor did "Seamonkey", but "SeaMonkey" did work.

So perhaps something like this might work for you:

Code: Select all

<Group>                                 
<Class>Firefox</Class>               
<Option>desktop:1</Option>            
</Group>
Something similar might work for you with Dia and Gramps.

tallboy wrote:It says in the description of the function, that it also understand *, but if I use 'dia*' in the code, nothing happens.
I can confirm that this doesn't seem to be working in JWM vsvn-505 either, although JWM vsvn-505 is newer than JWM 2.1.0, the current official release, which corresponds to JWM vsvn-502, and the documentation for JWM 2.1.0 claims that it should support a wild card in the <Group><Name> field.

tallboy wrote:I forgot that one of the first lines in /root/.jwmrc is:

Code: Select all

IMPORTANT, ONLY EDIT /etc/xdg/templates/_root_.jwmrc
Yes, that will also work, since fixmenus reads it and will copy your changes to /root/.jwmrc when it overwrites that file. But if you put your changes in /etc/xdg/templates/_root_.jwmrc, simply restarting JWM isn't enough. You will need to first run fixmenus.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#8 Post by npierce »

Here's a little addendum to my previous post.

If you have a recent Firefox (or a very old one) it should support this command line option: --class

So, in theory, you should be able to do something like this to set the resource class:

Code: Select all

mozilla --class Firefox_d4
or possibly this:

Code: Select all

mozilla --class=Firefox_d4
This option supposedly was supported by Firefox 1.x and 2.x, but was broken in 3.x and for many later versions. After a couple of years and some resistance by a Mozilla developer, users finally convinced another Mozilla developer to fix this bug. (See Mozilla Bugzilla: Bug 496653 - Command line option --class <WM_CLASS> does not work . . . It was fixed in early 2012, and is known to be fixed in Firefox 14.0.1.

I don't have Firefox, so I've not tried this. It doesn't work for SeaMonkey 2.3.1.

(A good document about Mozilla command line options is this: Command Line Options - Mozilla)


Also, I finally found a utility that would tell me the resource name for SeaMonkey. I was disappointed earlier when xwininfo -wm failed to give me that information. But the xprop utility will give this. For instance, try this command, then click in the desired window:

Code: Select all

xprop | grep WM_CLASS
It will display the resource name followed by the resource class.


By the way, SeaMonkey's resource name harkens back to a previous century. What is it? It is "Navigator".

User avatar
tallboy
Posts: 1760
Joined: Tue 21 Sep 2010, 21:56
Location: Drøbak, Norway

#9 Post by tallboy »

npierce wrote:By the way, SeaMonkey's resource name harkens back to a previous century. What is it? It is "Navigator".
And you think Firefox is new, and flashy and modern? Well, not really! :lol:

Code: Select all

# xprop | grep WM_CLASS
WM_CLASS(STRING) = "Navigator", "Firefox"
#
There is obviously some issues with gtk that creates the problems. From bugzilla:
reikred 2012-08-16 11:58:47 PDT

Gentlemen, I have downloaded firefox 14.0.1 and tested the bugfix, and I can report that the bug IS STILL THERE. If I specify --class Firefox2, then I end up with (from xprop in X11)

WM_CLASS(STRING) = "Navigator", "Firefox2"

It should be

WM_CLASS(STRING) = "Firefox2", "Firefox2"

as it was in Firefox 3.x long ago before this bug was introduced.

One interesting thing did happen: The very first time I fired up the new browser (14.0.1 installation), there was initially one window that had the correct WM_CLASS setting.
However, that window disappeared after firefox had checked for old plugins (etc),
and all the new windows popped by firefox (old session starting up) has one wrong value again.

Please note carefully the following: As I have mentioned before in this thread, it is likely nsXULWIndow.cpp that is the cause of new windows getting the "Navigator" moniker rather than the Firefox2 class name that I asked for.

Comment 38 Mike Hommey [:glandium] 2012-08-16 12:13:45 PDT

--class is not supposed to change both the resource name and resource class.

Try, for example, gimp --class foo...

Comment 39 reikred 2012-08-16 14:38:54 PDT

(In reply to Mike Hommey [:glandium] from comment #38 )
> --class is not supposed to change both the resource name and resource class.
>
> Try, for example, gimp --class foo...

Okay, but then the problem is something else, namely that Firefox does not properly implement the GTK standard option called --name=<name>. I should be able to say

firefox --name Firefox2

and get the desired result. To use your example,

gimp --name foo --class bar

does the right thing, as can be seen from running xprop on it:

WM_CLASS(STRING) = "foo", "bar"
I'll look further into the matter, and report back when I make progress. BTW, when dia-nornal opened in another desktop, it did not take focus.

Do you know anything about the numbering of versions/releases of FF? It seem to me they are still talking about 3.6 and 4, and then suddenly 14.0.1?
True freedom is a live Puppy on a multisession CD/DVD.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#10 Post by npierce »

tallboy wrote:And you think Firefox is new, and flashy and modern? Well, not really! :lol:

Code: Select all

# xprop | grep WM_CLASS
WM_CLASS(STRING) = "Navigator", "Firefox"
#
:) Netscape lives! :)

tallboy wrote:There is obviously some issues with gtk . . .
Apparently they weren't supporting some common command line options recommended for GTK+, nor did they support the standard X -name option, or the X RESOURCE_NAME environmental variable -- but then, not many applications support the latter two these days.
On 2012-08-16, reikred wrote:Gentlemen, I have downloaded firefox 14.0.1 and tested the bugfix, and I can report that the bug IS STILL THERE. If I specify --class Firefox2, then I end up with (from xprop in X11)

WM_CLASS(STRING) = "Navigator", "Firefox2"

It should be

WM_CLASS(STRING) = "Firefox2", "Firefox2"
Much as I admire the work reikred did (including coming up with first a workaround and later a patch) to get the bug fixed, I would disagree with the above statement that the bug is still there. If --class changed both the resource class and the resource name in Firefox 1.x and 2.x, I would say that that was a bug. I would agree with Mike Hommey:
On 2012-08-16, Mike Hommey wrote:--class is not supposed to change both the resource name and resource class.

Perhaps Firefox should have an option for changing the resource name, but it doesn't claim to have such an option, and if it did it should be separate from the --class option.

tallboy wrote:Do you know anything about the numbering of versions/releases of FF? It seem to me they are still talking about 3.6 and 4, and then suddenly 14.0.1?
Yes, it seems like major versions 1.x, 2.x, and 3.x each lasted for a couple of years. But more recently they usually don't even last a couple of months.

The index of release notes is here:
Mozilla Firefox Release Notes

Here is a sampling:
Mozilla Firefox 1.0 Release Notes 2004-11-09
Mozilla Firefox 2.0.0.1 Release Notes 2006-12-19
Mozilla Firefox 3.0 Release Notes 2008-06-17
Mozilla Firefox 4.0 Release Notes 2011-03-22
Mozilla Firefox 11.0 Release Notes 2012-03-13
Mozilla Firefox 19.0 Release Notes 2013-02-19


Have you had any luck getting Firefox, Dia, or Gramps to work using the <Group><Class> field as described in the post before my previous post (http://www.murga-linux.com/puppy/viewto ... 605#694605) ?

User avatar
tallboy
Posts: 1760
Joined: Tue 21 Sep 2010, 21:56
Location: Drøbak, Norway

#11 Post by tallboy »

There are some small issues with making a program open in another desktop. As described above, Firefox will also need a class declaration included in the code, even v.19.02 uses the old 'Navigator' and 'Firefox' class declarations. The other programs tested did not have that problem, but opened by using only the 'Name' declaration, see code below. One reason for my previous and partly incorrect claim that it did not work, is that the added programs don't show in the small virtual desktop windows in the tray when only a single program is opened in another desktop. But there are strange exeptions. If you want Abiword to open in another desktop, you can see it appear in the tray desktop window while it opens, all the others remain invisible unless you open one more program; then the tray view is updated. The opening process is also a bit awkward in comparison to fvwm2, which I use in Debian. If you are in, say desktop 1, in jwm the program annoyingly flashes open for an instance in the current desktop before it moves to the intended desktop, in fvwm2 it actually opens in another desktop and immediately update the tray. There may be code in the 'Send To' script used in the window border menu, that could be used to improve that behaviour. As far as I have understood, what we define as a 'desktop', is really a limited part of an infinitely large area, so the 'open' process could take place anywhere.

As it is now, the process of opening a program in another virtual desktop seem a bit underdeveloped, but it works.

The 'Class' used, is a result of running the command

Code: Select all

xprop | grep WM_CLASS
followed by clicking in the window in question. The code added to /root/.jwm/jwmrc-personal, was as follows:

Code: Select all

<Group>
<Class>Firefox</Class>
<Name>Firefox</Name>
<Option>desktop:4</Option>
</Group>

<Group>
<Name>galculator</Name>
<Option>desktop:2</Option>
</Group>

<Group>
<Name>abiword</Name>
<Option>desktop:3</Option>
</Group>

<Group>
<Name>dia-normal</Name>
<Option>desktop:2</Option>
</Group>

<Group>
<Name>gramps.py</Name>
<Option>desktop:3</Option>
</Group>
Note that Gramps is an extremely slow starter.

tallboy
True freedom is a live Puppy on a multisession CD/DVD.

npierce
Posts: 858
Joined: Tue 29 Dec 2009, 01:40

#12 Post by npierce »

npierce wrote:
tallboy wrote:It says in the description of the function, that it also understand *, but if I use 'dia*' in the code, nothing happens.
I can confirm that this doesn't seem to be working in JWM vsvn-505 either, although JWM vsvn-505 is newer than JWM 2.1.0, the current official release, which corresponds to JWM vsvn-502, and the documentation for JWM 2.1.0 claims that it should support a wild card in the <Group><Name> field.
I looked further into this and found a bug in the source code for JWM 2.1.0 (a.k.a. JWM vsvn-502). If the asterisk is at the end of the pattern, the comparison will never find a match. It will work is the asterisk is at the beginning or elsewhere in the pattern, but that doesn't help you if that's not what you want.

I was going to file a bug report and submit a patch to Joe W., but first I looked at the latest source to see if it had been fixed.

It turns out that, in newer versions, Joe has replaced the function containing the bug with calls to some standard C library functions used for regular expression matching ( regcomp(), regexec(), and regfree() ). So the bug is gone.

But now the <Group><Name> and <Group><Class> fields are considered regular expressions. This is very different from what it was before, and is no longer the way it is described in the documentation, which says simply, "A wild card, '*' may be used."

This won't apply to the JWM vsvn-500 that you were using, or the JWM vsvn-505 that I happen to be using at the moment. Those versions still use the asterisk as a simple wild card (except that it has the above-mentioned bug), just as it is used on a bash command line. But newer Puppies, probably any Woof-based Puppies released since Barry compiled JWM version 562 on January 1, 2012, will treat those fields as regular expressions.

This requires using a somewhat more complex pattern.

For instance, with the old way, using foobar in the <Group><Name> field would match a program with the name foobar and only a program with the name foobar. With the new way, foobar will match any name containing that string, such as my_foobar or foobar2. To restrict it to an exact match requires using the regular expression ^foobar$ for the <Group><Name> field.

Also, to use a wild card to match a program name beginning with foo and ending with bar, which would have been foo*bar if done the old way, now would need to be ^foo.*bar$ for the <Group><Name> field.

Of course, regular expressions allow you to do more complex matching, but do require more care in doing simple matching.


Since the newer versions of JWM didn't behave as currently documented, I submitted an "issue" report to Joe W., and he has already fixed it: Group Name and Class fields are now regular expressions, but the documentation hasn't yet been updated.

tallboy wrote:. . . the added programs don't show in the small virtual desktop windows in the tray when only a single program is opened in another desktop. But there are strange exeptions. . . .
Yes. I hadn't noticed that, but now that you mention it, I see the same here (with JWM vsvn-505). Apparently, the pager (the term JWM uses for the small virtual desktop windows in the tray) isn't usually updated when starting programs on another desktop. As you say, there are exceptions. For me, the seamonkey window will appear in the pager when first started, but running seamonkey again (which opens new windows but doesn't start a new instance of the program) doesn't cause any new windows to appear in the pager until some other action causes the pager to be updated.

Now I have installed JWM vgit-704 and am taking it for a test drive. I see that this seems to have been fixed: the pager is updated for any program that I start on another desktop, not just seamonkey.

tallboy wrote:. . . in jwm the program annoyingly flashes open for an instance in the current desktop before it moves to the intended desktop . . .
I also see that with JWM vsvn-505. I can report that with JWM vgit-704 this seems to have been slightly improved. The size of the flash seems to be smaller, but it is still there.


Anyway, even though things don't work quite as smoothly as we would like, I am glad to know that you got the <Group> stuff working.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#13 Post by amigo »

The most portable way to do this would be to use wmctrl as it will work with most WM's and is more commonly found than xdotool, etc.

User avatar
tallboy
Posts: 1760
Joined: Tue 21 Sep 2010, 21:56
Location: Drøbak, Norway

#14 Post by tallboy »

npierce, thank you very much for following up on this theme, lots of useful info here.

amigo, I got the understanding that wmctrl doesn't always agree with jwm, so I haven't followed that path yet, but I will definitely look into it.

tallboy
True freedom is a live Puppy on a multisession CD/DVD.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#15 Post by amigo »

I think JWM still lacks support for some of the standard WM hints which are used nearly everywhere. What does JWM do with a real DockApp?

Post Reply