Spec to define the default terminal?

[Jerome Leclanche]

This is something I tried solving quite a few times. There was an
intents spec (a la android) in the works which was subsequently picked
up by GNOME, I don't know where it's at now but it's the more correct
fix.

On 20 October 2015 at 13:37, Thomas Gläßle <t_glaessle at gmx.de> wrote:
>
> Thomas Gläßle wrote on 10/20/2015 12:23 PM:
>> 1 a) invent a new variable e.g. $TERMINAL or similar that works like
>> $BROWSER, i.e. something of the form TERMINAL=urxvt:gnome-terminal:xterm
>>
>> 1 b) invent a new variable e.g. $TERMINAL or similar that works like the
>> one used by mimeopen, i.e. TERMINAL="xterm -e"
>>
>> 2) encourage the use of (and possibly semi-mandatory dependency on)
>> gvfs-open/kde-open
>>
>> 3). invent a mimetype for terminal applications so available terminals
>> can be iterated via .desktop files and a default can be requested in the
>> mimeapps.list file, e.g.:
>
> I forgot to mention option 4 which I saw lurking around:
>
> 4) use the binary x-terminal-emulator which is to be symlinked to
> whatever terminal one wants to use.
>
>   - [+] nice and simple
>   - [+] possibly already supported by several subsystems?
>   - [-] system-wide config (you have to modify PATH in order to change
> it for users)
>
>
>
>> concerning 1 a)
>>
>>   - [+] nice and simple
>>   - [-] have to hardcode command line options, e.g. terminator uses "-x"
>> rather than "-e"
>>   - considering $TERMINAL is already used in a different fashion by
>> mimeopen (and mimeopen is used as fallback by xdg-open), I'd rather tend
>> towards a different name for the variable, e.g. $TERMCMD which would be
>> upward compatible to how its used by terminator
>>
>>
>> concerning 1 b)
>>
>>   - [+] no need to hardcode command line options
>>   - [+] compatible with existing mimeopen behaviour
>>   - [-] contains more than just a executable name, may be less simple to
>> analyze
>>
>>
>> concerning 2)
>>
>>   - [+] easy out without much coding for xdg-open
>>   - [-] doesn't really solve the problem that "everyone uses their own
>> mechanism"
>>   - [-] I didn't look at gvfs-open/kde-open so far, but I'm afraid, they
>> don't allow the user to specify their preferred terminal as easily
>>   - [-] seems like a heavy dependency
>>
>>
>> concerning 3)
>>
>>   - [+] uses an established config format
>>   - [+] can configure multiple terminals with correct command line
>> options and the default
>>   - [-] not sure if the mimetype concept applies to this problem very well
>>   - [-] maybe too complex for such a simple goal
>
>
>
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>