A spec to set default terminal applications?
Vladimir Kudrya
vladimir-csp at yandex.ru
Sat Oct 14 20:33:01 UTC 2023
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 <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.
>> 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 <pcman.tw at gmail.com> 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
>>> <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
>>> 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 at lists.freedesktop.org
>>> > https://lists.freedesktop.org/mailman/listinfo/xdg
>> _______________________________________________
>> xdg mailing list
>> xdg at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/xdg
>
>
More information about the xdg
mailing list