A spec to set default terminal applications?
jtojnar at gmail.com
Fri Aug 31 13:35:04 UTC 2018
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 <pcman.tw at gmail.com> wrote:
> Hi again,
> There is another way to make this xdg terminal exec stuff more
> standard compliant by reusing XDG menu spec.
> 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.
> On Fri, Aug 31, 2018 at 8:46 PM PCMan <pcman.tw at gmail.com> wrote:
>> 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.
>> 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
>> [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
>> 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
>> <vladimir-csp at yandex.ru> 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
>> > https://bugzilla.gnome.org/show_bug.cgi?id=767732 It required an
>> > argument to open file, but no argument to just launch the app.
>> > 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
>> > 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,
>> > ArgPrefix if needed. IMHO one of the few intents that would ever
>> > 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
>> > emulators. (xdg-terminal as wrapper to get rid of that space?).
>> > _______________________________________________
>> > xdg mailing list
>> > xdg at lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/xdg
> xdg mailing list
> xdg at lists.freedesktop.org
More information about the xdg