Re: [PATCHES] Add command 'query'

[Tyler Thomas Hart <htyler _at_ pdx _dot_ edu>]

> So here it is: The Object-Tree! It won't stay a tree; actually it has
> the structure of a filesystem with symlinks. You can use the command
> object_tree and attr to explore the objects:

Thanks Thorsten for this. It is definitely a better solution to what query
was trying to implement.

>     <snip>
> This tells if you are currently on the first or second tag. If yes it
> also prints the name of the current tag. I think I implemented all your
> "query_binds" as attributes of the suitable objects (e.g. ntags as
> tags.count) and described them in the man page[1]. If you think there's
> something missing, please ask.

This is good. As far as readily-available attributes, I'll have to experiment
with my 'herbstlogic' script some more to see if there are any more attributes
that could be included for my uses. A couple things not a part of my original
query patchset come to mind though:

The first frame-index, ie, knowing what frame is selected. This is tricky,
because of the tree structure. If we were to provide an attribute to the
current-selected frame, should we use a string akin to the index that rules
use? ie. "011"? or a 'flat' index (just an int)? Both would be useful...
although a 'flat' index would be counterintuitive, imo, comparing ints is just,
well, easier.

The second one is: would it be viable to provide attributes for environment
variables? In particular, I would use it to substitute variables with the
'substitute' command (which, for my uses, would be very useful, for example,
comparing an attribute to an envvar). 'getenv' and 'setenv' could be
depreciated/redundant due to these more general methods, and I suspect there
are other uses as well.




And heres another question, but only tangentially related to this topic:

For anyone who isn't familiar with my herbstlogic idea, here's a brief: hlwm
somewhat supports client-side scripting, by way of chain/and/or/!. My idea is
to write a translator that takes a script of hlwm commands written in a familiar
syntax, and translate them to a single chain of nested chain/and/or/!'s to create
a decision tree. By binding keys (and in the future, aliases) to these one-liners,
you are essentially scripting hlwm internally.

For herbstlogic to have an intuitive syntax it should fully support if...then...else
statements. This is ALMOST supported with the current chain operators:

if CMD1 then CMD2 else CMD3 ~= (CMD1 && CMD2) || CMD3

The problem is that if CMD1=true and CMD2=false, CMD3 still executes. This was a
problem in my original query-swap script on arch BBS.

The solution is to 'cast' CMD2 to always return true. The ideal solution, imo, is
to create wrapper commands 'true CMD' and 'false CMD' to do this. I already have
a branch which implements this. If this isn't implemented, however, a workaround
is this:

CMD2 = chain , CMD2 , true

where 'true' is a command that always returns 0 (eg. 'list_foo')

My question is, should 'true CMD' and 'false CMD' be implemented if there already
exists a viable workaround? Again, perhaps not, because of the argument that 'hlwm
shouldn't support explicit server-side-scripting', but it would only add ~10 lines
of code... (we could even the completion factions for '!')

I guess the REAL question I should be asking is: can anyone think of any use-cases
for 'true CMD' and 'false CMD' besides my example?


Thanks for the hard work Thorsten


Tylo