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.