Journal Jauges, indicateurs de niveau et autres widgets en GPL/Commercial

Posté par viridis (site web personnel) le 02 septembre 2009 à 15:49.

Étiquettes : aucune

sept.

2009

Bonjour à tous,

Tegesoft est fier de diffuser la première version publique (beta) de GICS, une bibliothèque proposant un ensemble d'instruments graphiques vectoriels ainsi qu'un framework simple permettant d'en concevoir d'autres (à l'aide de composants de base).

GICS, pour "Graphical Instruments and Components Solution" est développé en C++ et se base sur le module GraphicsView de Qt. GICS est disponible sous une licence GNU/GPL ou commerciale.

Cette première version, pouvant être vue comme une démo technologique, fournit un certain nombre d'instruments tels qu'une jauge, un indicateur de niveau, un bouton, un slider ou encore un LED. Ces instruments sont skinnables en SVG.

A noter que dans un futur proche, le système de skin va être entièrement revu :)

A noter également qu'une petit demo est disponible.

Enfin, GICS utilise le système de réflection (méta-classe/méta-propriété) CAMP également développé par Tegesoft sous licence GNU/GPL ou commerciale.

# Ah Qt...

Posté par Zenitram (site web personnel) le 02 septembre 2009 à 17:41. Évalué à 5.

Moi qui suis en train de migrer vers Qt, ça donne envie...

Une petite remarque : sous la version Windows du moins, l'ouverture d'une ligne de commande en parallèle et aucune icône dans la barre de tache ne fait pas très "pro"... Surtout que Qt permet d'éviter ça.
- [^] # Re: Ah Qt...
  
  Posté par viridis (site web personnel) le 02 septembre 2009 à 18:24. Évalué à 4.
  
  C'est juste un p'tit problème dans la conf cmake, ce sera corriger rapidement :)
  - [^] # Re: Ah Qt...
    
    Posté par viridis (site web personnel) le 02 septembre 2009 à 18:35. Évalué à 3.
    
    A noter aussi que la consommation CPU a été corrigée pour la prochaine version.
# Moche

Posté par yellowiscool le 02 septembre 2009 à 17:47. Évalué à 8.

êLes applications qui sont stylisées comme ça sont souvent moches par rapport aux mêmes applications qui utilisent le thème de l'utilisateur.
Envoyé depuis mon lapin.
- [^] # Re: Moche
  
  Posté par pampryl le 02 septembre 2009 à 18:15. Évalué à 6.
  
  C'est plus une histoire de coups et de douleurs ça...
- [^] # Re: Moche
  
  Posté par bubar🦥 (Mastodon) le 02 septembre 2009 à 18:18. Évalué à 4.
  
  Avis partagé aussi.
  
  Mais bémolé par le fait que je trouve ça sympa d'avoir sur mon bureau une ou deux appli qui "tranchent sur le look", s'il s' agit de widgets de bureaux par exemple.
  
  Le bordel de look, non
  mais une ou deux différentes, dans une unité d' ensemble, oui.
  
  L' unité oui,
  mais uniquement un look unifié, non.
  
  raaa ces michu, alors... :p
- [^] # Re: Moche
  
  Posté par viridis (site web personnel) le 02 septembre 2009 à 18:34. Évalué à 5.
  
  Comme mentionné dans le journal, GICS est doté d'un système de skin (qui sera amélioré sous peu) permettant d'adapter le style des instruments à d'autres applications/environnements. D'autres skins verront ainsi le jour avec, par exemple, des looks plus réel, plus multimédia, plus industriel...ou plus intégrés aux bureaux classiques.
  
  Il faut toutefois noter que le type d'instrument proposé par GICS est en général utilisé sur des applications en environnement industriels pour lesquels une ressemblance avec les instruments réels est souvent nécessaire (comme sur un pupitre de commande par exemple), d'où cette cassure avec le style habituel.
# CAMP

Posté par Gof (site web personnel) le 02 septembre 2009 à 18:19. Évalué à 4.

Quelle est la différence entre CAMP et le QMetaObject de Qt ?
- [^] # Re: CAMP
  
  Posté par Laurent le 02 septembre 2009 à 18:41. Évalué à 4.
  
  CAMP est un système beaucoup plus générique et poussé que les propriétés de Qt. Le système de QMetaObjects est relativement centré autour d'une utilisation bien précise et donc peu flexible.
  
  Quelques avantages de CAMP pêle-mêle :
  - non-intrusif pour la classe bindée
  - possibilité de binder des classes externes
  - pas besoin d'appartenir à une hiérarchie de QObject
  - pas besoin du précompilateur MOC
  - possibilité d'héritage multiple
  - on peut binder tout type de membre sans limitation, pas seulement des couples de getter/setter au prototype figé
  - les propriétés peuvent avoir des attributs et des tags dynamiques, qui peuvent servir à personnaliser et étendre le système au-delà de ce qu'il prévoit initialement
  - ...
# Bonne idée

Posté par GuieA_7 (site web personnel) le 02 septembre 2009 à 19:17. Évalué à 7.

Il y 2 ans et demi j'ai fait une régie pour un client afin de réaliser une appli de monitoring, plutôt orientée moteur de bateau. La précédente équipe avait codé une application utilisant Kylix je crois, et pour les widgets de monitoring, IOComp. L'équipe s'est lamentablement planté ; ils codaient certes comme des cochons, mais ils semble que les mauvaises performances des bibliothèques que j'ai citées ne soit pas pour rien dans cette échéc (quelle idée d'utiliser des saletés proprio aussi...).
Avec la nouvelle équipe nous sommes partis de zéro, en avons utilisé Qt (non sans avoir testé beaucoup de framework d'IHM). Nous avons notamment utilisé les possibilités de dessin vectoriel de Qt afin de coder des widgets spécifiques: jauges horizontales, verticales, cadrans etc... Le projet a été un succés (mon regret est bien entendu que tout cela reste du proprio), mais un projet tel que GICS aurait été le bienvenu à l'époque.

Tout ça pour dire que je pense que votre projet me semble clairement répondre à un réel besoin. Alors voir tout ça en libre me fait franchement plaisir. Je ne peux donc que vous souhaiter bonne chance pour la suite !!

Je vais quand même envoyer un mail à mon ancienne équipe pour leur indiquer l'existence de votre bibliothèque.
- [^] # Re: Bonne idée
  
  Posté par viridis (site web personnel) le 02 septembre 2009 à 19:29. Évalué à 3.
  
  Merci pour ces encouragements !
  
  Nous étions un peu dans la même situation et vu qu'aucune bibliothèque ne répondaient à nos besoins, nous nous sommes attaqués à GICS.
- [^] # Performances
  
  Posté par Pierre le 03 septembre 2009 à 12:28. Évalué à 1.
  
  ils codaient certes comme des cochons, mais ils semble que les mauvaises performances des bibliothèques que j'ai citées ne soit pas pour rien dans cette échec (quelle idée d'utiliser des saletés proprio aussi...).
  
  Chez moi, la demo prends un bon 100% du CPU...
  
  Par contre, c'est joli, l'effet de la fenêtre qui se retourne. Bon, en fait, ça clignote à mort, mais ca pourrait être très joli.
  - [^] # Re: Performances
    
    Posté par Laurent le 03 septembre 2009 à 12:50. Évalué à 1.
    
    Comme indiqué plus haut, le problème de consommation CPU a été corrigé récemment.
    
    Pour la fenêtre qui clignote, c'est sous quel OS ?
    Qt sous Mac OS X a des problèmes avec ce genre d'effet, qui seront d'ailleurs peut-être reglés avec la version 4.6.
    Sous Linux aussi on a quelques clignotements, mais là encore on suspecte le serveur X ou le WM plutôt que directement le code de la démo.
    Sous Windows aucun souci normalement.
# Les dependances

Posté par tanguy_k (site web personnel) le 02 septembre 2009 à 21:56. Évalué à 3.

Ce que je trouve dommage, c'est les dependances de GICS : il y a CAMP qui demande à son tour Boost.

Nokia fournit des widgets SVG du meme style
http://qt.nokia.com/developer/embedded-widget-demos
http://labs.trolltech.com/blogs/2009/03/23/embedded-widgets-(...)

Quel est la raison pour GICS d'avoir ces dependances ?
- [^] # Re: Les dependances
  
  Posté par Laurent le 03 septembre 2009 à 10:19. Évalué à 3.
  
  CAMP est la base du système de meta-propriétés. Alors évidemment on aurait aimé utiliser celui de Qt, mais lors de l'étude préliminaire on s'est vite rendus compte que ce dernier serait insuffisant, trop peu flexible (voir ma réponse à la question «différence entre CAMP et QMetaObject»).
  Quant à boost, c'est le minimum syndical pour des bibliothèques comme CAMP qui torturent le compilateur dans tous les sens.
  
  En ce qui concerne les widgets SVG présentés sur le site de Qt, c'est plus une démo qu'un outil. Il n'y a rien de vraiment intéressant autant au niveau API que technique, ils ont développé ça surtout pour montrer que l'on pouvait faire des trucs jolis avec Qt, du SVG et des feuilles de style. Mais il n'y a rien de vraiment réutilisable.
  GICS au contraire, fournit non seulement un ensemble d'instruments, mais surtout un framework complet et générique pour en développer des nouveaux très facilement.
  - [^] # Re: Les dependances
    
    Posté par tanguy_k (site web personnel) le 03 septembre 2009 à 12:54. Évalué à 1.
    
    Les dependances constituent un vrai frein a l'adoption. Personnellement, rien qu'a cause de Boost, je regarderais à 2 fois avant d'utiliser GICS si j'en avais besoin.
    J'ai du mal a imaginer pourquoi il faut tout ca pour faire du SVG et des CSS.
    - [^] # Re: Les dependances
      
      Posté par Laurent le 03 septembre 2009 à 13:06. Évalué à 3.
      
      Comme je l'ai dit on a besoin de boost principalement pour le système de meta-propriétés, qui constitue les fondations de tout le framework (un peu comme les propriétés Qt constituent la base de tout ce qui est à base de QObject). On ne fait pas que du SVG et du CSS, ça ce n'est que la partie personnalisation visuelle du framework.
      
      On a également besoin de boost pour les classes utilitaires classiques : pointeurs intelligents, conteneurs, ... Se passer de boost de nos jours est bien souvent une erreur, en tout cas un pas en arrière et une perte de temps, d'autant plus que bon nombre de ces classes vont figurer dans le prochain standard C++.
      - [^] # Re: Les dependances
        
        Posté par tanguy_k (site web personnel) le 03 septembre 2009 à 15:02. Évalué à 2.
        
        besoin de boost pour les classes utilitaires classiques : pointeurs intelligents, conteneurs, ...
        
        Ce que fournit deja Qt, mais j'imagine que vous voulez garder CAMP generique et donc independant de Qt, non ?
        
        [^] # Re: Les dependances
        
        Posté par Laurent le 03 septembre 2009 à 15:33. Évalué à 1.
        
        Tout à fait, mais de toute façon là je parlais de GICS ; CAMP quant à lui utilise tout un tas de modules de metaprogrammation que l'on ne retrouve que dans boost.
    - [^] # Re: Les dependances
      
      Posté par Mais qui suis-je ? :) le 04 septembre 2009 à 11:48. Évalué à 2.
      
      Je vois pas trop en quoi les dépendances sont le plus gros problème,
      La vraie question c'est la simplicité d'usage.
      
      Ca me semble le jours de librairie qui visent les gens qui concoivent des instruments et qui ont besoin de pondre une interface de controle/monitoring ou je ne sais quoi.
      Et pas un truc qui visent des informaticiens capable d'écrire leurs propre alternative a boost.
      
      Si les dépendances permettent d'écrire du code simple et efficace sans trop de fuite de mémoire même pour un utilisateur qui n'est pas developpeur c'est parfait.
      Si c'est plus cher hum, ben je suis pas convaincus de l'adoption massive de la chose !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.