Recherche d'une GUI mais pas seulement...

[gaudon]

Bonjour  ,

J'ai lu pas mal de choses sur SFML avec intérêt. bravo à Laurent et à vous tous pour ce beau travail.
Je bosse dans une petite société qui fait de la machine spéciale et je développe notre propre système d'automatisation. Le maillon faible de notre solution est l'IHM locale, il faut dire que je l'avais réalisé il y a maintenant (très) longtemps en partant du pixel et l'affichage se faisait sur un LCD 128x128. Maintenant je passe sur un écran VGA ou plus et mon challenge est le suivant:

L'OS utilisé est VxWorks 5.4 avec l'environnement tornado, il s'agit d'une ancienne version mais on n'a pas les sous pour passer à la dernière version. (ça c'est la tête du boss quand il voit le coût :  )
Je n'ai pas les drivers graphiques de la base PC que j'utilise, j'ai donc momentanément utilisé les interruptions Bios pour passer en 800x600 16 couleurs, cela m'a permis de reprendre facilement l'ancienne interface et de la mettre à la sauce 16couleurs mais c'est insuffisant, j'ai besoin de faire des scrollings d'écran et d'afficher des photos.

Mes questions:

Est-ce que SFML se suffit à elle-même et plus précisément:
Comment SFML initialise-t-elle le contrôleur graphique ? (La base PC est une MSM800 basée sur le Geode LX800)
En bref, peux-t-on utiliser SFML sous VxWorks ? (je maîtrise assez bien VxWorks)

Merci pour votre aide

[Laurent]

SFML est conçue pour fonctionner sur les environnements communs : Windows, Linux et Mac OS X.

Je ne sais pas sur quoi est basé VxWorks 5.4, donc je ne peux pas te répondre. Ceci-dit si c'est une base Unix, pour que ça fonctionne il faudra certainement les choses suivantes :
- OpenGL
- X11
- pthreads
- FreeType
- libpng
- GLEW
- sûrement des modifs dans SFML

En lisant ton message je pense qu'on doit être assez loin du compte, non ?

[gaudon]

>>En lisant ton message je pense qu'on doit être assez loin du compte, non ?

Oui, j'en ai bien peur  mais j'ai encore des options 

Vu la baisse des coût de hardware, j'ai aussi la solution de déporter l'IHM dans un petit panelPC tactile.
Ce serait alors une IHM autonome télécommandée par la (ou les) commande(s) numérique(s) via des messages TCP. Le terminal présenterait des pages standards codées en dur, par exemple la page des alarmes station, données de production, et je prévoirais quelques pages pour les besoins spécifiques de l'utilisateur. Celui-ci pourrait envoyer via la CN des commandes du genre :

• Affiche un menu à la position x,y dont les choix sont toto, titi, tata, tonton. Une fois le choix effectué, le terminal renvoi le numéro du choix.
• Affiche un bouton look "tartempion" avec le texte "truc" à la position x,y
• Le terminal embarquerait aussi un clavier virtuel affichage à la demande et renverrait les codes de touche pressés et/ou la position pointée, libre à l'utilisateur de traiter l'info ou pas.

Cette solution aurait l'avantage de pouvoir s'implémenter également sur le PC central, qui est sous Windows, elle aurait aussi l'avantage d'être accessibles depuis plusieurs CN simultanément. En fait, ça pourrait s'appeler un serveur d'IHM. Et pour le petit terminal, il me faudrait un OS minimaliste, juste ce qu'il faut pour tirer partie de la SFML que je sens bien.
Que pensez-vous de la solution ?
Quel hardware et quel OS minimaliste vous verriez ?

Merci 

[Laurent]

C'est dur à dire, là comme ça. Tu es le mieux placé pour juger de ce genre de choix et de technologie.

Par contre si ce n'est que de l'IHM, pourquoi faire le choix de SFML ? Pourquoi pas Qt, par exemple, qui tourne sur bien plus de plateformes (y compris embarquées), et surtout est fait pour l'IHM ?

[gaudon]

Par contre si ce n'est que de l'IHM, pourquoi faire le choix de SFML ? Pourquoi pas Qt, par exemple, qui tourne sur bien plus de plateformes (y compris embarquées), et surtout est fait pour l'IHM ?

Bonne question...
Je me trompe peut être mais je me dis que :

• Je développe dans l'industrie et ça ne fait pas bon ménage avec les nouvelles technos, on recherche surtout une fonctionnalité dans la fiabilité et une maintenance du produit sur plusieurs années, je maintiens encore des technos de 1990 avec du DOS6.22 et du micro contrôleur 8051 sans OS...
• Qt est beaucoup plus que ce dont j'ai besoin, en plus on est en droit de penser que Qt est en perte de vitesse pour finalement bientôt s'arrêter
• En ce qui concerne les IHM, nous sommes inondés par les nouvelles techno qui vont du RIA au natif. les 9/10ieme n'existeront plus dans 3 ans, le Rich Internet Application est en pleine évolution et tout ça est contraire aux contraintes précités
• Je pourrais faire la comparaison avec le matériel utilisé à l'armée : fiables, robustes, simples et maintenable, il n'y a pas longtemps que l'armée a abandonné le code morse, ils ne sont pas prêts d'adopter la 3G 
• Et plus généralement, je suis persuadé que nous allons trop loin et trop vite dans tous les domaines, et que notre salut passera par la redécouverte des choses simples (pour illustrer mes propos : le standard téléphonique de notre société vient de passer en VOIP, et maintenant, quand on appelle un collègue qui est déjà en ligne, la tonalité d'occupation n'existe plus... ça sonne comme s'il ne répondait pas, en tout cas c'est comme ça sur les modèles choisis... par contre on peut composer des numéros directement depuis le carnet d'adresse du PC, mais on ne s'en sert pas car c'est plus rapide sans...

Si j'essaye de résumer:

• Plutôt que faire le choix de la portabilité je préfère faire le choix d'un produit pérenne, par exemple j'utilise une carte PC Basée sur un chipset intel LX800 depuis plusieurs années et elle sera dispo encore pour plusieurs années)
• J'ai besoin d'un système d'exploitation minimum pour héberger mon application
• J'ai besoin de produire du code qui soit compilable pour windows XP
• Je suis à l'aise avec des outils de base et n'importe qui peut les maintenir

Mes questions, parce que il me manque des notions concernant SFML 

• Quel est le degré de dépendance de la SFML avec les OS
• Quel est le degré de dépendance de la SFML avec les Hardware
• Si je choisis une carte PC pérenne avec une version de Linux figée que je n'utilise que pour mon appli IHM sous SFML 2.0, y-a-t-il une raison de ne plus pouvoir assurer la vente et la maintenance ?
  

J'ai été un peu long, merci pour votre aide

[Laurent]

Je développe dans l'industrie et ça ne fait pas bon ménage avec les nouvelles technos, on recherche surtout une fonctionnalité dans la fiabilité et une maintenance du produit sur plusieurs années

Ce qui serait complètement en faveur d'une bibliothèque telle que Qt plutôt que SFML.

Qt est beaucoup plus que ce dont j'ai besoin

Qt est modulaire, tu peux ne prendre que ce que tu veux.

en plus on est en droit de penser que Qt est en perte de vitesse pour finalement bientôt s'arrêter

Tu rigoles ? Ils vont sortir la 5.0 dans quelques mois. Il y a toujours plusieurs dizaines de salariés derrière, et plusieurs milliers de développeurs dans la communauté. De plus ils s'orientent vers une gestion ouverte (ils l'ont même déjà mise en place), donc même si les trolls de chez Nokia arrêtent de bosser dessus (très improbable) le produit n'en mourra pas pour autant.
Il n'y a aucune techno similaire/concurrente, donc ça ne risque pas non plus de tomber en désuétude.

En ce qui concerne les IHM, nous sommes inondés par les nouvelles techno qui vont du RIA au natif. les 9/10ieme n'existeront plus dans 3 ans, le Rich Internet Application est en pleine évolution et tout ça est contraire aux contraintes précités

Qt n'est pas une nouvelle techno, c'est un framework C++ natif, rien d'exotique là-dedans. Ils essayent de nouvelles approches pour le côté front-end (QML), mais je n'appellerait pas ça une "nouvelle techno".

Je pourrais faire la comparaison avec le matériel utilisé à l'armée : fiables, robustes, simples et maintenable

Alors n'utilise pas SFML. Sérieusement.
La 2.0 va sortir donc ne sera ni fiable ni robuste (la 2.9 le sera peut-être, dans quelques années).

Et plus généralement, je suis persuadé que nous allons trop loin et trop vite dans tous les domaines, et que notre salut passera par la redécouverte des choses simples

Je ne pense pas que SFML soit plus "simple" que Qt. Du moins c'est argumentable.
Et puis avec SFML il te faudra redévelopper tout le côté IHM, à moins d'utiliser un add-on genre SFGUI mais là tu perds encore un niveau de fiabilité/maintenance/robustesse.

Plutôt que faire le choix de la portabilité je préfère faire le choix d'un produit pérenne

SFML n'est pas pérenne. Je suis seul à bosser dessus. Si je n'ai pas le temps, si j'ai autre chose à faire, ou si je ne suis pas motivé, SFML n'avance pas. Si j'arrête carrément, SFML est morte.

J'ai besoin d'un système d'exploitation minimum pour héberger mon application

SFML cible uniquement les OS "communs" de bureau. Pour le moment du moins.

Quel est le degré de dépendance de la SFML avec les OS

Pour chaque OS il faut développer nativement :
- une couche système (threading, time)
- une couche de fenêtrage
- une couche d'interfaçage entre OpenGL et le fenêtrage
- une couche réseau
Il faut aussi un backend qui soit géré par OpenAL, pour la partie audio.

Quel est le degré de dépendance de la SFML avec les Hardware

Niveau graphique il faut pouvoir faire tourner OpenGL 1.4.

Si je choisis une carte PC pérenne avec une version de Linux figée que je n'utilise que pour mon appli IHM sous SFML 2.0, y-a-t-il une raison de ne plus pouvoir assurer la vente et la maintenance ?

Le risque le plus important pour toi c'est que je ne m'occupe plus de SFML. Ou qu'il y ait des bugs très gênants (il y en a) que je ne puisse pas corriger.

Voilà, comme tu le vois j'essaye d'être le plus objectif pour que tu te rendes compte que SFML est encore un produit "amateur" et dont l'avenir dépend entièrement d'une seule personne, alors que Qt est un produit professionnel robuste et pérenne.

Personnellement, si les contraintes hardware et softwares le permettent, j'utiliserais Qt sans hésiter. D'ailleurs je le fais au boulot, et nous faisons aussi de l'embarqué sur des systèmes parfois assez limités.

[gaudon]

Bonsoir Laurent, merci pour tes réponses.

Evidemment, si je poste sur ce forum, c'est pour me défricher 
Ce qui me vient, dans le désordre:

• Premièrement, si je venais à choisir SFML et que tu arrêtais son développement, personne ne pourrait t'en vouloir, c'est déjà énorme d'avoir mis à disposition cette librairie et tu ne vas pas passer ta vie gracieusement à notre service. Et ce jour là, je vivrai avec l'existant comme je le fais aujourd'hui avec d'autres applis
• Concernant Qt, je persiste à dire que c'est énorme par rapport à mes besoins, tout au plus, j'ai besoin d'afficher des fonds d'écran, d'y incorporer du texte, de faire des saisies, éventuellement afficher un camenbert et faire des transitions d'écran un peu sympa.
• Comme je l'ai signalé dans mon poste précédent, je viens de la programmation contrôleur, et avec une librairie qui part du pixel, je sais tout faire, je maîtrise tout, je peux assurer un résultat, je peux chiffrer un temps de réalisation, avec Qt, je n'y connais rien et je risque d'être incapable de fournir ces mêmes éléments
• maintenant vu tes réponses et ton avis encourageant sur la pérennité de Qt, je vais quand même m'y intéresser car c'est peut-être plus accessible que ça en a l'air ?
• N'empêche que je n'ai pas besoin de faire du multi fenêtrage, de déplacer des fenêtres, ... 34 modules, 1200 class, plus de 10000 fonctions... sic!
• C'est le genre de situation ou je risque de passer plus de temps à chercher comment interdire le déplacement d'une fenêtre qu'à la créer de toute pièce 

si les contraintes hardware et softwares le permettent, j'utiliserais Qt sans hésiter

Une dernière question parce que ça devient du Qt, quelles sont les contraintes auxquelles tu penses ? puissance CPU ? taille mémoire ?

En attendant, un grand merci pour tes conseils.

[Cpl.Bator]

La 2.0 va sortir donc ne sera ni fiable ni robuste (la 2.9 le sera peut-être, dans quelques années).

 

Heu... , c'est une blague ? qu'entend tu par là ? tu doutes de ton propre code ? je ne te suis pas du tout là. 

[gaudon]

Douter de soi est souvent le lot des grands talents 

[minirop]

Heu... , c'est une blague ? qu'entend tu par là ? tu doutes de ton propre code ? je ne te suis pas du tout là. 

je dirais juste qu'il est conscient/réaliste.

y'a une diff entre un truc testé et éprouvé depuis de longue années (genre Qt) et une lib dév par un seul homme sur son temps libre (et utilisé à bcp moins grande échelle).
suffit de voir les bugs (notamment ceux de la 1.6).

[Laurent]

Premièrement, si je venais à choisir SFML et que tu arrêtais son développement, personne ne pourrait t'en vouloir, c'est déjà énorme d'avoir mis à disposition cette librairie et tu ne vas pas passer ta vie gracieusement à notre service. Et ce jour là, je vivrai avec l'existant comme je le fais aujourd'hui avec d'autres applis

Le problème, c'est qu'à ce moment l'existant sera dans un état indéterminé de maintenance. Il y aura peut-être des bugs, des trucs en chantier, etc.

Concernant ton point de vue sur l'énormité de Qt et tes besoins relativement bas-niveau et bien ciblés, je comprends tout à fait. Le mieux sera sans doute que tu te fasses ta propre opinion sur Qt, si toutefois tu peux te le permettre.

Une dernière question parce que ça devient du Qt, quelles sont les contraintes auxquelles tu penses ? puissance CPU ? taille mémoire ?

Ca, et puis surtout il faut voir si Qt est supporté sur la plateforme que tu envisages d'utiliser.

Heu... , c'est une blague ? qu'entend tu par là ? tu doutes de ton propre code ? je ne te suis pas du tout là.

Il faut bien se rendre compte qu'une version 2.0 c'est le tout début d'un nouveau cycle. Les versions suivantes, jusqu'à la 3.0, ne serviront qu'à corriger et améliorer. Du coup 2.0 sera la moins robuste et fiable de la série, forcément. Faut pas voir ça comme une version ultime, mais comme un premier jet d'une nouvelle API.

[gaudon]

Bonjour,

Laurent:

Concernant ton point de vue sur l'énormité de Qt et tes besoins relativement bas-niveau et bien ciblés, je comprends tout à fait. Le mieux sera sans doute que tu te fasses ta propre opinion sur Qt, si toutefois tu peux te le permettre.

Bien dit, et pour ça il y a le forum de Qt 

minirop:

y'a une diff entre un truc testé et éprouvé depuis de longue années (genre Qt) et une lib dév par un seul homme sur son temps libre (et utilisé à bcp moins grande échelle).
suffit de voir les bugs (notamment ceux de la 1.6).

Je précise quand même qu'il s'agit d'IHM, et que ça n'engage pas la sécurité de la machine.
J'ai fais un parallèle brut (voir osé) avec les besoins de l'armée pour expliquer la maintenabilité, mais pour le reste je n'en ai pas les contraintes, et les moyens ne seraient pas les mêmes :-)

Question: Et la SDL, la considérez-vous comme (plus) fiable ? 
En bref, entre l'usine Qt et l'outil d'un seul homme, vous verriez quoi comme milieu ?

Merci

[Laurent]

Et la SDL, la considérez-vous comme (plus) fiable ?

De par son âge et son utilisation largement éprouvée, forcément oui. Maintenant on parle de SDL 1.2. SDL 1.3/2.0 ce sera un peu le même délire que SFML 2.0.

[Cpl.Bator]

Désolé du HS. c'est ma dernière "dérive" du sujet.

je dirais juste qu'il est conscient/réaliste.

y'a une diff entre un truc testé et éprouvé depuis de longue années (genre Qt) et une lib dév par un seul homme sur son temps libre (et utilisé à bcp moins grande échelle).
suffit de voir les bugs (notamment ceux de la 1.6).

Peut être, mais le dev n'est pas non plus un lapin de six semaines , sinon on ne serais pas là.
entre pas robuste / pas fiable et quelques bugs , y a une différence, les mots ont un sens.

Il faut bien se rendre compte qu'une version 2.0 c'est le tout début d'un nouveau cycle. Les versions suivantes, jusqu'à la 3.0, ne serviront qu'à corriger et améliorer. Du coup 2.0 sera la moins robuste et fiable de la série, forcément. Faut pas voir ça comme une version ultime, mais comme un premier jet d'une nouvelle API

Je préfère lire cela Encore désolé du hs, j'allais pas faire un topic pour ça.
 

[Laurent]

C'était même pas forcément du HS, la fiabilité et la robustesse font partie des arguments clés de cette discussion