On 26 Oct 2004 14:21:56 +0200, Rafal Bisingier wrote:
>
> On Tue, Oct 26, 2004 at 10:10:16AM +0200, Dominik Vogt wrote:
> > On Thu, Oct 21, 2004 at 10:58:40AM +0200, Rafal Bisingier wrote:
> > > >
> > > > On Wed, 20 Oct 2004, Rafal Bisingier wrote:
> > > >
> > > > >I've found a problem with selecting windows which
> > > > >name/res/class/icon contains a literal *.
> > > > >I've looked in the source code, and if I understand it function
> > > > >matchWildcards from libs/wild.c use every * as a wildcard, so
> > > > >there is no chance to match only a literal *.
> > > > >I think I can patch it to use ** as a literal *, but I'm not
> > > > >sure if it's a good way of resolving this problem.
> >
> > We recently had a discussion about qouting of window titles.
> > Mikhael came up with with a suggestion to solve it by enhancing
> > $[...] expansion. Maybe someone can look up the thread in the
> > list archives.
>
> I've found a thread "CVS scott: Apply conditionals patch." from July in
> which this (and couple of other, even more serious) problem has been discussed,
> but this thread ended with Mikhael's suggestion:
> <cite>
> I think the current syntax of non-option names should not be the main
> one in the long run. How about to solve the whole issue correctly by
> introducing the following options in conditions:
> Name "pattern", IconName "pattern", Class "pattern", Resource "pattern",
> AnyName "pattern"
> All of these will support special pattern characters including "|".
> The non-option names are still supported, but there is a better syntax.
> And we still need the variable filters like $[var:pattern], and
> quoting syntax for names in conditions; "||", "**" and "??" is ok by me.
> </cite>
>
> I can implement "||", "**" and "??" part (it should be simple), but I
> want to know if there is a chance to inclusion of this patch into to
> fvwm (this is my original question as you can see above)?
I think someone else wanted to implement the OR syntax, i.e. "|", I have
no idea what is the status of this.
The first step (that you can do) is to handle the specified doubled chars
as escaped char rather than meta-chars in conditions. And implement one
filter "pattern" that quotes variables in order to be used in commands
that require patterns. I.e. Next ($[w.name:pattern], !Iconified) ...
If you are at it, you may implement other suggested filters, but please
test this thoroufully if you do it.
> It'll be good to implement also the proposed syntax for selecting window
> exclusivly by it's class, resource, icon name or title, but I'm not
> sure if I have enough skill to do it.
> And there's still a problem with backward compatibility of this new
> syntax. Can we just leave existing syntax as is, and add only the new
> options? I know it can break backward compatibility in some (I think
> rare) cases when one want to select window named for ex: "Name" or
> "Resource", but in this cases there will always be posibility to use the
> new option AnyName.
I don't think that Name/IconName/Class/Resource/AnyName should be
done before 2.6.
> PS. I know I'm a little boring with this, but some time ago I've send a
> patch adding new Test option... ;-)
I guess, noone had a time to look at it yet. fvwm-workers should be a
better place for these discussions.
Regards,
Mikhael.
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Tue Oct 26 2004 - 08:33:46 BST