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

Posté par  (site web personnel) .
Étiquettes : aucune
8
2
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  (site web personnel) . É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.

  • # Moche

    Posté par  . É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  . Évalué à 6.

      C'est plus une histoire de coups et de douleurs ça...

    • [^] # Re: Moche

      Posté par  (Mastodon) . É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  (site web personnel) . É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  (site web personnel) . Évalué à 4.

    Quelle est la différence entre CAMP et le QMetaObject de Qt ?

    • [^] # Re: CAMP

      Posté par  . É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  (site web personnel) . É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  (site web personnel) . É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  . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  (site web personnel) . É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  . É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  . É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.