Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 6 sur 17 PremièrePremière ... 234567891016 ... DernièreDernière
Affichage des résultats 101 à 120 sur 324
  1. #101
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 661
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 661
    Points : 15 972
    Points
    15 972

    Par défaut

    Citation Envoyé par fcharton Voir le message
    (Et puis, un framework ou il faut un graphiste et un programmeur, ce n'est pas une avancée : ca augmente le cout de développement...)

    Francois
    Citation Envoyé par JolyLoic Voir le message
    En pratique, c'est un framework où il faut un programmeur pour faire un programme fonctionnel. Si en plus, on veut un programme qui soit sexy, à la dernière mode, alors on peut prendre en plus un graphiste, et ce dernier pourra bosser en grande partie sans embêter les programmeurs à leur demander d'écrire du code pour changer l'aspect, ou à s'entendre dire que ses projets d'IHM sont très jolis mais trop chers.
    Je plussoie avec Loïc, car tu semble avoir "zappé" le mot le plus important : éventuellement...

    Lorsque je crées une IHM, j'ai tendance à être affreusement conventionnel sur la présentation que je lui donne, tout comme, lorsque je code un site web, il est techniquement très au point, mais il reste très (trop ) conventionnel, mais je le dis sans honte: mon dada, c'est la technique.

    Par contre, dans certaines conditions, il *peut* être intéressant de s'adjoindre les services d'un designer.

    Il n'a pas besoin de s'attaquer au coté technique de la chose (ca, c'est mon domaine), mais son rôle est "de faire du joli".

    Le risque, si il vient à s'occuper de modifier le code pour atteindre son objectif, c'est qu'il bousille purement et simplement "le reste".

    Dans le meilleur des cas, il me demandera de modifier le code pour refléter ses décisions... Alors que je suis occupé à essayer d'apporter une solution à un problème bien plus grave que le simple fait de "faire joli".

    Si nous pouvons séparer l'apparence des éléments affichables de la manière dont ils réagissent, un gars plutôt conventionnel pourra parfaitement faire son interface conventionnelle, mais une boite disposant d'un "IHM designer" pourra parfaitement faire appel à ses talents, sans que cela n'intervienne sur la partie métier de la chose.

    S'il est possible de dire qu'un bouton doit être rose bonbon, rond, avec une police de caractères Ghotic au lieu d'être un bête bouton carré, sur une nuance de gris avec la police de caractères par défaut sans que cela n'implique que celui qui décide de changer l'apparence du bouton ne doive venir mettre "ses sales pattes pleines de doigts" dans mon code, cela ne pourra être considéré que comme un avantage
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  2. #102
    Nouveau Membre du Club
    Inscrit en
    novembre 2009
    Messages
    64
    Détails du profil
    Informations forums :
    Inscription : novembre 2009
    Messages : 64
    Points : 32
    Points
    32

    Par défaut

    Comme l'a justement vu fcharton, j'ai fait exprès de mettre des exemples bien tordus qui :
    1/ ne reposent que sur le moteur de rendu (et pas de methode paint heritee) (j'avais lu le poste de Klaim sur la separation du moteur rendu)
    2/ ne reposent que sur l'interface d'entree. (vrpn anyone ?)

    En fait les 2 exemples ne remettent pas en cause la notion de widget.

    C'était juste pour dire, qu'il est souvent préférable de donner des idées en l'air pour ensuite se poser la question : est-ce que tel resultat est faisable ? est-ce que cela remet en cause mon framework? Est-ce que je considère que tel effet ou effet ne m'intéressent pas (pour borner le projet)?

    koala, tu as raison, il n'y a pas que FLTK dans la vie .

  3. #103
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 661
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 661
    Points : 15 972
    Points
    15 972

    Par défaut

    Citation Envoyé par ElPedro Voir le message
    Comme l'a justement vu fcharton, j'ai fait exprès de mettre des exemples bien tordus qui :
    1/ ne reposent que sur le moteur de rendu (et pas de methode paint heritee) (j'avais lu le poste de Klaim sur la separation du moteur rendu)
    2/ ne reposent que sur l'interface d'entree. (vrpn anyone ?)

    En fait les 2 exemples ne remettent pas en cause la notion de widget.

    C'était juste pour dire, qu'il est souvent préférable de donner des idées en l'air pour ensuite se poser la question : est-ce que tel resultat est faisable ? est-ce que cela remet en cause mon framework? Est-ce que je considère que tel effet ou effet ne m'intéressent pas (pour borner le projet)?
    Ca semble plaider en faveur d'une séparation nette entre les différents aspects que sont le rendu, la gestion des périphériques et la déclaration des éléments...

    Car, dans l'absolu, si les trois sont clairement séparés, il devient parfaitement possible d'utiliser "quelque chose de similaire", par exemple, faisant appel à "un autre système de pointage" que la souris ou à un affichage 3D.

    Au pire, la seule contrainte que nous aurons sera... d'assurer la présence d'une interface commune pour les différents aspects
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  4. #104
    Expert Confirmé Sénior
    Avatar de Luc Hermitte
    Profil pro
    Inscrit en
    août 2003
    Messages
    4 636
    Détails du profil
    Informations personnelles :
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : août 2003
    Messages : 4 636
    Points : 6 142
    Points
    6 142

    Par défaut

    (j'ai aussi lu en diagonale de retour de vacances)

    Citation Envoyé par koala01 Voir le message
    1. Existe-t-il un framework d'IHM de ce style (adam et eve, peut être )
    2. Si la réponse à (1) est "non", y aurait-il un intérêt quelconque à proposer un tel framework
    3. Quels seraient difficultés majeurs rencontrées lors de la mise au point d'un tel projet
    4. Trouveriez vous, par exemple, un intérêt quelconque à pouvoir créer un "data grid" basé sur des template, un peu comme n'importe quelle collection de la STL
    5. Certains d'entre vous seraient-ils intéressés par le fait de collaborer à un tel projet s'il était lancé
    Pour l'instant, je lance une idée en l'air, histoire de voir ce qui en ressortira avant de faire le tri. N'hésitez donc pas à donner votre avis, ni à justifier et commenter vos réponse, et encore moins à faire des propositions
    1- En effet, Adobe.ASL me parait répondre à la question.

    2,4- L'intérêt premier d'Adobe.ASL est le côté declarative UI. Après qu'ils aient pris une approche templatisée et DRY (ils s'appuient sur boost et sur Intel TBB) est un bonus.

    3- Ne pas se décourager pour fournir un ensemble de widgets tout aussi riches. Cela fait bien un à deux ans qu'il n'y a plus rien eu sur Adobe.ASL
    Autre difficulté: la portabilité. Je ne parle pas du support de plateformes de compilation antédiluviennes[*], mais de portabilité des éléments graphiques.

    5- Je ne pense pas en avoir le temps. En revanche je ne peux que vous conseiller de jeter sérieusement un oeil à adobe.ASL. Pas en termes de code, mais d'abord en termes d'articles. Il me parait plus intéressant de contribuer à de l'existant que de repartir from scratch. Ce double framework répond à l'essentiel de vos besoins non-discutables. C'est juste qu'il n'y a personne pour travailler dessus et continuer de le faire vivre, ce qui est fort dommage je trouve.


    EDIT:[*] J'estime qu'il faut viser C++03. Même s'il est vrai que les rvalue-references vont rendre complètement désuètes les approches COW de Qt, et une autre à la auto_ptr d'Ultimate++ (à moins que ce fut-ce un autre framework)
    FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média.

  5. #105
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 661
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 661
    Points : 15 972
    Points
    15 972

    Par défaut

    Citation Envoyé par Luc Hermitte Voir le message
    (j'ai aussi lu en diagonale de retour de vacances)
    Etaient-elles bonnes (bon, évitons ce genre de digressions )

    Ceci dit, ce que tu as écrit au sujet de ASL m'interpelle, dans le sens où je me pose plein de questions sur le sujet...

    Par exemple, il semblerait (à lire les "release notes" que l'un des responsables du projet ait quitté adobe. Serait-ce une des raisons de la désertion du projet

    Si le projet était si bien (et je ne met pas sa qualité en cause), qu'est-ce qui fait qu'il soit resté d'un usage "si confidentiel", et qu'il semble destiné à tomber dans l'oubli Pourrait-ce être à cause du désintérêt d'adobe pour le sujet

    N'aurait il pas été mieux servi par une équipe croyant dans le projet ne se dispersant pas dans toutes les directions dans lesquelles adobe se lance (entre flash, flex, et toutes ses applications, il y a déjà tellement de boulot )

    Serait il vraiment plus simple de "déterrer" un projet pour le faire revivre que de lancer quelque chose de neuf avec une équipe nouvelle

    Nous pourrions en effet envisager de lancer une campagne rédactionnelle sur le projet (essayer de trouver plusieurs rédacteurs qui feraient des articles dessus), mais serait-ce suffisant pour en raviver l'intérêt

    Peut être pourrions nous réfléchir à cette série de questions... Peut-être ne serait-ce qu'une "perte de temps".

    Pour ta dernière remarque, je voudrais préciser que nous partirions carrément sur du C++11, quitte à voir jusqu'où il serait possible de faire remonter la compatibilité ascendante avec d'anciennes plateformes.

    Pour l'instant, aucune décision ferme n'a encore été prise de lancer le projet dont nous parlons ici, il est donc tout à fait possible d'effectuer un virage à 180°.

    Simplement, il me semble utile de prendre la décision maintenant, autrement, cette discussion s'éternisera et ne sera plus qu'une perte de temps pour tous les intervenants, au même titre que bon nombre de discussions stériles que l'on trouve sur le forum.

    Comme je l'ai dit, je suis (et je reste) disposé à tenter l'aventure, mais j'ai trop bien conscience de l'ambition du projet pour ne serait-ce qu'espérer le mener à bien tout seul.

    Il serait peut être temps de mettre un GO ou un NO GO, histoire de voir si on décide d'aller plus loin en commençant l'écriture des spécifications ou si on se sert la main en se promettant de s'écrire...

    Même en gardant en tête le manque de temps flagrant de tous ceux qui se sont exprimés, si chacun peut, à son niveau, participer non pas régulièrement mais au moins ponctuellement, je vous répète ma conviction qu'il y a moyen d'y arriver... Simplement, je n'y arriverai pas tout seul.

    Qui me suit qui passe "à autre chose"
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  6. #106
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par koala01 Voir le message
    Je plussoie avec Loïc, car tu semble avoir "zappé" le mot le plus important : éventuellement...
    Je ne suis pas très futé, mais je l'avais quand même lu...

    Tous les frameworks actuels, quels qu'ils soient, permettent des skins (sous différentes formes), qui font que, si on a un graphiste, on peut facilement améliorer l'interface (enfin, si le développeur est au courant de cette possibilité et l'a déjà prise en compte).

    Un nouveau framework doit permettre cela, mais ce n'est pas innovant. Ce qui le serait davantage, ce serait de permettre au développeur de faire joli (à partir de modeles prédéfinis et facilement modifiables et réutilisables) à partir d'une bête charte graphique, et sans graphiste.

    Parce qu'à mon avis, il y a bien plus de projets qui n'ont pas de graphistes que de projets qui en ont...


    Plus généralement, le problème que je vois à cette approche, c'est l'idée qu'on peut joliment séparer données et traitements (cf la discussion sur les callbacks), que du moment qu'on a une approche déclarative, alors tout devient paramétrable (ben voyons), et que la "vue d'artiste" peut s'intégrer sans douleur dans un framework, sans qu'il y ait de trade offs avec la "développabilité" de celui ci, ou ses performances.

    L'idée que tout est séparable ne survit jamais longtemps à la réalité,

    - soit parce certaines choses, veut veut pas, sont malgré tout liées (eg le moteur de rendu agnostique... tôt ou tard on bute sur les primitives de l'OS, ou le système d'entrée qui a "tout prévu"),
    - soit parce que le cout de cette séparation, en terme d'accroissement de la complexité du framework, est prohibitif,
    - soit parce que même si "ce serait bien" de pouvoir tout séparer, on veut surtout que les choses restent liées par défaut (c'est ma principale objection à pas mal d'UI déclaratives : la quantité de code qu'il faut taper pour produire un truc moche reste assez impressionnante, et comme le code n'est pas destiné aux programmeurs eux mêmes, ceux ci ont un peu tendance à ne pas le rendre très amical)

    Je suis probablement déformé par mon expérience de FLEX, mais le peu que j'ai vu de l'approche d'ADOBE dans ce domaine me suggère que c'est plus un anti-modèle qu'un modèle...

    Francois

  7. #107
    Membre expérimenté Avatar de Lavock
    Inscrit en
    octobre 2009
    Messages
    560
    Détails du profil
    Informations forums :
    Inscription : octobre 2009
    Messages : 560
    Points : 543
    Points
    543

    Par défaut

    Je suis pas bien renseigner dans le monde des IHMs, mais adam&eve n'aurai-il pas un très fort rapport avec adobe asl ?

    Sinon, je vais de regarder vite fait adobe asl, il semble qu'il ne respecte pas un des principes de base de Koala's mushrooms (!?!) => ils utilisent boost d'un côté, mais semble re-écrire de ses parties de l'autre. Je peux me tromper, j'ai vraiment regarder rapidement.

    Pour le côté ultra-séparatiste (déclaration/affichage/io) cela ne tendrait pas à carrément annihiler le principe même du widget ?

    C'est une impression, mais les widget sont utiles car justement il borne, fonctionnellement et visuellement paralant, un élément qu'on va afficher. Or final, j'ai l'impression qu'on se retrouve avec :

    • Je déclare une zone
    • Qui à l'air de ça
    • Dont les "données" sont là
    • Sachant qu'il se passe ça sur mes données lors de tel event

    Où sont les widgets ? Dans le "Je déclare une zone" ? J'ai pas l'impression. Dans les données ? pas vraiment non plus.

    Si c'est juste pour les timelines, je dirais : Mais minces ! Et si j'ai envie qu'une de mes zones perdurent alors que la "contenante" meurt ?
    Pire, dans la plus part des cas, j'ai besoin de garder toutes les info tel quel, mais de juste arrêter d'éxecuter l'affichage... Et parfois, j'ai besoin uniquement de quelque swap.
    Au final, chaque timelines devrait pouvoir être gérait individuellement non ?


    Donc du coup, je me demande quel est la place des "widgets" en considérant une tel architecture? Ai-je manqué quelque chose ? Vous l'avez peut-être "naturellement" pris en compte vu vos niveau par rapport au mien, mais j'avoue que ça me laisse perplexe.

    En même temps, je suis peut-être juste à côté de la plaque :/

    [edit] Honnêtement et humblement, j'ai envie de dire GO :p
    The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.
    --Wilhelm Stekel

  8. #108
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par Lavock Voir le message
    Pour le côté ultra-séparatiste (déclaration/affichage/io) cela ne tendrait pas à carrément annihiler le principe même du widget ?
    En fait, pas forcément... Tu peux imaginer l'approche de séparation en termes de drivers.

    La séparation, c'est le fait qu'on communique avec le "matériel" (périphériques de saisie ou moteurs de rendu) au travers d'une API spécifique, que chaque matériel doit alors implémenter. On a alors un problème nouveau : quelle taille pour cette API, trop petite, elle ne permettra pas d'utiliser les nouvelles fonctionnalités des périphériques, trop grande, elle devient difficile à mettre en oeuvre. Cette approche par driver est une application du principe de Koenig (le niveau d'indirection supplémentaire)

    Mais le fait qu'on sépare ne signifie pas la mort du widget : quelque part, ton interface, déclarative, arborescente, ou en forme de poire, sera constituée d'éléments "atomiques" (classes, templates, ou schmurtzs), qui seront chargés (au travers de callbacks, de données membres, de traits,...) d'appeler l'API de rendu (ou de saisie).

    C'est ça, les widgets...

    Francois
    (qui trouve que la discussion est encore bien trop imprécise pour dire GO ou NO GO, mais peut être que ca veut juste dire GO sans lui)

  9. #109
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 661
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 661
    Points : 15 972
    Points
    15 972

    Par défaut

    Citation Envoyé par fcharton Voir le message
    Je ne suis pas très futé, mais je l'avais quand même lu...
    Je ne voulais absolument pas sous entendre que tu n'étais pas futé...

    Si telle est l'impression que j'ai donnée, je t'en fais toutes mes excuses les plus sincères
    Tous les frameworks actuels, quels qu'ils soient, permettent des skins (sous différentes formes), qui font que, si on a un graphiste, on peut facilement améliorer l'interface (enfin, si le développeur est au courant de cette possibilité et l'a déjà prise en compte).
    Peut-être ne vais-je raler que sur la manière dont c'est abordé par l'existant, mais, quand on voit les RAD existant, on se rend compte que tout est systématiquement accessibles à tous:

    Les propriétés propres à la seule apparence d'un élément visuelles côtoient allègrement les attributs purement fonctionnels (comme la possibilité de changer ou non la valeur d'un champs), quand il n'est pas possible (eg comme sous borland) d'aller "titiller" directement les événement auxquels l'élément doit réagir.

    Et, bien souvent, la création d'un widget personnalisé passe par... la programmation pure et simple: si on veut créer une data grille perso, il faut... se taper du code C++ pour tout (ou peu s'en faut).
    Un nouveau framework doit permettre cela, mais ce n'est pas innovant. Ce qui le serait davantage, ce serait de permettre au développeur de faire joli (à partir de modeles prédéfinis et facilement modifiables et réutilisables) à partir d'une bête charte graphique, et sans graphiste.
    d'accord, mais qu'est-ce qui empêcherait, justement, que ce soit un graphiste (ou n'importe qui "pas trop maladroit en dessin") qui propose ces modèles prédéfinis

    Si "n'importe qui" peut sauvegarder l'apparence d'un objet visuel, dans un format donné éventuellement généré par ailleurs), son utilisation peut être aussi simple que d'utiliser un menu "nouveau->selon modèle"...
    Plus généralement, le problème que je vois à cette approche, c'est l'idée qu'on peut joliment séparer données et traitements (cf la discussion sur les callbacks), que du moment qu'on a une approche déclarative, alors tout devient paramétrable (ben voyons), et que la "vue d'artiste" peut s'intégrer sans douleur dans un framework, sans qu'il y ait de trade offs avec la "développabilité" de celui ci, ou ses performances.
    Le fait de croire que la séparation des différents aspects permet de tout résoudre et de lever toutes les limites s'apparente très certainement à une utopie, je te l'accorde.

    Par contre, si l'on arrive à appliquer une séparation claire et maximale entre les différents éléments, nous pouvons arriver à lever un nombre important de restrictions.

    La plupart du temps, les restrictions qui ne sont pas dues au matériel utilisées sont beaucoup plus dues aux dépendances dont souffre un aspect donné qu'à l'aspect lui-même.

    Limitons les dépendances entre les trois aspects, nous lèverons de facto une bonne partie des restrictions dans chacun d'eux
    L'idée que tout est séparable ne survit jamais longtemps à la réalité,
    C'est pourtant l'un des principes récurrent de la programmation, quel que soit le côté d'où l'on regarde, c'est toujours du "diviser pour mieux régner"
    - soit parce certaines choses, veut veut pas, sont malgré tout liées (eg le moteur de rendu agnostique... tôt ou tard on bute sur les primitives de l'OS, ou le système d'entrée qui a "tout prévu"),
    Il y a, effectivement, certaines limites insurmontables: vouloir créer un élément affichable en 3D alors que le moteur de rendu ne fonctionne qu'en 2D parrait... irréalisable

    C'est la raison pour laquelle il me semble important de prévoir, à terme, la possibilité de la mise au point d'autres moteurs de rendus ou d'autres système d'entrées...

    Tu auras, fatalement, des modèles qui ne pourront pas fonctionner avec un moteur donné, mais il "suffira" de brancher l'autre.

    Cela pourrait simplement passer par l'utilisation d'une bibliothèque partagée différente
    - soit parce que le cout de cette séparation, en terme d'accroissement de la complexité du framework, est prohibitif,
    Ce sera peut être le cas... ou pas...

    Tant que nous ne serons pas en période de conception, il sera difficile de répondre à cette question
    - soit parce que même si "ce serait bien" de pouvoir tout séparer, on veut surtout que les choses restent liées par défaut (c'est ma principale objection à pas mal d'UI déclaratives : la quantité de code qu'il faut taper pour produire un truc moche reste assez impressionnante, et comme le code n'est pas destiné aux programmeurs eux mêmes, ceux ci ont un peu tendance à ne pas le rendre très amical)
    C'est à nous, développeurs, de veiller à ce que ce qui ne nous est pas "directement destiné" reste malgré tout amical...

    Je me sens totalement capable de faire respecter ce point

    (dois-je avouer que je risque d'être chiant en supprimant à vue toute version qui ne respecte pas les règles qui seront imposées par les specs, une fois qu'elles seront écrites )
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  10. #110
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 661
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 661
    Points : 15 972
    Points
    15 972

    Par défaut

    Citation Envoyé par fcharton Voir le message
    (qui trouve que la discussion est encore bien trop imprécise pour dire GO ou NO GO, mais peut être que ca veut juste dire GO sans lui)
    Ou peut être que je me suis mal exprimé...

    Pour moi, le NO GO à l'heure actuelle serait plus proche de la décision de relancer ASL...

    Si, déjà, il venait à y avoir plus de réactions proches de "voyons si on peut ressusciter ASL", le NO GO serait évident...

    Si par contre, il reste un grand nombre de "je me laisserais bien tenter, mais...", le GO serait accepté sur le principe, et nous pourrions continuer à discuter sans que la décision de commencer ce nouveau projet ne soit remise en question dans dix pages de discussion

    Soit, nous décidons que c'est un projet qui vaut la peine d'être lancé, et nous essayons réellement de préciser tout ce qui doit l'être (car il y a sans doute encore beaucoup de points à aborder ) et ceux qui ne sont pas intéressés s'engagent, en tout cas, à ne plus venir avec des "oui, mais bon, MachinChose n'est pas si mal... pourquoi vouloir faire mieux" (*), soit on se dit que je suis sans doute un peu fou de vouloir "révolutionner" la manière dont les IHM sont créées, et la discussion est close

    J'ai l'impression que nous partons plutôt dans la première direction

    (*) Maintenant, s'il viennent avec des "tel truc n'est pas si mal, ce serait sympa de le prévoir", leur proposition sera étudiée avec tout le sérieux nécessaire
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  11. #111
    Membre émérite
    Inscrit en
    juin 2006
    Messages
    1 207
    Détails du profil
    Informations personnelles :
    Âge : 38

    Informations forums :
    Inscription : juin 2006
    Messages : 1 207
    Points : 926
    Points
    926

    Par défaut

    on voit malgré tout l'orientation XAML ou XUL d'une UI.
    moi meme j'ai vu l'HTML prendre le pas sur toutes les applis dans mon domaine (appli de gestion)

    d'ailleurs j'en suis venu a ne faire que de l'HTML / Javascript, meme pour des appli desktop. (flash pour quelques trucs plus waoo effects)

    j'adore le javascript, c'est dynamique et facile à faire plein de workaround pour des quick fixes.
    J'aime l'html car ca peut se redesigner en peu de temps et paraitre vraiment super sexy.

    maintenant pour faire des super transitions comme XAML, alors il faut utiliser des libs comme JQuery / JQuery-UI mais il faudra un peu plus de code.

    Sinon j'aime aussi bien Flash, on peut tout faire tres design et super animé,
    mais j'aime pas flex, je n'aime pas en general l'XML pour decrire ma scene.

    D'apres mon experience et les designers qui travaillent avec moi,
    ils designent tres bien (et uniquement) l'html (avec css etc) et le flash.

    Donc l'interface du futur ne serait-il pas un mixe de l'html / flash (timeline) et socle commun comme le javascript avec C++ (ou C#) backend
    (en vue du tout internet)

    ps: j'ai oublié de mentionner que pour moi une appli desktop devrait etre identique à une appli web server, ca a toujours été demandé par les clients (sorte de online/offline appli identiques)

  12. #112
    Membre chevronné Avatar de metagoto
    Hobbyist programmateur
    Inscrit en
    juin 2009
    Messages
    646
    Détails du profil
    Informations professionnelles :
    Activité : Hobbyist programmateur

    Informations forums :
    Inscription : juin 2009
    Messages : 646
    Points : 745
    Points
    745

    Par défaut

    Revenons aux fondamentaux:

    Le truc qui me chagrine (OK, j'exagere) c'est qu'il me parait bien vain de partir dans toutes les directions à propos de serialisation, de langage déclaratif, de stylesheets, de présence ou non de designer (qui ne va jurer que par l'iPhone et l'iPad), AVANT d'avoir étudier sérieusement les sub systems de windowing des OS dont on peut raisonnablement penser qu'ils doivent être supportés.

    Qui est expert en win32, gtk, cocoa, opengl etc ?
    Là je m'intéroge même: dans Windows 7, est-ce que win32 existe toujours ?

    Sans une parfaite compréhension des particularités intrinsèques de ces sub systems (api, messages pumps, gdi, threading, etc etc), on ne va pas aller bien loin

  13. #113
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro yan verdavaine
    Ingénieur expert
    Inscrit en
    mars 2004
    Messages
    9 955
    Détails du profil
    Informations personnelles :
    Nom : Homme yan verdavaine
    Âge : 32
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2004
    Messages : 9 955
    Points : 14 015
    Points
    14 015

    Par défaut

    Citation Envoyé par JolyLoic Voir le message
    J'ai un peu regardé tes liens (rapide survol), et j'aime bien le fait qu'ils n'ont pas choisi un truc lourdeau comme le XML comme base de leur declarative UI.
    moi aussi

    Citation Envoyé par JolyLoic Voir le message
    Par contre, même si j'ai vu des aspects liés au binding, je n'ai pas trop compris comment lier des éléments de l'IMH à des éléments du code, or ce fait est essentiel en WPF et est à la base du framework M-V-VM qui est recommandé avec lui (au lieu de MVC/MVP), et qui me semble mieux correspondre à ce que j'imagine d'une architecture d'IHM.
    Ce n'est pas aussi automatique qu'avec visual qui fait tout le travail. (qui permet d'exploiter les composante de xaml directement avec le code).

    Avec Qt Quick, c'est le développeur qui fournie les instances à l'engine. En simple qml est du script qui peut exploiter tes classes grâce au metadata.
    En soit, qml ne sait pas ce qu'il manipule juste qu'il veut utiliser quelque chose qui s'appel maClasse, qui as une propriété foo et une fonction bar().
    Développeur Windows 8, Windows phone 8 et Nokia Asha, inscrivez vous sur DVLUP

  14. #114
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 661
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 661
    Points : 15 972
    Points
    15 972

    Par défaut

    Citation Envoyé par epsilon68 Voir le message
    on voit malgré tout l'orientation XAML ou XUL d'une UI.
    moi meme j'ai vu l'HTML prendre le pas sur toutes les applis dans mon domaine (appli de gestion)

    d'ailleurs j'en suis venu a ne faire que de l'HTML / Javascript, meme pour des appli desktop. (flash pour quelques trucs plus waoo effects)

    j'adore le javascript, c'est dynamique et facile à faire plein de workaround pour des quick fixes.
    J'aime l'html car ca peut se redesigner en peu de temps et paraitre vraiment super sexy.

    maintenant pour faire des super transitions comme XAML, alors il faut utiliser des libs comme JQuery / JQuery-UI mais il faudra un peu plus de code.

    Sinon j'aime aussi bien Flash, on peut tout faire tres design et super animé,
    mais j'aime pas flex, je n'aime pas en general l'XML pour decrire ma scene.

    D'apres mon experience et les designers qui travaillent avec moi,
    ils designent tres bien (et uniquement) l'html (avec css etc) et le flash.

    Donc l'interface du futur ne serait-il pas un mixe de l'html / flash (timeline) et socle commun comme le javascript avec C++ (ou C#) backend
    (en vue du tout internet)
    Peut être parce que cette solution est... dépendante de la présence d'un navigateur web graphique

    Or, l'idée de base est, malgré tout, de permettre aux gens de... créer un navigateur web graphique s'ils le souhaitent (des fois qu'ils voudraient faire concurrence à IE et à firefox )

    ps: j'ai oublié de mentionner que pour moi une appli desktop devrait etre identique à une appli web server, ca a toujours été demandé par les clients (sorte de online/offline appli identiques)
    Ce point pourrait effectivement être beaucoup plus facile à mettre en oeuvre avec une approche d'IHM déclarative...

    Par exemple, en HTML, il est possible d'utiliser une partie de dessin pour représenter un bouton sans que la souris ne soit dessus et une autre partie du même dessin pour représenter le même bouton lorsqu'il est survolé par la souris, ou lorsque l'on clique dessus.

    L'IHM déclarative faciliterait ce genre de mise en oeuvre, même s'il ne faut pas se leurrer: il y aura très certainement nécessité de "convertir" les codes HTML et/ou CSS pour pouvoir les utiliser
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  15. #115
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 661
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 661
    Points : 15 972
    Points
    15 972

    Par défaut

    Citation Envoyé par metagoto Voir le message
    Revenons aux fondamentaux:

    Le truc qui me chagrine (OK, j'exagere) c'est qu'il me parait bien vain de partir dans toutes les directions à propos de serialisation, de langage déclaratif, de stylesheets, de présence ou non de designer (qui ne va jurer que par l'iPhone et l'iPad), AVANT d'avoir étudier sérieusement les sub systems de windowing des OS dont on peut raisonnablement penser qu'ils doivent être supportés.

    Qui est expert en win32, gtk, cocoa, opengl etc ?
    Là je m'intéroge même: dans Windows 7, est-ce que win32 existe toujours ?
    Tu sembles avoir loupé la partie de la discussion dans laquelle je disais qu'il n'était pas question de faire une surcouche de l'existant (enfin, en ce qui concerne gtk et cocoa)...

    Même en ce qui concerne openGL, ce sera quelque chose qui ne viendra que "plus tard" (lorsque le reste fonctionnera avec les primitives OS).

    Ce qui serait bien plus intéressant, c'est de savoir qui maitrise suffisemment Xorg ou GD+

    Et encore, avant d'en arriver au codage, il semble important:
    • d'écrire les spécifications fonctionnelles
    • d'écrire les spécifications techniques
    • d'effectuer la conception de base
    Or, nous n'en sommes même pas encore tout à fait la (nous sommes encore au stade où l'on réfléchit à ce qui devra se trouver dans les spécifications [EDIT]voir même de savoir, simplement, s'il vaut la peine de commencer à écrire les spécifications...[/EDIT])
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  16. #116
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par epsilon68 Voir le message
    ps: j'ai oublié de mentionner que pour moi une appli desktop devrait etre identique à une appli web server, ca a toujours été demandé par les clients (sorte de online/offline appli identiques)
    En terme de look, oui, mais en terme de logique applicative, surement pas... En gros, ce qui fait la qualité d'une appli desktop (on a le moteur de calcul sous la main, on peut faire plein de petits calculs vite fait), est complètement différent de ce qui fait l'intéret d'une appli web (données décentralisées et uniques, sécurité des accès, mais contrainte sur la bande passante des échanges).

    Pour une appli un tant soi peu compliquée (en termes de volumes de calculs ou de données), une même appli web et desktop, c'est la garantie d'un truc inefficace dans les deux domaines. (C'est un peu ce qui condamne AIR, chez Adobe)

    A mon avis, un framework d'IHM est ici un framework desktop. On peut lui donner un "look web", mais c'est tout ce qu'il aura de web.

    Francois

  17. #117
    Expert Confirmé Sénior
    Avatar de Luc Hermitte
    Profil pro
    Inscrit en
    août 2003
    Messages
    4 636
    Détails du profil
    Informations personnelles :
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : août 2003
    Messages : 4 636
    Points : 6 142
    Points
    6 142

    Par défaut

    Citation Envoyé par koala01 Voir le message
    Par exemple, il semblerait (à lire les "release notes" que l'un des responsables du projet ait quitté adobe. Serait-ce une des raisons de la désertion du projet
    J'ai l'impression qu'il s'agit au départ d'un projet interne qu'ils ont ouvert pour des raisons qui étaient les leurs.

    Un petit lien sympa.
    http://stackoverflow.com/questions/1...699225#1699225

    Citation Envoyé par koala01 Voir le message
    Si le projet était si bien (et je ne met pas sa qualité en cause), qu'est-ce qui fait qu'il soit resté d'un usage "si confidentiel", et qu'il semble destiné à tomber dans l'oubli
    Avec un responsable en moins et une forte concurrence, plus une utilisabilité suffisante pour leurs besoins, je ne suis pas étonné de l'état du projet. Contrairement à Trolltech, ce projet n'est pas leur coeur de métier. Juste une toolbox antibug (ma libre interprétation du tuto sur le site).
    Le côté révolutionnaire n'a pas dû aider. De même que le côté pas prêt pour de la production hors de chez Adobe.


    Citation Envoyé par koala01 Voir le message
    N'aurait il pas été mieux servi par une équipe croyant dans le projet ne se dispersant pas dans toutes les directions dans lesquelles adobe se lance (entre flash, flex, et toutes ses applications, il y a déjà tellement de boulot )
    Adobe est je pense une grosse boite. Je ne considère pas qu'il s'agisse plus d'une question de se disperser que ce que l'on voit avec google : ils ont leur labo.

    Citation Envoyé par koala01 Voir le message
    Serait il vraiment plus simple de "déterrer" un projet pour le faire revivre que de lancer quelque chose de neuf avec une équipe nouvelle
    Nous ne partons pas des mêmes hyppothèses :
    - ils ont des cadors qui ont bossé là dessus, et d'autres cadors dans les bureaux d'à côté (cf les noms attachés aux divers articles)
    - ils sont parti de leur retour d'expérience en tant qu'utilisateurs de framework IHM pour leur applis gourmandes (photoshop)
    - ils ont capitalisé une expérience (bonne ou mauvaise)
    - ils ont documenté quantité de choses
    - ils suivent les mêmes contraintes que ce que tu cherches à lancer (au détail sur C++11) -> DRY (SL/boost/Intel TBB), moderne, pas de super objet, les divers découplages mentionnés, portable, ...

    Donc, quiconque se lance dans un même projet a tout à gagner à analyser leur choix avant de se lancer tête baissée dans une direction, quelle qu'elle soit.

    J'aime bien commencer par un état de l'art chez les plus proches "concurrents".

    Bref avant de le relancer, regardons juste ce qu'ils font et comment ils le font. Même si ASL n'est pas relancé au final, je pense qu'il s'agira d'une étude intéressante et pertinente pour tous les choix faits qui répondent aux même besoins que ceux exprimés ici.

    @ lavock, Adam&Eve sont deux des sous-composant de Adobe.ASL. Adam est le moteur de contraintes (utilisé aussi pour résourdre des sudoku), et Eve un moteur de rendu. (IIRC).
    Ils ont patchés certaines choses dans boost, et écrits diverses choses. Certaines devaient être soumises chez boost. Dans tous les cas, il n'y a rien eu de redondant -- ils ont eu besoin de chaines 0-copie, ou des COW, ils en ont écrites, sinon ils réutilisent (c'est une autre différence avec Qt, parfois il y a une multiplication des types chaines au lieu d'imposer une approche qui n'est pas bonne tout le temps)
    FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média.

  18. #118
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par metagoto Voir le message
    Là je m'intéroge même: dans Windows 7, est-ce que win32 existe toujours ?
    L'API Win32 fonctionne encore sous 7 (heureusement!), il y a des trucs en plus, comme dans toute nouvelle version. Globalement, j'aurais tendance à dire qu'il faut partir de 2 ou 3 systèmes cibles (pas plus), windows, forcément (ca je connais un peu, toi aussi manifestement), linux sans doute (je ne sais pas mais je pense qu'on peut trouver quelqu'un).

    Maintenant, il n'y a pas besoin d'être un expert, juste de bien connaitre. Le but, c'est d'en savoir suffisamment sur les principes de fonctionnement pour éviter de prendre des décisions qui rendraient l'implémentation trop difficile dans tel ou tel système.

    Francois

  19. #119
    Modérateur
    Avatar de koala01
    Profil pro Philippe Dunski
    Inscrit en
    octobre 2004
    Messages
    9 661
    Détails du profil
    Informations personnelles :
    Nom : Philippe Dunski
    Âge : 42

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 661
    Points : 15 972
    Points
    15 972

    Par défaut

    Citation Envoyé par Luc Hermitte Voir le message
    Nous ne partons pas des mêmes hyppothèses :
    J'étais volontairement provoquant...

    Quoi de mieux pour provoquer des réactions
    Donc, quiconque se lance dans un même projet a tout à gagner à analyser leur choix avant de se lancer tête baissée dans une direction, quelle qu'elle soit.

    J'aime bien commencer par un état de l'art chez les plus proches "concurrents".

    Bref avant de le relancer, regardons juste ce qu'ils font et comment ils le font. Même si ASL n'est pas relancé au final, je pense qu'il s'agira d'une étude intéressante et pertinente pour tous les choix faits qui répondent aux même besoins que ceux exprimés ici.
    Tout à fait...

    Il y a, très certainement, énormément à apprendre de ce qu'ils ont fait, tout comme il y a à apprendre de ce que Qt ou WxWidget a fait, des problèmes auxquels ils ont été confrontés et des solutions qu'ils ont apportées

    Je dirais presque que leurs déboires sont plus importants que leur réussites, d'ailleurs
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  20. #120
    Membre expérimenté Avatar de Lavock
    Inscrit en
    octobre 2009
    Messages
    560
    Détails du profil
    Informations forums :
    Inscription : octobre 2009
    Messages : 560
    Points : 543
    Points
    543

    Par défaut

    Citation Envoyé par fcharton Voir le message

    Mais le fait qu'on sépare ne signifie pas la mort du widget : quelque part, ton interface, déclarative, arborescente, ou en forme de poire, sera constituée d'éléments "atomiques" (classes, templates, ou schmurtzs), qui seront chargés (au travers de callbacks, de données membres, de traits,...) d'appeler l'API de rendu (ou de saisie).

    C'est ça, les widgets...
    Hum, en fait, ça m'a plus embrouillé qu'autre chose. Les éléments "atomiques" comme tu les appelles seront au final dispersé. Qui aura la charge de se faire appeler widget ? Le tout ? dans se cas, c'est plus une notion super-abstraite qu'une existence réel ?

    @Luc : Merci pour les précisions
    The mark of the immature man is that he wants to die nobly for a cause, while the mark of the mature man is that he wants to live humbly for one.
    --Wilhelm Stekel

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •