Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Wed 26 Nov 2014, 12:35
All times are UTC - 4
 Forum index » House Training » Users ( For the regulars )
start program in another window? (alt-2 alt1)
Moderators: Flash, Ian, JohnMurga
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 1 of 1 Posts_count  
Author Message
divisionmd


Joined: 14 Jul 2007
Posts: 606

PostPosted: Fri 22 Mar 2013, 07:32    Post_subject:  start program in another window? (alt-2 alt1)  

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
Back to top
View user's profile Send_private_message MSNM 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Sat 23 Mar 2013, 14:18    Post_subject:  

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:
<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:
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:
#!/bin/bash
yourprogname_d1 &


[EDITED, 2013-Mar-24 to suggest a better configuration file to use.]

Edited_time_total
Back to top
View user's profile Send_private_message 
tallboy


Joined: 21 Sep 2010
Posts: 449
Location: Oslo, Norway

PostPosted: Sun 24 Mar 2013, 05:04    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Sun 24 Mar 2013, 08:59    Post_subject:  

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:
<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
Back to top
View user's profile Send_private_message 
tallboy


Joined: 21 Sep 2010
Posts: 449
Location: Oslo, Norway

PostPosted: Sun 24 Mar 2013, 12:46    Post_subject:  

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

I forgot that one of the first lines in /root/.jwmrc is:
Code:
IMPORTANT, ONLY EDIT /etc/xdg/templates/_root_.jwmrc
Embarassed

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.
Back to top
View user's profile Send_private_message 
divisionmd


Joined: 14 Jul 2007
Posts: 606

PostPosted: Mon 25 Mar 2013, 14:51    Post_subject:  

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
Back to top
View user's profile Send_private_message MSNM 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Mon 25 Mar 2013, 16:22    Post_subject:  

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

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:
<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:
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.
Back to top
View user's profile Send_private_message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Mon 25 Mar 2013, 19:59    Post_subject:  

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:
mozilla --class Firefox_d4

or possibly this:
Code:
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:
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".
Back to top
View user's profile Send_private_message 
tallboy


Joined: 21 Sep 2010
Posts: 449
Location: Oslo, Norway

PostPosted: Mon 25 Mar 2013, 21:20    Post_subject:  

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! Laughing
Code:
# xprop | grep WM_CLASS
WM_CLASS(STRING) = "Navigator", "Firefox"
#


There is obviously some issues with gtk that creates the problems. From bugzilla:
Quote:

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.
Back to top
View user's profile Send_private_message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Tue 26 Mar 2013, 00:22    Post_subject:  

tallboy wrote:
And you think Firefox is new, and flashy and modern? Well, not really! Laughing
Code:
# xprop | grep WM_CLASS
WM_CLASS(STRING) = "Navigator", "Firefox"
#

Smile Netscape lives! Smile


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/viewtopic.php?p=694605#694605) ?
Back to top
View user's profile Send_private_message 
tallboy


Joined: 21 Sep 2010
Posts: 449
Location: Oslo, Norway

PostPosted: Fri 29 Mar 2013, 23:41    Post_subject:  

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:
xprop | grep WM_CLASS
followed by clicking in the window in question. The code added to /root/.jwm/jwmrc-personal, was as follows:
Code:
<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.
Back to top
View user's profile Send_private_message 
npierce

Joined: 28 Dec 2009
Posts: 858

PostPosted: Mon 01 Apr 2013, 11:47    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
amigo

Joined: 02 Apr 2007
Posts: 2278

PostPosted: Mon 01 Apr 2013, 12:35    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
tallboy


Joined: 21 Sep 2010
Posts: 449
Location: Oslo, Norway

PostPosted: Mon 01 Apr 2013, 14:16    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
amigo

Joined: 02 Apr 2007
Posts: 2278

PostPosted: Tue 02 Apr 2013, 11:16    Post_subject:  

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?
Back to top
View user's profile Send_private_message 
Display_posts:   Sort by:   
Page 1 of 1 Posts_count  
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » House Training » Users ( For the regulars )
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1486s ][ Queries: 12 (0.0062s) ][ GZIP on ]