proposal for an 'appstart' protocol

[Egmont Koblinger]

On Tue, Jan 7, 2020 at 2:01 AM Bruno Haible <bruno at clisp.org> wrote:

> José and I are asking for (C) and (D). (C) is a major feature for GNU
> poke,

An application which I haven't heard of before, and is not shipped by
latest Ubuntu or Fedora.

> and (D) will be a major feature for GNU gettext.

For translators and QA of translations of terminal-based apps, i.e. a
tiny user base.

Mind you, this:

> - An interactive program has a 'help' command that prints
> a set of available commands. When the user selects one of these
> command, the command gets added to the prompt. This reduces
> the amount of necessary typing.

can already be achieved by your application handling mouse events, and
it works even in terminals without support for explicit hyperlinks.

Or, if the app doesn't manage its full screen but rather "just prints"
stuff and lets it scroll out, as e.g. the shell, then your proposal
doesn't say a word what would happen when the link is still visible
(maybe the user even scrolled back) but the application is no longer
running, no longer listening on the given port. Or a different
application started to listen there.

Or can be done currently by selecting the word with double-clicking,
and pasting with middle-click or Shift+insert or alike. However, those
who want real efficiency would probably ask for TAB autocompletion or
other keyboard-based approach, rather than having to reach out to the
mouse.


The things you propose here might be great for in-house hacks where
security and robustness don't matter; but are nowhere near to, and
conceptually start in the wrong direction to become standardizable,
shippable and widely usable.

I'm not sure if you'll require any buy-in from either the hyperlink
specification, or from its implementations in terminals. Maybe you
don't, because an app can already register an appfoo:// URL-handler in
e.g. GNOME, and another app might emit these in the terminal, and then
gnome-terminal will automagically open these for you. If that's the
case, I personally couldn't care less what protocols you invent for
yourself. But if you require any buy-in from the hyperlink spec or
from vte/gnome-terminal, you definitely won't get mine in this current
direction. What you propose suffers from so many conceptual problems,
including but not limited to the utter lack of security that you
haven't responded to, that it just can't be taken seriously.

I'd love to hear how much of your problems would the line number
feature (if done correctly) solve, and whether you're interested in
implementing that according to the approach I outlined (involving
convincing the desktop spec to add a new field, apps to start shipping
desktop files that use that feature, and new convenience methods
implemented by GTK and friends).


e.