I see three more possible problems:
- There might already be some applications that implement those names.
After DEs implement this, the apps would be recognized as terminals.
- DEs not supporting the updated spec would allow user to trigger those
actions, even though they cannot substitute the placeholder.
- Do we want to explicitly sanction window–tab paradigm for
terminals? There are apps that do not subscribe to this view (e.g.
Tilix) and these actions would not make sense to them.
The first two can be fixed by choosing a different section names (e.g.
Standardized Desktop Action).
Actually, we might want to namespace the actions using reverse domain
name to allow vendors to test their new experimental actions before
proposing them to Freedesktop.
On Fri, 31 Aug, 2018 at 2:46 PM, PCMan <[email protected]> wrote:
Hello,
Just took a look at xdg-terminal-exec and I liked the idea.
Actually I figured out something similar previously but did not write
any code.
There is, however, one thing I'd like to propose to make the spec
more complete.
Use the Desktop Entry Actions.
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#extra-actions
Then, for each desktop entry file of a terminal emulator, we define
some standard actions:
* OpenDirInWindow: a command to open a dir in a new tab
* OpenDirInTab: a command to open a dir in a new tab
* ExecInWindow: a command to run a program in a new window
* ExecInTab: a command to run a program in a new tab
When the "InTab" actions are not defined in the desktop entry file,
fallback to the "InWindow" version.
This should cover most of the common operations when we need a
terminal window.
For example, we can write xterm.desktop like this
[Desktop Entry]
Name=Gnome Terminal
Exec=gnome-terminal
Actions=OpenDirInWindow;
[Desktop Action OpenDirInWindow]
Name=Open Directory in Terminal
Exec=gnome-terminal --window --working-directory %f
[Desktop Action OpenDirInTab]
Name=Open Directory in Terminal
Exec=gnome-terminal --tab --working-directory %f
[Desktop Action ExecInWindow]
Name=Execute in Terminal
Exec=gnome-terminal -e %f
In this way, we reuse the existing spec and support various kinds of
operations.
The only drawback is %f means a file name, but what we need to pass to
the terminal emulator is actually a full command line with args.
Just my two cents.
On Thu, Aug 30, 2018 at 3:36 PM Vladimir Kudrya
<[email protected]> wrote:
Couple of notes.
xdg-terminal-exec in its current form is a minimum intervention
solution: you need to place desktop files for some terminals, then
use
xdg-terminal-exec itself as a command to launch terminal.
ArgPrefix has a solid generic use case: there was a bug in
Ocrfeeder:
https://bugzilla.gnome.org/show_bug.cgi?id=767732 It required an
argument to open file, but no argument to just launch the app.
Current
desktop entry spec can not handle this via single desktop entry.
I'll try to sum up, simplify, and build upon Jan's and Ian's
proposals.
Fields for destop entries:
MimeType: what app can open
MimeTypeView: what app can open for viewing
MimeTypeEdit: what app can open for edit
Intent: what actions app represents (analogous to MimeType, like:
x-intent/terminal, x-intent/increase-brightness.) Choosing goes
alongside mimetypes and schemes into mimeapps.list hierarchy.
ArgPrefix: argument(s) to be added to the beginning of command line
if
there are other arguments provided.
With all above:
xdg-open some.file: current behavior
xdg-open --edit some.file: uses MimeTypeEdit choices.
xdg-open --view some.file: uses MimeTypeView choices.
xdg-intent terminal: opens terminal.
xdg-intent termianl foo --bar: runs foo --bar in chosen terminal,
using
ArgPrefix if needed. IMHO one of the few intents that would ever
require
arguments.
This strategy is backward-compatible, uses same data and config
hierarchies, works without dbus (I don't want to touch it even with
ten
meter stick), 'xdg-intent terminal' can be used as drop in for
terminal
emulators. (xdg-terminal as wrapper to get rid of that space?).
_______________________________________________
xdg mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/xdg
_______________________________________________
xdg mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/xdg
_______________________________________________
xdg mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/xdg
