Re: application graphique *et* en ligne de commande

Liste des GroupesRevenir à fco unix 
Sujet : Re: application graphique *et* en ligne de commande
De : fantome.forums.tDeContes (at) *nospam* free.fr.invalid (Thomas)
Groupes : fr.comp.os.unix
Date : 21. Oct 2021, 20:50:12
Autres entêtes
Organisation : Guest of ProXad - France
Message-ID : <fantome.forums.tDeContes-558DB3.20501221102021@news.free.fr>
References : 1 2 3 4
User-Agent : MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
In article <slrnsks6d2.83t.sc@scarpet42p.localdomain>,
 Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:

Le 20-09-2021, pehache <pehache.7@gmail.com> a écrit :
Le 20/09/2021 à 03:09, Thomas a écrit :
In article
<fantome.forums.tDeContes-DA8D66.21400513092021@news.free.fr>,
 Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
actuellement, j'ai un exécutable qui peut être utilisé soit en graphique
soit en ligne de commande.
on choisit en mettant une option sur la ligne de commande.
 
est ce que c'est qqch qui se pratique ?
>
Pourquoi pas.
 
si non, est ce que c'est qqch que vous me déconseillez formellement ?
en me conseillant de séparer cet exécutable en 2,
1 qui peut être utilisé seulement en graphique,
et 1 qui peut être utilisé seulement en ligne de commande ?
 
Je ne sais pas comment est géré vim par rapport à gvim, mais j'ai
l'impression que c'est un peu comme ta première demande. Par contre
l'approche de neovim de ne fonctionner que dans un terminal avec la
possibilité d'écrire des wrappers pour le lancer en mode graphique me
semble plus intéressant, comme ta seconde proposition.

pourquoi trouves-tu ça plus intéressant ?

je ne suis pas sur que ça soit vraiment comparable,
je me pose cette question du point de vue de la conception :

- la procédure principale (semblable à la fonction main) n'a pas grand
chose en commun, quasiment que l'analyse des arguments pour savoir si on
est en cli ou en gui.

- à l'inverse, en cli et en gui ça utilise des sous-programmes en commun,
donc si je sépare, je me demande dans quelle mesure ça ferais doublon de
code machine dans chacun des 2 exécutables, et ça raterais des occasions
d'optimisation à différents niveaux (que je n'imagine pas bien), donc ça
ferais du gaspillage.

 
ni si ça ferais une différence importante ou négligeable, de faire un
exécutable séparé pour utiliser en ligne de commande, pour éviter qu'il
se connecte au serveur x11.
>
Qu'est-ce qui oblige à se connecter au serveur X11 dans tous les cas ?
Pourquoi ça ne peut pas être fait uniquement en cas de session graphique
demandée ?
 
Surtout que ce n'est pas exactement pareil que le mode graphique. Par
exemple wayland est aussi un mode graphique mais sans serveur x11.

est-ce que wayland propose aussi un moyen de passer à travers ssh ?

c'est bizarre, avec gtk j'ai :
Xlib:  extension "RANDR" missing on display "localhost:10.0".
mais je ne l'ai pas avec Tcl/Tk, alors qu'il se connecte bien à mon
serveur x11.

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

Date Sujet#  Auteur
13 Sep 21 * application graphique *et* en ligne de commande9Thomas
20 Sep 21 `* Re: application graphique *et* en ligne de commande8Thomas
20 Sep 21  `* Re: application graphique *et* en ligne de commande7pehache
24 Sep 21   +* Re: application graphique *et* en ligne de commande4Stéphane CARPENTIER
21 Oct 21   i`* Re: application graphique *et* en ligne de commande3Thomas
23 Oct 21   i `* Re: application graphique *et* en ligne de commande2Stéphane CARPENTIER
12 Feb 22   i  `- Re: application graphique *et* en ligne de commande1Thomas
21 Oct 21   `* Re: application graphique *et* en ligne de commande2Thomas
12 Feb 22    `- Re: application graphique *et* en ligne de commande1Thomas

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal