A spec to set default terminal applications?

[Ian Huang]

Hello, I'm just a regular GNOME user, but I recently stumbled across an
issue <https://gitlab.gnome.org/GNOME/glib/issues/338> on GitLab that
brought up the concern that there seems to be no good way at the moment to
specify the default terminal to handle applications with the Terminal=true
field in their desktop files. GLib, for example, is hardcoded to use
gnome-terminal at the moment because no MIME type exists for this type of
function.

Anyway, it was brought up—both in the issue and on GNOME's IRC—that a MIME
type for terminal emulators (@borschty proposed something like
x-task/terminal) in the specification would make things a bit easier. Or
maybe there's a better way to do this using another method. All I know is
that having GLib and alternatives come up with their own way to set the
terminal seems to be a bit inconsistent and sloppy compared to the way in
which, say, URI handlers are chosen.

Thanks for the consideration,
Ian Huang (imyxh)

[Jan Tojnar]

I would like to add that this looks like an omission in the Desktop
Entry Specification, since the Terminal key is only described as

Whether the program runs in a terminal window. [1]

but it is not clear what does that mean. The specification should
clarify, link to another specification, or, in the worst case,
explicitly say that it is implementation dependent.

–Jan

[1]:
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.2.html#key-terminal

[Jan Tojnar]

Apparently, this has already been discussed in 2015

https://lists.freedesktop.org/archives/xdg/2015-October/013583.html

however, it seems to have fizzled out.

[Vladimir Kudrya]

_______________________________________________
xdg mailing list
***@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

[Ian Huang]

https://github.com/Vladimir-csp/xdg-terminal-exec/

I like this proposal a lot, but it seems to me to be a little inconsistent
with the selection of other default handlers. Mostly just because it would
require a second desktop file for each application to put under the
xdg-terminals/ directory. Though I'm no X developer, I also can't think of
a cleaner way to do this, so I think it should be considered again.

There's a MIME type for a shell script, which seems appropriate?

I also don't think using the existing shell script MIME
type makes sense . . . not all applications that run in terminals are shell
scripts, and it would seem to be more appropriate to reserve such a MIME
type to serve as only the shell-language equivalent type of, say, Python
scripts.

Ultimately, I think if the solution is to use a MIME type, I think it
should be a dummy one that assigns a terminal as its handler but does not
have actual files with the type. Such a decision would be to avoid the
terminal being the default handler for existing files, since really what we
want to do (as far as I understand) is to open .desktop files of type
text/plain and not shell scripts. Unless you want to make a new type
specifically for .desktop files that have Terminal=true selected. . . .

[Vladimir Kudrya]

_______________________________________________
xdg mailing list
***@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

[Ian Huang]

No, it is just for terminals themselves.

I know, by "application" I meant the terminal apps themselves not the apps
that run inside them as you pointed out. At the time I thought it could be
a little troublesome, but the more I've looked into it the more I'm
thinking patching install scripts to symlink a desktop file as you
specified is a pretty clean way to do it.

I think I also agree about the MIME types being a poor idea. Terminals
differ so much from other handlers in the way that you pointed out that it
would really be an abuse of the MIME system.

One last point to keep in mind: I think it would be wonderful if your spec
(or whatever is decided upon) could be easily expanded to include other
types of default applications unsuitable to the MINE system. For example,
many keyboards have a calculator function button that I believe is hard
coded to use GNOME's calculator for me at the moment. Similar apps that
don't necessarily handle a single type of file but reasonably call for a
default choice could maybe share the same spec? Might be a little out of
scope, though. You tell me.

Mostly just because it would require a second desktop file for each
application to put under the xdg-terminals/ directory.
No, it is just for terminals themselves.
Ultimately, I think if the solution is to use a MIME type, I think it
should be a dummy one that assigns a terminal as its handler but does not
have actual files with the type.
I'd advise against dragging MIME associations into this case because it
isn't an association of an application with filetype/protocol to open in,
but a matter of how an executable will be executed.

[Vladimir Kudrya]

That's an interesting area. For example, XFCE has generalizations like
web browser, email client facilitated by their own reinvented wheel
inside exo-open AFAIK.
I found a way to do some without any special treatment: I have a bind in
Openbox to open browser and mail client set up like 'xdg-open http://'.
But it does not work well for mailto: and there is no scheme for
calculators.
Another related function: backlight. How to generalize between
xbacklight or brightnessctl depending on hardware support.

To sum it up, this is another class of tasks, not to open something in
something, but to execute something. Intents? x-intent/email-client,
x-intent/reduce-backlight? Generalize xdg-terminal-exec into
xdg-intent-exec? X-ExecArg into X-ArgPrefix? What do you think?

For example, many keyboards have a calculator function button that I
believe is hard coded to use GNOME's calculator for me at the moment.
Similar apps that don't necessarily handle a single type of file but
reasonably call for a default choice could maybe share the same spec?

[Ian Huang]

Hey, that's a thought. Something like an intent system sounds perfect to
categorize these actions. And then desktops could stop abusing the MIME
system
or gconf or hardcoding
for these things.
Somebody's got to bring up that we could take the easy way out and have
x-intent/ be a whole category of dummy MIME types, but that doesn't really
fix the concern about inconsistent CLI arguments, so once again I doubt it
would be the right choice.


So yes, I think generalizing your xdg-terminal-exec proposal into a new
system for intents would be great. Off the top of my head, one way would be
that the directories could be restructured to have xdg-intents directories
(instead of xdg-terminals of course) with subdirectories carrying the names
of the intents, like ~/.local/share/xdg-intents/terminals/ for instance.


You could also structure the config .list files in the same matter. But
there might be a better way, it's kind of trivial how you should structure
this.

Post by Vladimir Kudrya
That's an interesting area. For example, XFCE has generalizations like
web browser, email client facilitated by their own reinvented wheel
inside exo-open AFAIK.
I found a way to do some without any special treatment: I have a bind in
Openbox to open browser and mail client set up like 'xdg-open http://'.
But it does not work well for mailto: and there is no scheme for
calculators.
Another related function: backlight. How to generalize between
xbacklight or brightnessctl depending on hardware support.
To sum it up, this is another class of tasks, not to open something in
something, but to execute something. Intents? x-intent/email-client,
x-intent/reduce-backlight? Generalize xdg-terminal-exec into
xdg-intent-exec? X-ExecArg into X-ArgPrefix? What do you think?

For example, many keyboards have a calculator function button that I
believe is hard coded to use GNOME's calculator for me at the moment.
Similar apps that don't necessarily handle a single type of file but
reasonably call for a default choice could maybe share the same spec?

[Jan Tojnar]

For what it’s worth, there already was a quite nice Intents proposal
[1]. Android Intents [2] might be interesting as well.

[1]: https://lists.freedesktop.org/archives/xdg/2014-January/013068.html
[2]: https://developer.android.com/reference/android/content/Intent

Post by Ian Huang
Hey, that's a thought. Something like an intent system sounds perfect
to categorize these actions. And then desktops could stop abusing the
MIME system or gconf or hardcoding for these things. Somebody's got
to bring up that we could take the easy way out and have x-intent/ be
a whole category of dummy MIME types, but that doesn't really fix the
concern about inconsistent CLI arguments, so once again I doubt it
would be the right choice.
So yes, I think generalizing your xdg-terminal-exec proposal into a
new system for intents would be great. Off the top of my head, one
way would be that the directories could be restructured to have
xdg-intents directories (instead of xdg-terminals of course) with
subdirectories carrying the names of the intents, like
~/.local/share/xdg-intents/terminals/ for instance.
You could also structure the config .list files in the same matter.
But there might be a better way, it's kind of trivial how you should
structure this.

Post by Vladimir Kudrya
That's an interesting area. For example, XFCE has generalizations like
web browser, email client facilitated by their own reinvented wheel
inside exo-open AFAIK.
I found a way to do some without any special treatment: I have a bind in
Openbox to open browser and mail client set up like 'xdg-open
http://'.
But it does not work well for mailto: and there is no scheme for
calculators.
Another related function: backlight. How to generalize between
xbacklight or brightnessctl depending on hardware support.
To sum it up, this is another class of tasks, not to open something in
something, but to execute something. Intents? x-intent/email-client,
x-intent/reduce-backlight? Generalize xdg-terminal-exec into
xdg-intent-exec? X-ExecArg into X-ArgPrefix? What do you think?

For example, many keyboards have a calculator function button that

I

believe is hard coded to use GNOME's calculator for me at the

moment.

Similar apps that don't necessarily handle a single type of file

but

reasonably call for a default choice could maybe share the same

spec?

[Ian Huang]

Huh, good find. I was about to type up an email about how the "Implements="
key
that was added after that proposal is kind of useless in our case; as it
says,
"it is entirely up to the entity who defined a particular interface to
define
what it means to implement it." But then I realized that we can actually
use it
quite easily in addition to the proposed xdg-terminal-exec or
xdg-intent-exec
spec to avoid the need for duplicate desktop files for intent handlers.

It could work like this:
1. The X-ExecArg option (or X-ArgPrefix) in the proposed spec is moved from
the
"data" directories with desktop files to part of the .list "config"
files;
2. the concept of "data" directories (the ones full of .desktop files) can
be
left out;
3. terminals and other applications that open intents are instructed to have
certain values in the Implements key, for example "Implements=xdg-intent-
terminal" or "Implements=xdg-intent-calculator";
4. when we scan through the .list config files, instead of running the
matching
app in the data directories, we check that the matching .desktop file in
the
usual place (/usr/share/applications/ or ~/.local/share/applications or
whatever) has the correct intent named in the Implements= key;
5. we just run that desktop file with the ArgPrefix specified in the .list.

It's only a little cleaner, though. Thoughts?

[Jan Tojnar]

Relying on `Implements=` key should work, though I think the
`ArgPrefix` should be part of the desktop file itself – it will be
static and defined by the vendor. Also for the system to be efficient,
DEs would want to add something like PCMan’s cache mentioned in the
intents mail.

However, since `Implements=` is supposed to contain D-Bus interfaces
[1], I would like to propose an alternative solution. We could define
`org.freedesktop.TerminalEmulator` interface containing `Execute`
method. This could be modelled after `org.freedesktop.Application` from
D-Bus Activation section of desktop-entry-spec [2].

Similarly, there would be `org.freedesktop.Editor` interface containing
`Edit` method, representing *Edit* intent, dual to the
`org.freedesktop.Application`’s `Open` method, which would be
interpreted as default *View* intent.

This would require modification of the programs but would offer a
standard replacement to fiddling with the CLI flags. Since modern
applications already should be D-Bus-activatable, it should be fairly
simple addition (and most of the code would be handled by GLib or Qt
anyway).

[1]:
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.2.html#interfaces
[2]:
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.2.html#dbus

Post by Ian Huang
Huh, good find. I was about to type up an email about how the
"Implements=" key
that was added after that proposal is kind of useless in our case; as
it says,
"it is entirely up to the entity who defined a particular interface
to define
what it means to implement it." But then I realized that we can
actually use it
quite easily in addition to the proposed xdg-terminal-exec or
xdg-intent-exec
spec to avoid the need for duplicate desktop files for intent
handlers.
1. The X-ExecArg option (or X-ArgPrefix) in the proposed spec is
moved from the
"data" directories with desktop files to part of the .list
"config" files;
2. the concept of "data" directories (the ones full of .desktop
files) can be
left out;
3. terminals and other applications that open intents are instructed to have
certain values in the Implements key, for example
"Implements=xdg-intent-
terminal" or "Implements=xdg-intent-calculator";
4. when we scan through the .list config files, instead of running
the matching
app in the data directories, we check that the matching .desktop
file in the
usual place (/usr/share/applications/ or
~/.local/share/applications or
whatever) has the correct intent named in the Implements= key;
5. we just run that desktop file with the ArgPrefix specified in the .list.
It's only a little cleaner, though. Thoughts?

[Vladimir Kudrya]

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?).

[PCMan]

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.

Post by Vladimir Kudrya
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.
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.
MimeType: what app can open
MimeTypeView: what app can open for viewing
MimeTypeEdit: what app can open for edit
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.
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
https://lists.freedesktop.org/mailman/listinfo/xdg

[PCMan]

Hi again,
There is another way to make this xdg terminal exec stuff more
standard compliant by reusing XDG menu spec.
https://specifications.freedesktop.org/menu-spec/latest/apas02.html
We can parse all desktop entry files and collect every one with
Category=TerminalEmulator to generate a list of terminal emulators.
This way we don't have to manually maintain a terminal.list file.
Of course parsing all of the *.desktop files is slow so we will need
something like "update-mime-database" to generate the list.

To provide desktop entry files for those apps which are not shipped
with their own, we can install desktop files for them.
set XDG_DATA_DIRS=/usr/share/terminal-emulators:$XDG_DATA_DIRS

And just add our own desktop entry files in
/usr/share/terminal-emulators/*.desktop for those terminals which do
not have desktop entries.
So we don't need to invent another spec to manage the terminals.

Regards

Post by Ian Huang
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
* 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.

Post by Vladimir Kudrya
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.
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.
MimeType: what app can open
MimeTypeView: what app can open for viewing
MimeTypeEdit: what app can open for edit
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.
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
https://lists.freedesktop.org/mailman/listinfo/xdg

[Jan Tojnar]

Reusing `Categories` key would be nice, but we would still need
`category-defaults.list` for actually choosing the default representant
for each category, would not we?

Caching is a good point, we would need to create some mechanism no
matter which solution we choose – for instance, if some of the
actions were optional, they would probably need to be cached as well.

Post by PCMan
Hi again,
There is another way to make this xdg terminal exec stuff more
standard compliant by reusing XDG menu spec.
https://specifications.freedesktop.org/menu-spec/latest/apas02.html
We can parse all desktop entry files and collect every one with
Category=TerminalEmulator to generate a list of terminal emulators.
This way we don't have to manually maintain a terminal.list file.
Of course parsing all of the *.desktop files is slow so we will need
something like "update-mime-database" to generate the list.
To provide desktop entry files for those apps which are not shipped
with their own, we can install desktop files for them.
set XDG_DATA_DIRS=/usr/share/terminal-emulators:$XDG_DATA_DIRS
And just add our own desktop entry files in
/usr/share/terminal-emulators/*.desktop for those terminals which do
not have desktop entries.
So we don't need to invent another spec to manage the terminals.
Regards

Post by Ian Huang
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
* 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

Post by Vladimir Kudrya
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

Post by Vladimir Kudrya
xdg-terminal-exec itself as a command to launch terminal.
ArgPrefix has a solid generic use case: there was a bug in
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

Post by Vladimir Kudrya
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.

Post by Vladimir Kudrya
MimeType: what app can open
MimeTypeView: what app can open for viewing
MimeTypeEdit: what app can open for edit
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

Post by Vladimir Kudrya
there are other arguments provided.
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

Post by Vladimir Kudrya
ArgPrefix if needed. IMHO one of the few intents that would ever

require

Post by Vladimir Kudrya
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

Post by Vladimir Kudrya
meter stick), 'xdg-intent terminal' can be used as drop in for

terminal

Post by Vladimir Kudrya
emulators. (xdg-terminal as wrapper to get rid of that space?).
_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg

[Jan Tojnar]

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.

Post by Ian Huang
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
* 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

Post by Vladimir Kudrya
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
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.
MimeType: what app can open
MimeTypeView: what app can open for viewing
MimeTypeEdit: what app can open for edit
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.
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
https://lists.freedesktop.org/mailman/listinfo/xdg

_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg

[Liam R E Quin]

Anyway, it was brought up—both in the issue and on GNOME's IRC—that a
MIME
x-task/terminal) in the specification would make things a bit easier.

There's a MIME type for a shell script, which seems appropriate?


Liam (IRC::ankh)

[Philipp A.]

I have my shell script mime types associated with my text editor, not my
terminal emulator.

Post by Liam R E Quin

Post by Ian Huang
Anyway, it was brought up—both in the issue and on GNOME's IRC—that a MIME
x-task/terminal) in the specification would make things a bit easier.

There's a MIME type for a shell script, which seems appropriate?
Liam (IRC::ankh)
--
Liam Quin - web slave for https://www.fromoldbooks.org/
with fabulous vintage art and fascinating texts to read.
Click here to have the slave beaten.
_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg