run_scaled: support passing arguments to Xpra

[dancek]

I needed to pass some arguments to Xpra when running Wine software with run_scaled. I think this might have other use cases than mine, so I added support for passing generic extra arguments.

While I was at it, I fixed a bug in the manpage.

[totaam]

Thanks!
I think it would be nicer if instead of using --xpra-arg=, the parsing just looked for -- in the arguments and if found then it could just pass on any arguments before it to xpra and those after it to the real command.

[dancek]

I actually considered that.

Considering the UI of run_scaled, I'd find it confusing because run_scaled is basically a wrapper around an X application. It also wraps Xpra, but a user won't think of Xpra when they write run_scaled some_application. And since it's conventional to pass arguments after -- to the wrapped software, it would feel like run_scaled some_application -- --param would call some_application --param.

Another point is that running applications that themselves expect the -- separating argument would be difficult to call if run_scaled itself used that.

Now, if --xpra-arg= sounds like a bad idea, I'd consider something like XPRA_ARGS="--arg1 --arg2" run_scaled some_application instead. Is that better?

[dancek]

Still, if you do consider the -- separator to be the best approach just say so and I'll implement that 👍

[totaam]

Another point is that running applications that themselves expect the -- separating argument would be difficult to call if run_scaled itself used that.

In that case, you must specify it before theapp.
run_scaled -- theapp -- --whatever

Still, if you do consider the -- separator to be the best approach just say so and I'll implement that

I do. Sorry for the extra work!
It just feels cleaner. Being a single argument, --xpra-arg= could get messy with nested quoting.
As for XPRA_ARGS=, I've already overused environment variables in xpra!

[dancek]

I implemented the -- separator and force-pushed the changed commits. (I think it's cleaner not to have a wrong implementation in git history.)

In that case, you must specify it before theapp. run_scaled -- theapp -- --whatever

This won't work in my implementation. But hopefully no one needs it.

[totaam]

This will pass arguments after -- to xpra and does not take into account he possibility that there might be more than one -- in the command line.
I'll take a stab at it later today.

[dancek]

The Github web UI is down for me right now, but I can probably comment with email too? I slept on this and I think the reasonable way to do it is to split on the last `--` instance. I wrote that and pushed the commit. Now with something like ``` run_scaled --scale=1.5 someapp --arg -- --more-args -- other-stuff -- --xpra-arg ``` the command to run is `someapp --arg -- --more-args -- other-stuff`. This looks workable to me, though not very intuitive.

…

On Fri, 15 Oct 2021 at 08:06, Antoine Martin ***@***.***> wrote: @totaam commented on this pull request. ________________________________ In fs/bin/run_scaled: > scale = parse_scale(x[len("--scale="):]) + elif x == "--": + extra_xpra_args = sys.argv[i+2:] This will pass arguments after -- to xpra and does not take into account he possibility that there might be more than one -- in the command line. I'll take a stab at it later today. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

-- Hannu Hartikainen

[totaam]

I would prefer splitting on the first arg, that way you never end up with a command with -- right at the end, which is what you would need to use if there was another -- used by the app.
ie:

run_scaled --scale=1.5 -- someapp -- --someapp-arg

is much nicer than:

run_scaled --scale=1.5 someapp -- --someapp-arg --

Also it keeps the xpra args, including --scale, all on one side. The side that has run_scaled.
So when you do:

run_scaled --dpi=96 --scale=1.5 --title=hello -- someapp --someapp-arg

It's easier to see which arguments go where.
When you split at the end, you have to mentally re-assemble them from either side.

[dancek]

That would require everyone to always use --, wouldn't it? Or we could just pass all non-recognized arguments starting with - to Xpra and consider the first argument that starts with something else to be the start of the command. In which case we don't really need -- for anything?

[totaam]

That would require everyone to always use --, wouldn't it?

No. -- would only be required if either:

• the application uses it
• one wants to specify arguments for xpra

Existing users would not need to modify their existing command lines at all, which is important.

[dancek]

Right. But why not just allow

run_scaled --dpi=96 --scale=1.5 --title=hello someapp --someapp-arg

where --scale=1.5 is an argument handled by run_scaled, --dpi=96 and --title=hello are passed to Xpra, and the command is someapp --someapp-arg?

Anyway, I'll implement it either way later.

[dancek]

run_scaled --dpi=96 --scale=1.5 --title=hello -- someapp --someapp-arg

This works now.