Re: A spec to set default terminal applications?

[Vladimir Kudrya]

Hi everyone!

It once had a good momentum, major issues addressed. The request is 
still open, what's next?


On 01/12/2023 01.34, Vladimir Kudrya wrote:


FYI, The proposed xdg-terminal-exec 
 now relies on 
stock desktop entries, the shell implementation is optimized, 
experimental cache support is in the works.


The spec proposal is updated 
.

Re: A spec to set default terminal applications?

[Vladimir Kudrya]

FYI, The proposed xdg-terminal-exec 
 now relies on stock 
desktop entries, the shell implementation is optimized, experimental 
cache support is in the works.


The spec proposal is updated 
.


On 14/10/2023 23.33, Vladimir Kudrya wrote:

Hi. Let's dust off this thread.

I'm starting to transition xdg-terminal-exec to use stock entries 
filtered by "TerminalEmulator" in Categories key.


On 31/08/2018 16.35, Jan Tojnar wrote:
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.


On Fri, 31 Aug, 2018 at 2:54 PM, PCMan  wrote:

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

On Fri, Aug 31, 2018 at 8:46 PM PCMan  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 
 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 

Re: A spec to set default terminal applications?

[Vladimir Kudrya]

Hi. Let's dust off this thread.

I'm starting to transition xdg-terminal-exec to use stock entries 
filtered by "TerminalEmulator" in Categories key.


On 31/08/2018 16.35, Jan Tojnar wrote:
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.


On Fri, 31 Aug, 2018 at 2:54 PM, PCMan  wrote:

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

On Fri, Aug 31, 2018 at 8:46 PM PCMan  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 
 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?).
 > 

Re: A spec to set default terminal applications?

[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.


On Fri, 31 Aug, 2018 at 2:54 PM, PCMan  wrote:

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

On Fri, Aug 31, 2018 at 8:46 PM PCMan  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 
 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
 > xdg@lists.freedesktop.org
 > https://lists.freedesktop.org/mailman/listinfo/xdg

___
xdg mailing 

Re: A spec to set default terminal applications?

[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.


On Fri, 31 Aug, 2018 at 2:46 PM, PCMan  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 
 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
 xdg@lists.freedesktop.org
 https://lists.freedesktop.org/mailman/listinfo/xdg

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


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

Re: A spec to set default terminal applications?

[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

On Fri, Aug 31, 2018 at 8:46 PM PCMan  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  
> 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
> > xdg@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/xdg
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: A spec to set default terminal applications?

[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.

On Thu, Aug 30, 2018 at 3:36 PM Vladimir Kudrya  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
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: A spec to set default terminal applications?

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

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

Re: A spec to set default terminal applications?

[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






On Wed, 29 Aug, 2018 at 11:41 PM, Ian Huang  wrote:
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?


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

Re: A spec to set default terminal applications?

[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?
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: A spec to set default terminal applications?

[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

On Wed, 29 Aug, 2018 at 10:14 PM, Ian Huang  wrote:
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.


On Wed, Aug 29, 2018, 01:21 Vladimir Kudrya  
wrote:
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?

On 2018-08-29 09:50, Ian Huang wrote:
> 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?




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

Re: A spec to set default terminal applications?

[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.

On Wed, Aug 29, 2018, 01:21 Vladimir Kudrya  wrote:

> 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?
>
> On 2018-08-29 09:50, Ian Huang wrote:
> > 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?
>
>
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: A spec to set default terminal applications?

[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?


On 2018-08-29 09:50, Ian Huang wrote:
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?


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

Re: A spec to set default terminal applications?

[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.

On Tue, Aug 28, 2018, 21:35 Vladimir Kudrya  wrote:

> On 2018-08-29 00:27, Ian Huang wrote:
>
> 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.
>
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: A spec to set default terminal applications?

[Vladimir Kudrya]

  
  
On 2018-08-29 00:27, Ian Huang wrote:
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.
  

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

Re: A spec to set default terminal applications?

[Ian Huang]

Vladimir Kudrya 

> Last year I proposed a mechanism for this purpose:
> 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.


Liam R E Quin 

> 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. . . .
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: A spec to set default terminal applications?

[Philipp A.]

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

Liam R E Quin  schrieb am Di., 28. Aug. 2018 um 09:07 Uhr:

> On Mon, 2018-08-27 at 17:26 -0700, Ian Huang wrote:
> > 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.
>
> 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
> xdg@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
>
___
xdg mailing list
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: A spec to set default terminal applications?

[Liam R E Quin]

On Mon, 2018-08-27 at 17:26 -0700, Ian Huang wrote:
> 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.

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
xdg@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/xdg

Re: A spec to set default terminal applications?

[Vladimir Kudrya]

  
  
Hello!
Last year I proposed a mechanism for this purpose:
  https://github.com/Vladimir-csp/xdg-terminal-exec/
It addresses issues like inconsistent cli arguments of different
  emulators and general difference in paradigms between choosing a
  terminal emulator and choosing file/protocol associations.


On 2018-08-28 03:26, Ian Huang wrote:


  
  
Hello,
  I'm just a regular GNOME user, but I recently stumbled across
  an issue 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)

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



  

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

Re: A spec to set default terminal applications?

[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.

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

Re: A spec to set default terminal applications?

[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


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