Faire interface utilisateur sans environnement bureau

Support Debian
#1

Bonjour,

voilà je suis en train de me faire un petit système embarqué à base de ARM. Je compte y ajouter un écran tactile LCD. Mon système n’aura qu’une seule application à lancer (certainement réalisé avec Qt). Du coup j’aimerai me passer d’environnement de bureau et lancer mon application en plein écran dès le démarrage du système et qu’en gros on ne puisse rien faire d’autre que utiliser cette application en plein écran.

Hors j’avoue que je ne sais pas comment m’y prendre ni par où commencer… peut être avec des outils comme openBox ou fluxbox?

Si quelqu’un peut me donner la marche à suivre^^

Merci d’avance

#2

Je ne sais pas trop, mais tu pourrais même n’avoir besoin que de Xorg.
Et de lancer ton application via ~/.xinitrc, vu que c’est avec ça qu’on peut lancer certains gestionnaires de fenêtres ou des commandes au démarrage de X.

[code]$ cat ~/.xinitrc
#!/bin/bash

#exec ck-launch-session awesome
#exec twm
#exec roxterm
exec i3
exec xbacklight -set 0[/code]

Pas certain de l’utilité du exec dans le dernier cas.
wiki.archlinux.org/index.php/Xinitrc

Il te faudra aussi un paquet genre [mono]nodm[/mono] pour démarrer X automatiquement.

#3

Merci je vais déjà tester ça ^^

#4

j’ai fait un truc quasi identique pour mon GPS (dreamplug + écran tactile)
J’utilise xorg, slim, et fluxbox.
L’appli GPS (navit) démarre par défaut en plein écran.
C’est vraiment simple à faire.

#5

ok, Slim je ne connais pas et je n’ai jamais utilisé fluxbox ^^ je vais essayer de voir ce que je peux faire avec.

Comment ça se passe pour le “design” général de l’application ? car Qt empreinte le visuel de la machine pour laquelle il est compilé…

#6

Un environnement type *box ça le fait.
Un openbox avec un autostart bien paramétré et ça roule…

#7

n’ayant toujours pas le PC cible à disposition, j’ai décidé de me lancer avec un machine virtuelle… ^^

donc j’ai suivit les conseils de Zbf, et j’ai fait ça (je part d’une Ubuntu car le pc est déjà livré avec Ubuntu … ):
j’ai donc lancer une console avec "ctrl + alt 9+F1 " … puis :

sudo service lightdm stop
sudo apt-get remove lightdm
sudo apt-get install nodm

jusque là tout va bien…
ensuite j’ai “configuré” nodm comme ceci:

cat /etc/default/nodm


# nodm configuration

# Set NODM_ENABLED to something different than 'false' to enable nodm
NODM_ENABLED=true

# User to autologin for
NODM_USER=franck

# xinit program
NODM_XINIT=/usr/bin/xinit

# First vt to try when looking for free VTs
NODM_FIRST_VT=7

# X session
NODM_XSESSION=/etc/X11/Xsession

# Options for the X server
NODM_X_OPTIONS='vt7 -nolisten tcp'

# If an X session will run for less than this time in seconds, nodm will wait an
# increasing bit of time before restarting the session.
NODM_MIN_SESSION_TIME=60

enfin j’ai créé un fichier ~/.xinitrc pour lancer mon programme :

cat ~/.xinitrc

#!/bin/bash

exec /PATH/vers/monprogramme/monprogramme

mais là ça ne fonctionne pas, et Unity est quand même lancé…
en consultant cette page:
geek-du-soir.blogspot.fr/2011/03 … -avec.html

j’ai tenté de créer le fichier ./xsession comme ceci :

#!/bin/bash
/PATH/vers/monprogramme/monprogramme

et là ça fonctionne mais le design des boutons, etc, n’est pas aussi beau que dans Unity… pourtant je pense que les librairies Qt4 sont utilisées par le serveur X et non pas par le bureau ou le windows manager non? de plus du coup j’ai l’impression que ~/.xinitrc n’est jamais utilisé, et là je ne comprends pas ce qui m’échappe ?

je tenterai avec openBox aussi plus tard une fois que j’aurai compris ce qui se passe déjà la car mon programme en appelle un autre (une cartographie qui a une barre de status déplaçable pour zoomer et fermer la cartographie et cette barre n’apparait pas du tout alors que la cartographie est bien affichée et je suppose , peut être à tord, que cela vient de l’absence de gestionnaire de fenêtre)

#8

Je me mélange les pinceaux avec .xsession et .xinitrc, mais bref.

Si les graphismes de QT sont pas jolis, ça se règle peut-être avec [mono]qtconfig[/mono], fournit par le paquet [mono]qtchooser[/mono]

#9

en fait ça n’est pas tant que ce n’est pas “joli” mais que c’est “différent” du résultat sous Unity… là je dirai que c’est plus “brute” … je vais regarder du coté de qtchooser et qtconfig pour comprendre d’où vient cette différence ^^

.xinitrc sert à quoi concrètement si .xession lance déjà lui aussi un peu ce qu’on veut tel que des windows manager ?

#10

Comment tu fais pour avoir unity avec une install minimale ou “serveur” sous *buntu?
Le plus simple est de partir d’une install minimale debian et d’y greffer juste ce que tu as besoin après, sans oublier de configurer apt pour qu’il ne traite pas les paquets recommandés comme des dépendances.

Je ne sais comment procèdent la majorité des forumeurs d’ici mais j’ai jamais installé une debian one shot, j’ai toujours construit le système en partant d’une install minimale : ça permet d’avoir ce qu’on a besoin et QUE ce qu’on a besoin.

#11

oui tu as raison, mais c’est parce que je pars d’un PC (panel-pc tactile) avec *buntu qui sera déjà installé par le constructeur (avec tout ce qui est driver tactile et autre dessus. du coup soit je réinstalle tout soit je pars de cette base existante et cette solution me semblait un peu plus “rapide” . Mais je vais tenter une installation minimale de debian et voir si j’arrive à faire marcher le tactile dessus.

Par contre je ne savais pas que l’on peut configurer apt comme tu le dis. je vais me renseigner sur ce point aussi^^

#12

.xinitrc (et la version system-wide dans /etc/X11/xinit/xinitrc) sont utilisés par xinit et startx, pour lancer X, dans le cas ou on n’utilise pas de gestionnaire de session.

[mono]man startx
man xinit[/mono]
pour en savoir plus

#13

je vais faire mon lourd, mais ceci m’amène à une autre question (désolé ^^) mais dans quels cas choisir entre ne pas utiliser du tout de gestionnaire de session et utiliser nodm ?

#14

Un critère: si tu as un ou plusieurs comptes utilisateurs

#15

ok, ayant en général un seul compte utilisateur, je n’ai pas ce réflexe de penser “plusieurs utilisateurs” … merci pour l’éclaircissement ^^

#16

perso j’ai arréter de bidouillé dans les fichiers de type.xinit, et j’utilise slim.
Gros gain en efficacité, plus de prise de tête.

#17

donc là pour info j’utilise nodm qui lance openbox-session dans .xsession

openbox lance mon programme dans autostart

j’ai fait un coup de qtconfig-qt4 pour avoir le visuel qui me plait avec mon programme …

openbox me permet juste de gérer la panneau d’outils de la cartographie car sans manager de fenêtre, je n’arrivais pas à gérer ce point sans WM (peut être que c’est faisable mais je n’ai pas trouvé comment)…

Là je suis en train de voir comment configurer openbox pour virer les bordures , etc…

enfin j’utilise plymouth pour avoir un truc sympa au démarrage … mais comme j’ai fait une bidouille pour qu’il apparaisse de suite, je suis obligé de faire un “killall plymouth” dans l’autostart d’openbox pour ne pas avoir un crash de celui-ci…

voilà encore un petit effort pour finaliser le truc et je testerai depuis une debian minimal (le seul truc qui m’inquiète un peu est le driver tactil car je n’ai pas les sources … )

edit: voilà, j’ai suivit ces instructions pour enlever les bord d’openBox :
xprop | grep WM_CLASS
puis clic que la fenêtre dont on veut enlever les bords pour connaître sa classe et complètrer le rc.xml d’openBox avec ceci (comme décrit ici:
tux-planet.fr/openbox-enleve … plication/ )
:

…

no

…

en faisant comme ça c’est nickel car on peut définir quelles applications on des bords ou pas, ce qui m’arrange pour fermer facilement la cartographie.

Bon il me reste à traiter le clavier virtuel qui est sensé apparaître automatiquement lorsque l’on clique dans une zone de texte… en gros lancer onboad avec openbox en mode caché par défaut et affichage auto ^^

Edit : donc pour finir, j’ai ajouté onboard & dans l’autostart d’openbox. ça marche bien mais j’ai galéré à lui faire avoir le comportement décrit ci dessus… j’ai néanmoins trouvé une astuces capilotractée pour y parvenir en redémarrant sous Un*ty, faisant le parapmètrage “graphiquement” et ensuite j’ai pu constaté que le comportement paramétré a bien été sauvegardé… par contre ça n’est clairement pas élégant car je n’ai pas trouvé dans quel fichier est paramétré ce comportement…

Enfin j’ai découvert que les liens vers les images utilisées par mon application Qt doivent être codés en absolu pour que les images s’affichent alors que sous Un*ty en relatif ça marchait très bien.

voilà, j’ai enfin quelque chose qui devrai fonctionner le jour où je pourrait tester ça sur le PC cible… (je rappelle que j’ai fais tout ça dans une VM…)

Bon maintenant prochaine étape, faire tout ça partir d’une Debian minimal dès que j’ai un peu de temps ^^

Un grand merci à vous pour votre aide :023