pdcontrol updates

[porres]

1st commit ( 036fe41 ) closes #803
2nd commit ( f4816e9 ) closes #819
commits 31d2931 and 31d2931 close #1027
8ed7ee6 closes #928

[porres]

I see many applications of the commit f4816e9 . I think it's a more powerful/configurable alternative solution to the key issue in #570 but it can also be used for other things, like filtering out mouse events from [cyclone/mousestate] for instance

[Lucarda]

@porres could you prepend an atom to the output of [version(

so we get:

print: list version 0 54 4

And we can use a [route version]

What do you think?

EDIT: no forget it it's no a good idea. :)

[porres]

yeah, in order to use [route version] we need the output to start with 'version' instead of list, and [pdcontrol] doesn't really send tagged data to tell you what you asked for, so it'd be a special case as an odd one out. I guess the idea is that you know what you're asking to [pdcontrol] so you know what you're getting. And if you want different things from [pdcontrol] you have to use more than one.

[umlaeute]

i agree with @porres.
[pdcontrol] is a design nightmare, but the intended use for querying a version is to use an other instance of [pdcontrol] than for querying e.g. the path

[porres]

as long as this doesn't have conflicts, I can update the help file later, I'm always strugglng on solving conflicts :(

[porres]

as long as this doesn't have conflicts, I can update the help file later, I'm always strugglng on solving conflicts :(

yeah, with all the doc updates I did I'm having to solve many conflicts in lots of old PRs of mine. I don't know why this now fails in one of the checks, same thing happened to another PR but not all... I just put the original help file from master and didn't change the code

[Ant1r]

The CI check_file_permissions output is pretty clear:

src/x_gui.c
Data files should never have the EXECUTABLE BIT set!

[porres]

sorry I didn't read it :/ I was just surprised that I hadn't touched the code, but then, maybe this check was added later and my old mistake just wasn't caught before ;) there's also another error on another PR that I made the same conflict resolving but read the error and it wasn't this at all... so that remains a mystery.

thanks