Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Unix application graphique *et* en ligne de commande

application graphique *et* en ligne de commande

8 réponses
Avatar
Thomas
bonjour :-)


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 ?

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 ?

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Thomas
In article
,
Thomas wrote:
bonjour :-)
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 ?
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 ?

en fait, concrètement,
cet exécutable se connecte au serveur x11 au démarrage, même si après il
ne fait plus rien avec.
je ne sais pas ce que ça implique.
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.
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Avatar
pehache
Le 20/09/2021 Í  03:09, Thomas a écrit :
In article
,
Thomas wrote:
bonjour :-)
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 ?

en fait, concrètement,
cet exécutable se connecte au serveur x11 au démarrage, même si après il
ne fait plus rien avec.
je ne sais pas ce que ça implique.

Qu'il faut qu'il y ait X11 installé sur la machine, et qu'un serveur X11
soit accessible.
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 ?
Avatar
Stéphane CARPENTIER
Le 20-09-2021, pehache a écrit :
Le 20/09/2021 Í  03:09, Thomas a écrit :
In article
,
Thomas 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.
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.
--
Si vous avez du temps Í  perdre :
https://scarpet42.gitlab.io
Avatar
Thomas
In article ,
pehache wrote:
Le 20/09/2021 Í  03:09, Thomas a écrit :
In article
,
Thomas wrote:
bonjour :-)
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.

ok.
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 ?

en fait, concrètement,
cet exécutable se connecte au serveur x11 au démarrage, même si après il
ne fait plus rien avec.
je ne sais pas ce que ça implique.

Qu'il faut qu'il y ait X11 installé sur la machine, et qu'un serveur X11
soit accessible.

en principe c'est obligatoire, parce que l'usage principal est en gui :
en cli on n'a accès qu'Í  des fonctions "périphériques".
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 ?

je viens de vérifier qu'effectivement ça se passe au moment o͹ on
initialise gtk, pas avant.
mais la conception fait que gtk est initialisé au démarrage du logiciel,
pas au moment o͹ on commence ͠ vraiment l'utiliser.
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Avatar
Thomas
In article ,
Stéphane CARPENTIER wrote:
Le 20-09-2021, pehache a écrit :
Le 20/09/2021 Í  03:09, Thomas a écrit :
In article
,
Thomas 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/
Avatar
Stéphane CARPENTIER
Le 21-10-2021, Thomas a écrit :
In article ,
Stéphane CARPENTIER wrote:
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 ?

L'intérêt de séparer la partie moteur de la partie rendu, c'est que le
moteur, c'est la fonctionnalité du programme alors que le rendu est
beaucoup plus subjectif. Si la personne n'aime pas le rendu mais aime
les fonctionnalités, elle a facilement la possibilité de changer de
wraper. De même le passage de X11 Í  Wayland est le problème du wraper,
pas du moteur. Donc, si un nouveau remplacement débarque, ton programme
tournera toujours dans un terminal de ce remplaçant sans que tu n'aies
rien Í  faire.
je ne suis pas sur que ça soit vraiment comparable,
je me pose cette question du point de vue de la conception :

Je ne sais pas ce que tu cherches Í  faire, je ne sais donc pas si c'est
comparable ou pas.
- 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.

Heu, lÍ , je veux bien que tu m'expliques comment tu fais pour savoir
comment tu es en ligne de commande ou en mode graphique en analysant la
les arguments. Une option de la ligne de commande peut demander son
lancement en terminal ou en mode graphique, mais ça ne te dira pas
si c'est lancé dans un terminal ou en mode graphique.
- Í  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.

Si tu fais du code en double, c'est que tu n'as pas séparé la partie
moteur de la partie graphique. Le but du wraper n'est pas de dupliquer
le code, mais de l'appeler.
est-ce que wayland propose aussi un moyen de passer Í  travers ssh ?

J'en ai l'impression :
<https://wiki.debian.org/Wayland#I_share_monitors_between_systems_using_x2x.__How_will_this_work_under_Wayland.3F>
--
Si vous avez du temps Í  perdre :
https://scarpet42.gitlab.io
Avatar
Thomas
In article ,
Stéphane CARPENTIER wrote:
Le 21-10-2021, Thomas a écrit :
In article ,
Stéphane CARPENTIER wrote:
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 ?

L'intérêt de séparer la partie moteur de la partie rendu, c'est que le
moteur, c'est la fonctionnalité du programme alors que le rendu est
beaucoup plus subjectif. Si la personne n'aime pas le rendu mais aime
les fonctionnalités, elle a facilement la possibilité de changer de
wraper. De même le passage de X11 Í  Wayland est le problème du wraper,
pas du moteur. Donc, si un nouveau remplacement débarque, ton programme
tournera toujours dans un terminal de ce remplaçant sans que tu n'aies
rien Í  faire.

c'est curieux.
je vois très bien comment faire ainsi que l'intérêt de compartimenter ce
genre de chose au niveau du code,
mais bcp moins bien comment ça peut se passer entre un binaire et un
wraper.
je ne suis pas sur que ça soit vraiment comparable,
je me pose cette question du point de vue de la conception :

Je ne sais pas ce que tu cherches Í  faire, je ne sais donc pas si c'est
comparable ou pas.
- 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.

Heu, lÍ , je veux bien que tu m'expliques comment tu fais pour savoir
comment tu es en ligne de commande ou en mode graphique en analysant la
les arguments. Une option de la ligne de commande peut demander son
lancement en terminal ou en mode graphique, mais ça ne te dira pas
si c'est lancé dans un terminal ou en mode graphique.

je ne comprend pas ta question. on dirait que la réponse est dedans.
- Í  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.

Si tu fais du code en double, c'est que tu n'as pas séparé la partie
moteur de la partie graphique. Le but du wraper n'est pas de dupliquer
le code, mais de l'appeler.

comment fonctionne un wraper pour appeler gtk et pas le moteur ?
est-ce que c'est un binaire ? comment communique-t-il avec le moteur ?
est-ce que wayland propose aussi un moyen de passer Í  travers ssh ?

J'en ai l'impression :
<https://wiki.debian.org/Wayland#I_share_monitors_between_systems_using_x2x.__
How_will_this_work_under_Wayland.3F>

c'est écrit "Native Wayland applications are not forwarded".
c'est quand même embêtant qu'il n'y ait rien de prévu ...
c'est grace Í  ce mécanisme que je peux continuer Í  développer un peu sur
mon vieil ordi, malgré certaines limites.
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/
Avatar
Thomas
In article
,
Thomas wrote:
In article ,
pehache wrote:
Le 20/09/2021 Í  03:09, Thomas a écrit :
> In article
> ,
> Thomas wrote:
>

>> 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 ?
>
>
> en fait, concrètement,
> cet exécutable se connecte au serveur x11 au démarrage, même si après il
> ne fait plus rien avec.
>
> je ne sais pas ce que ça implique.
Qu'il faut qu'il y ait X11 installé sur la machine, et qu'un serveur X11
soit accessible.

en principe c'est obligatoire, parce que l'usage principal est en gui :
en cli on n'a accès qu'Í  des fonctions "périphériques".
> 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 ?

je viens de vérifier qu'effectivement ça se passe au moment o͹ on
initialise gtk, pas avant.
mais la conception fait que gtk est initialisé au démarrage du logiciel,
pas au moment o͹ on commence ͠ vraiment l'utiliser.

lÍ  j'ai une question un peu différente,
parce que je me suis aperçu qu'avec Tcl/Tk ça fait l'initialisation
seulement au moment o͹ on s'en sert pour la 1ere fois, pas au démarrage
du logiciel.
ça a pour conséquence que si on s'en sert en cli ça ne fait pas
l'initialisation.
ça fonctionne grÍ¢ce Í  des variables globales.
je pense que je pourrais faire la même chose avec gtk.
mais je n'aime pas du tout les variables globales.
si je divise ce logiciel en 2, et que la partie qui peut être utilisée
seulement en graphique est sure de s'en servir,
ça me parait bien plus sur et lisible de faire le contraire,
cad transformer le pair Tcl/Tk pour qu'il soit initialisé au démarrage
du logiciel,
et supprimer les variables globales, sources de toutes sortes d'erreurs
et d'effets de bord.
as tu un avis lÍ  dessus ?
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/