Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > fr.comp.os.unix > #7775 > unrolled thread

application graphique *et* en ligne de commande

Back to article view | Back to fr.comp.os.unix

Contents

  application graphique *et* en ligne de commande Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-13 21:40 +0200
    Re: application graphique *et* en ligne de commande Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-20 03:09 +0200
      Re: application graphique *et* en ligne de commande pehache <pehache.7@gmail.com> - 2021-09-20 10:45 +0000
        Re: application graphique *et* en ligne de commande Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-09-24 18:32 +0000
          Re: application graphique *et* en ligne de commande Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-10-21 20:50 +0200
            Re: application graphique *et* en ligne de commande Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-10-23 13:08 +0000
              Re: application graphique *et* en ligne de commande Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-02-12 20:32 +0100
        Re: application graphique *et* en ligne de commande Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-10-21 20:14 +0200
          Re: application graphique *et* en ligne de commande Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-02-12 21:05 +0100

#7775 — application graphique *et* en ligne de commande

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/

[toc] | [next] | [standalone]

#7779

In article 
<fantome.forums.tDeContes-DA8D66.21400513092021@news.free.fr>,
 Thomas <fantome.forums.tDeContes@free.fr.invalid> 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/

[toc] | [prev] | [next] | [standalone]

#7780

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:
> 
>> 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 ?

[toc] | [prev] | [next] | [standalone]

#7792

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.

>> 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

[toc] | [prev] | [next] | [standalone]

#7846

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/

[toc] | [prev] | [next] | [standalone]

#7854

Le 21-10-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit :
> In article <slrnsks6d2.83t.sc@scarpet42p.localdomain>,
>  Stéphane CARPENTIER <sc@fiat-linux.fr> 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

[toc] | [prev] | [next] | [standalone]

#7908

In article <slrnsn82b3.4sf.sc@scarpet42p.localdomain>,
 Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:

> Le 21-10-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit :
> > In article <slrnsks6d2.83t.sc@scarpet42p.localdomain>,
> >  Stéphane CARPENTIER <sc@fiat-linux.fr> 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/

[toc] | [prev] | [next] | [standalone]

#7845

In article <CWVW4dhAGMorQ_KzJ5kEy_bSuK0@jntp>,
 pehache <pehache.7@gmail.com> wrote:

> 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:
> > 
> >> 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/

[toc] | [prev] | [next] | [standalone]

#7909

In article 
<fantome.forums.tDeContes-12D115.20143721102021@news.free.fr>,
 Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

> In article <CWVW4dhAGMorQ_KzJ5kEy_bSuK0@jntp>,
>  pehache <pehache.7@gmail.com> wrote:
> 
> > 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:
> > > 

> > >> 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/

[toc] | [prev] | [standalone]

Back to top | Article view | fr.comp.os.unix

csiph-web