Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 7 sur 17 PremièrePremière ... 34567891011 ... DernièreDernière
Affichage des résultats 121 à 140 sur 324
  1. #121
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par Lavock Voir le message
    c'est plus une notion super-abstraite qu'une existence réel ?
    C'est pourtant ce que tu vas présenter à l'utilisateur, non? Une interface formée de "composants" qui peuvent avoir des données, recevoir des sollicitations clavier ou souris (ou tout autre périphérique de saisie), et s'afficher.

    Ces composants devront bien avoir une existence dans le système, des types paramétrés probablement (puisqu'on ne les fait pas descendre d'un superWidget). Mais l'implémentation de leurs données, de leur dessin, et de leur interaction saisie seront déléguées, en vertu de la séparation...

    C'est peut être juste moi, mais j'ai beaucoup de mal à imaginer un modèle d'IHM qui n'utilise pas des widgets (quelqu'autre nom qu'on leur donne), ou alors on tombe dans l'interface "totalement dessinée" des jeux vidéos, qui s'apparente davantage à une vidéo calculée en runtime qu'à une IHM (et qu'on pourrait même considérer, dans un modèle à widget comme un widget unique).

    Peut être est ce un point sur lequel on peut statuer assez vite, d'ailleurs.

    Y a-t-il d'autres options? En veut on?

    Francois
    Dernière modification par Invité ; 06/04/2010 à 20h17.

  2. #122
    Membre Expert
    Inscrit en
    juin 2006
    Messages
    1 214
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : juin 2006
    Messages : 1 214
    Points : 1 015
    Points
    1 015

    Par défaut

    Citation Envoyé par fcharton Voir le message
    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.
    Je ne suis pas d'accord.
    bon je ne parle pas d'opengl ou de gerer 150'000 objets
    mais d'une interface de gestion de données.

    afficher des tables, masque de saisie, presentation de données etc
    et bien la c'est tout a fait possible et c'est rapide.
    Je le fais deja avec Qt webkit.

    d'ailleurs Qt fait toutes les approches:
    1. la standard (widgets / layout / signal-slot)
    2. QML (XAML, XUL etc)
    3. webkit (html css javascript)

    je suis plus dans la 3ieme solution, et ca marche vraiment bien.

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

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 743
    Points : 17 226
    Points
    17 226

    Par défaut

    Je crois qu'il serait temps de recommencer à faire les bonnes choses avec les bons outils...

    L'utilisation de webkit n'a vraiment de sens que dans l'optique d'une application... utilisant le réseau...

    C'est un système génial, il faut bien l'avouer, mais, il n'en demeure pas moins que c'est prévu pour... déléguer une partie de la gestion au serveur qui se trouve à l'autre bout.

    Commencer à utiliser webkit alors que tout se trouve sur le même ordinateur, dans le même dossier (ou tout comme) est proche de l'aberration, pour ne pas dire de l'hérésie.
    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. #124
    Membre Expert
    Inscrit en
    juin 2006
    Messages
    1 214
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : juin 2006
    Messages : 1 214
    Points : 1 015
    Points
    1 015

    Par défaut

    Citation Envoyé par koala01 Voir le message
    Je crois qu'il serait temps de recommencer à faire les bonnes choses avec les bons outils...

    L'utilisation de webkit n'a vraiment de sens que dans l'optique d'une application... utilisant le réseau...

    C'est un système génial, il faut bien l'avouer, mais, il n'en demeure pas moins que c'est prévu pour... déléguer une partie de la gestion au serveur qui se trouve à l'autre bout.

    Commencer à utiliser webkit alors que tout se trouve sur le même ordinateur, dans le même dossier (ou tout comme) est proche de l'aberration, pour ne pas dire de l'hérésie.
    encore une fois pas d'accord.
    webkit est un moteur d'affichage, rien de plus.

    si tu comprend XAML alors tu comprends que HTML est aussi un langage descriptif, et qu'il faut dans les deux cas un moteur d'affichage. Et bien pour l'html, j'en connais au moins un: Webkit

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

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 743
    Points : 17 226
    Points
    17 226

    Par défaut

    J'ai honnêtement l'impression que je perdrais mon temps si j'essayais de te faire comprendre que HTML est, certes, un langage descriptif, mais qu'il a été créé pour une raison précise, afin de résoudre une problématique précise, et que c'est, entre autres, parce que l'on avait atteint les limites de ce que l'on pouvait envisager avec HTML que l'on a mis XML au point.

    Vouloir utiliser HTML dans un domaine autre que celui pour lequel il a été conçu revient, peu ou prou, à vouloir utiliser SQL Server pour... gérer les options de configuration d'une application...

    Les deux sont possibles, mais les deux sont particulièrement inadaptées à l'usage qui en est fait.

    Maintenant, si tu n'arrive pas à te remettre suffisamment en question pour analyser les choses sous cet angle, je vais te laisser faire joujou avec webkit et te demander, si possible, d'essayer de faire des remarques constructives plutôt que de nous convaincre de la suprématie de tes idées
    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. #126
    Membre expérimenté Avatar de Lavock
    Inscrit en
    octobre 2009
    Messages
    560
    Détails du profil
    Informations forums :
    Inscription : octobre 2009
    Messages : 560
    Points : 595
    Points
    595

    Par défaut

    Ok, je vois, il s'agit donc de tout séparer dans l'implémentation, pour présenter des "bêtes" widget à l'utilisateur du framework.

    Mais du coup, je vois mal en quoi, pour l'ulisateur, c'est innovant. Il s'agit toujours de penser en widget, ça, j'aime pas trop.

    Sans tomber dans le jeux vidéo et le moteur graphique, il y a peut être moyen de faire "entre les deux"... Ou comment pensée une ihm de la même façon qu'on penserez l'ui d'un jeux vidéo => c'est, à près tout, de ça que c'est inspiré Klaim.

    Après tout, il y a des exemples d'ihm pas banal dans le jeu vidéo : Expérience 112 pour ne citer que lui.

    Est-il a ce point étrange de penser qu'on peux trouver mieux que le cadre poser du widget ? Peut importe la façon dont il est amené d'ailleurs (non, je suis franchement pas fan du webkit).

    Je veux dire, tant qu'à les séparer à l'implémentation, pourquoi l'utilisateur ne pourrait pas en profiter pleinement ?
    Et quel est donc l'intérêt suprême du widget qui m'échappe à ce point ?

    Dans la bassitude de ma compréhension, j'espère que je fais au moins un peu avancer le débat >< ! Sinon, j'en suis vraiment désolé.
    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

  7. #127
    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 : 785
    Points
    785

    Par défaut

    Citation Envoyé par koala01 Voir le message
    Maintenant, si tu n'arrive pas à te remettre suffisamment en question pour analyser les choses sous cet angle, je vais te laisser faire joujou avec webkit et te demander, si possible, d'essayer de faire des remarques constructives plutôt que de nous convaincre de la suprématie de tes idées
    Et bien pour le coup, je comprends la position et les arguments de epsilon numéro 68.

    C'est un moteur de rendu après tout (je parle de webkit). En plus il embarque javascript core (toujours sympa à avoir sous le coude) et il gère html et svg. A vrai dire, webkit résout à lui seul toute la problématique sachant qu'il est open source, cross platform et son api est en c++.

    C'est tout naturellement que Qt a su tirer partie de ce toolkit.

    Tient d'ailleurs je suis en train de penser: Chrome OS n'utiliserait-il pas webkit pour son interface ?

    A propos des widgets: je vois ça comme une entité résultante d'une part de données et d'autre part de leur représentation sur un support quelconque. C'est du Model-View. Tout comme fcharton j'ai du mal à me débarrasser de la notion de widget, à commencer par le fait que l'appli toute entière peut être considérée comme un widget.

  8. #128
    Membre Expert
    Inscrit en
    juin 2006
    Messages
    1 214
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : juin 2006
    Messages : 1 214
    Points : 1 015
    Points
    1 015

    Par défaut

    Citation Envoyé par koala01 Voir le message
    entre autres, parce que l'on avait atteint les limites de ce que l'on pouvait envisager avec HTML que l'on a mis XML au point.
    rien à voir, mais absolument rien.

    par contre ils ont "essayé" de faire XHTML pour profiter des parseurs XML.
    ca a plus ou moins été un coup dans l'eau, et ils sont reparti dans HTML 5.

  9. #129
    Membre Expert
    Inscrit en
    juin 2006
    Messages
    1 214
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : juin 2006
    Messages : 1 214
    Points : 1 015
    Points
    1 015

    Par défaut

    Citation Envoyé par koala01 Voir le message
    Maintenant, si tu n'arrive pas à te remettre suffisamment en question pour analyser les choses sous cet angle, je vais te laisser faire joujou avec webkit et te demander, si possible, d'essayer de faire des remarques constructives plutôt que de nous convaincre de la suprématie de tes idées
    merci beaucoup pour ta remarque (ironie)

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

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 743
    Points : 17 226
    Points
    17 226

    Par défaut

    Citation Envoyé par metagoto Voir le message
    Et bien pour le coup, je comprends la position et les arguments de epsilon numéro 68.

    C'est un moteur de rendu après tout (je parle de webkit). En plus il embarque javascript core (toujours sympa à avoir sous le coude) et il gère html et svg. A vrai dire, webkit résout à lui seul toute la problématique sachant qu'il est open source, cross platform et son api est en c++.

    C'est tout naturellement que Qt a su tirer partie de ce toolkit.

    Tient d'ailleurs je suis en train de penser: Chrome OS n'utiliserait-il pas webkit pour son interface ?

    A propos des widgets: je vois ça comme une entité résultante d'une part de données et d'autre part de leur représentation sur un support quelconque. C'est du Model-View. Tout comme fcharton j'ai du mal à me débarrasser de la notion de widget, à commencer par le fait que l'appli toute entière peut être considérée comme un widget.
    Comme navigateur internet, ou pour créer un navigateur webkit est exactement ce qu'il faut, mais nous parlons ici de tout à fait autre chose:

    Javascript n'est... qu'un langage de script, et HTML n'est qu'un langage de mise en forme de texte.

    Dans certains cas (entre autres, lorsque tu envisages une architecture client / serveur), HTML + javascript est parfaitement adapté, et dans d'autres, ce n'est pas le cas.

    Forcer l'utilisation d'une telle architecture dans les cas où elle est inutile est purement et simplement aberrant.
    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. #131
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro yan verdavaine
    Ingénieur expert
    Inscrit en
    mars 2004
    Messages
    9 966
    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 966
    Points : 13 630
    Points
    13 630

    Par défaut

    Citation Envoyé par koala01 Voir le message
    Comme navigateur internet, ou pour créer un navigateur webkit est exactement ce qu'il faut, mais nous parlons ici de tout à fait autre chose:

    Javascript n'est... qu'un langage de script, et HTML n'est qu'un langage de mise en forme de texte.

    Dans certains cas (entre autres, lorsque tu envisages une architecture client / serveur), HTML + javascript est parfaitement adapté, et dans d'autres, ce n'est pas le cas.

    Forcer l'utilisation d'une telle architecture dans les cas où elle est inutile est purement et simplement aberrant.
    Alors pourquoi parler d'adobe asl???
    Car j'ai beau regarder depuis tous à l'heure et c'est la même philosophie.... Ou alors j'ai raté un truc...
    T'as un langage déclaratif (Html <=> adam&eve) qui définie l'ihm et du fait du binding pour que le langage déclaratif puisse appeler tes fonctions.

    Par contre je n'ai pas compris où est le renderer de l'ihm...

    Le webkit permet en plus d'y ajouter un peu de code JS pour controller le tous.

    Maintenant, si tu n'arrive pas à te remettre suffisamment en question pour analyser les choses sous cet angle, je vais te laisser faire joujou avec webkit et te demander, si possible, d'essayer de faire des remarques constructives plutôt que de nous convaincre de la suprématie de tes idées
    Dsl mais je ne comprends vraiment pas pourquoi tu lui dit cela... Tu devrais réfléchir sur son point de vue (que je partage)...

    Pour info, sur les mobiles le webkit commence à être utilisé pour l'ihm des appli en java, objectif-C,...
    Et quand tu regarde, ce n'est pas aussi abérant. Une même ihm et un code source spécifique à chaque plateforme.
    http://www.appcelerator.com/
    http://phonegap.com/

    Il en existe d'autre
    Développeur Windows 8, Windows phone 8 et Nokia Asha, inscrivez vous sur DVLUP

  12. #132
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par epsilon68 Voir le message
    afficher des tables, masque de saisie, presentation de données etc
    et bien la c'est tout a fait possible et c'est rapide.
    Je le fais deja avec Qt webkit.
    C'est possible. Mais le truc, c'est que quand le volume des données ou la complexité des traitement, le desktop et la web application ne se "scalent" pas de la même façon.

    En gros, sur une application internet, la bande passante (les volumes échangés entre le moteur et l'interface) coute cher, le calcul moteur pas. Sur une appli desktop, c'est l'inverse... (on est bien moins patient)

    Du coup, si tu a un volume raisonnable de données, mais dont le calcul est long, en web tu fais tout en une fois, en desktop, tu fais plutôt à la demande (tu calcules seulement ce que tu as besoin d'afficher, par exemple).

    Inversement, sur un très gros tableau lu directement, tu peux tout calculer d'un coup en desktop (et après tout va vite), alors qu'en web, il va falloir jouer du cache (et ca complique singulièrement l'appli)

    Dans pas mal de cas, cela va changer en profondeur l'architecture de l'appli.

    Ajoute à cela que l'attente de l'utilisateur n'est pas la même : 10 secondes d'attente dans une appli web, pas de souci, 10 secondes d'attente en desktop, ca parait nettement plus long.

    Maintenant, je suis d'accord avec tes remarques sur le moteur de rendu. Je ne suis pas certain que html soit assez puissant, mais si on disposait d'un standard permettant de modéliser toute UI, web ou desktop, ce serait effectivement incontournable... (et on écrirait un "interpréteur" pour ce langage dans le cadre du framework desktop, pas besoin de navigateur pour ca).

    [EDIT] je ne suis pas certain que les UI déclaratives répondent à cette question, ceci dit, j'ai l'impression que, comme leur nom l'indique, elles répondent davantage à la question de la définition de l'interface qu'à celle du rendu, et, à mon avis, ce sont des choses différentes[/EDIT]

    Francois

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

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 743
    Points : 17 226
    Points
    17 226

    Par défaut

    HTML: Hyper Text Marked up Language : langage balisé de liens hypertexte.

    Il s'agit d'un langage merveilleux en ce qui concerne la description de la manière dont un texte doit être affiché, mais son rôle (et ses objectifs) s'arrêtent là.

    On peut avoir des IHM déclaratives, mais il n'y a rien à faire: avec ses (environs) 120 balises très (trop ) spécialisées, HTML n'est pas suffisant pour rejoindre l'ensemble des cas que l'on risque de rencontrer dans la création d'une IHM.

    Contrairement à HTML, XML (qui est le langage utilisé par ASL) est beaucoup plus souple quand aux informations qu'il permet de représenter.

    Il ne faut donc pas baser une argumentation sur le fait que XML est fort proche (du fait des balises) de HTML pour dire que l'on peut utiliser HTML pour tout et n'importe quoi...
    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

  14. #134
    Invité
    Invité(e)

    Par défaut

    Citation Envoyé par Lavock Voir le message
    Je veux dire, tant qu'à les séparer à l'implémentation, pourquoi l'utilisateur ne pourrait pas en profiter pleinement ?
    Et quel est donc l'intérêt suprême du widget qui m'échappe à ce point ?

    Dans la bassitude de ma compréhension, j'espère que je fais au moins un peu avancer le débat >< ! Sinon, j'en suis vraiment désolé.
    Surtout pas! Depuis le début, je pousse pas mal cette discussion sur les widgets, parce je crois que c'est le coeur du débat... Si on arrive à une idée nouvelle, et qu'on s'entend dessus, on a les bases d'un projet. Si on n'y arrive pas, je ne crois pas que ce sont les questions d'implémentation, ou les listes de courses, qui nous sauveront.

    Le problème du widget, pour moi, c'est moi "à quoi ca sert" que "comment s'en passer"...

    Pour permettre à l'utilisateur de définir son IHM, et au framework de la transformer en code, il faut la définir, la modéliser, si tu veux. Et pour l'instant, dans toute cette discussion, même si on dit qu'on aimerait bien larguer les widgets, on parle toujours de boutons, de menus, de souris qui passe au dessus, de clics sur des éléments d'interface... bref, de widgets...

    C'est ce qu'on disait ce matin avec El Pedro : quelque part, on se dit que le widget est probablement réducteur, et qu'on peut faire des tas de choses dans une interface qui ne se résument pas à des boutons, et des cases à cocher... Mais voila, on en revient toujours à nos boutons, nos listes, nos menus,... nos widgets !

    Le discours de Qt, dans la video postée par yan, essaye d'étendre le débat, en parlant de "zones" sur l'interface... Mais je ne suis pas certain qu'il renouvelle le genre.

    Maintenant, il y a une chose qu'on peut modifier, c'est cette idée d'une interface formée d'un composite de widgets : une appli contient des fenetres, qui contiennent des panels, qui contiennent des boutons et d'autres panels qui contiennents des listes, avec dedans des boutons...

    Mais, une fois de plus, elle est quand même drolement pratique, cette vision arborescente de l'interface. Alors, si on la remplace, c'est par quoi?

    Francois

  15. #135
    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 : 785
    Points
    785

    Par défaut

    Citation Envoyé par koala01 Voir le message
    HTML: Hyper Text Marked up Language : langage balisé de liens hypertexte.

    Il s'agit d'un langage merveilleux en ce qui concerne la description de la manière dont un texte doit être affiché, mais son rôle (et ses objectifs) s'arrêtent là.
    A HTML il faut en fait ajouter css + javascript + DOM

    Ce "power trio" tend à s'affranchir du simple cadre des navigateurs web pour déferler sur les autres platforms/hosts. Pensons à XUL ou les trucs de Qt ou encore les trucs d'Adobe AIR/flex.
    Et ça sera pire avec HTML5 dans quelques années.

    Je ne dis pas qu'il faut adopter webkit, je pense juste que cette approche n'est pas dénué de bon sens.

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

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 743
    Points : 17 226
    Points
    17 226

    Par défaut

    Citation Envoyé par metagoto Voir le message
    A HTML il faut en fait ajouter css + javascript + DOM
    Au niveau des CSS, on ne peut déjà modifier qu'un certains nombres d'attributs clairement défini pour chacune des balises...

    Tout ce qu'elles font, c'est simplement de permettre de modifier... la manière dont le texte est mis en forme.

    d'un autre coté, les deux seules balises qui seraient, éventuellement, utilisables dans HTML (et encore), ce sont div et span, car il y a des restrictions très fortes sur l'utilisation des autres (bon, je ne parle pas de la possibilité d'imbriquer des tableau pour forcer à la mise en page, car c'est une technique réprouvée par toute la communauté du développement web )

    enfin, javascript est très bien en cela qu'il s'agit d'un langage (principalement) événementiel, mais, encore une fois, il ne peut pas fonctionner seul (il aura régulièrement besoin de renvoyer une ou l'autre requête à un serveur pour pouvoir aller plus loin)...

    Et, qu'il s'agisse de javascript ou d'ajax, on tourne toujours toujours autour d'une architecture client / serveur

    Ce "power trio" tend à s'affranchir du simple cadre des navigateurs web pour déferler sur les autres platforms/hosts.
    Mais toujours sous la forme d'une architecture client / serveur...
    Pensons à XUL ou les trucs de Qt ou encore les trucs d'Adobe AIR/flex.
    Si ce n'est que XUL et toutes les autres techno déclaratives sont beaucoup plus proches de XML que de HTML...

    Ce n'est pas parce que les balises sont représentées entre < et >, ni parce que leur fermeture est représentée par </ > qu'il faut en déduire que c'est du HTML amélioré.

    Si c'est le raisonnement que tu suis, d'accord, nous pouvons utiliser des balises indiquées entre [ et ] ou entre... ^ ^, pourquoi pas (après tout, du moment que l'on défini un caractère d'ouverture et un de fermeture...)
    Je ne dis pas qu'il faut adopter webkit, je pense juste que cette approche n'est pas dénué de bon sens.
    L'approche qui consiste à avoir un arbre composé d'une racine commune, de noeuds et de feuille et de pouvoir situer facilement la fin de chacune de ces parties est excellente...

    Mais HTML ne pourra en aucun cas suffir... et là est tout le problème
    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

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

    Informations forums :
    Inscription : octobre 2004
    Messages : 9 743
    Points : 17 226
    Points
    17 226

    Par défaut

    Citation Envoyé par fcharton Voir le message
    Surtout pas! Depuis le début, je pousse pas mal cette discussion sur les widgets, parce je crois que c'est le coeur du débat... Si on arrive à une idée nouvelle, et qu'on s'entend dessus, on a les bases d'un projet. Si on n'y arrive pas, je ne crois pas que ce sont les questions d'implémentation, ou les listes de courses, qui nous sauveront.

    Le problème du widget, pour moi, c'est moi "à quoi ca sert" que "comment s'en passer"...

    Pour permettre à l'utilisateur de définir son IHM, et au framework de la transformer en code, il faut la définir, la modéliser, si tu veux. Et pour l'instant, dans toute cette discussion, même si on dit qu'on aimerait bien larguer les widgets, on parle toujours de boutons, de menus, de souris qui passe au dessus, de clics sur des éléments d'interface... bref, de widgets...

    C'est ce qu'on disait ce matin avec El Pedro : quelque part, on se dit que le widget est probablement réducteur, et qu'on peut faire des tas de choses dans une interface qui ne se résument pas à des boutons, et des cases à cocher... Mais voila, on en revient toujours à nos boutons, nos listes, nos menus,... nos widgets !

    Le discours de Qt, dans la video postée par yan, essaye d'étendre le débat, en parlant de "zones" sur l'interface... Mais je ne suis pas certain qu'il renouvelle le genre.

    Maintenant, il y a une chose qu'on peut modifier, c'est cette idée d'une interface formée d'un composite de widgets : une appli contient des fenetres, qui contiennent des panels, qui contiennent des boutons et d'autres panels qui contiennents des listes, avec dedans des boutons...

    Mais, une fois de plus, elle est quand même drolement pratique, cette vision arborescente de l'interface. Alors, si on la remplace, c'est par quoi?
    Le fait, c'est:
    • que widget, par définition, un terme totalement abstrait, pour la simple raison qu'il représente... un type tout à fait abstrait
    • que, quoi que nous fassions, quelle que soit la manière dont on en parle de manière générale, on en reviendra toujours (parce que c'est "dans notre culture") à parler de fenêtre, de menu, de bouton, de... widget... parce que ce sont les termes dont nous avons l'habitude
    Maintenant, faut il *réellement* que toute surface que l'on peut tracer dérive systématiquement de manière publique d'une classe mère unique

    C'est, certainement, la pratique dont on a le plus l'habitude, mais je ne suis pas convaincu pour la cause que ce soit la *seule* manière de voir.

    Comment pourrait on s'en passer en travaillant sur plusieurs politiques clairement distinctes: le tracé (moteur de rendu), la "gestion du contenu" (les données que chacun est susceptible de représenter), la "connexion de signaux" et la gestion des "caractéristiques intrinsèques" (couleur, taille, ...)
    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

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

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 4 735
    Points : 7 786
    Points
    7 786

    Par défaut

    Citation Envoyé par koala01 Voir le message
    Contrairement à HTML, XML (qui est le langage utilisé par ASL) est beaucoup plus souple quand aux informations qu'il permet de représenter.
    Que nenni.
    Pas de XML dans Adobe.ASL. Mais deux langages spécialisés qui ressemblerait plus à du JSON (sans en être) qu'à du XML.

    Et +1 à la maigre sémantique derrière l'HTML. Si c'est si suffisant que cela, on ne verrai pas apparaitre des choses comme GWT/GXT.
    (Je vous invite à jouer avec Adobe.begin. Il permet de faire glisser des paires de fichiers Eve+Adam sur une appli qui les rend aussitôt. Ce qui permet de prototyper les IHMs sans rien recompiler. Cela donne une bonne idée des possibilités et des limitations de leur approche)
    Blog|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. Et de toutes façons, ma BAL sur dvpz est pleine...

  19. #139
    Membre éclairé

    Inscrit en
    juillet 2008
    Messages
    180
    Détails du profil
    Informations forums :
    Inscription : juillet 2008
    Messages : 180
    Points : 333
    Points
    333

    Par défaut

    Citation Envoyé par koala01 Voir le message
    Le fait, c'est:
    • que widget, par définition, un terme totalement abstrait, pour la simple raison qu'il représente... un type tout à fait abstrait
    • que, quoi que nous fassions, quelle que soit la manière dont on en parle de manière générale, on en reviendra toujours (parce que c'est "dans notre culture") à parler de fenêtre, de menu, de bouton, de... widget... parce que ce sont les termes dont nous avons l'habitude
    Non seulement de ce dont nous avons l'habitude, mais également ce que nous voulons montrer.
    Citation Envoyé par koala01 Voir le message
    Maintenant, faut il *réellement* que toute surface que l'on peut tracer dérive systématiquement de manière publique d'une classe mère unique
    Là on est dans le cœur du problème si j'ai bien compris. À quoi peut bien donc servir cette classe mère commune*?

    Tout d'abord à la gestion de la mémoire. En effet, quand un widget est ajouté à un widget parent (pas dans le sens héritage de classe, mais dans le sens hiérarchie de zones à l'écran*: fenêtre, groupe, bouton, texte), c'est le parent qui en devient propriétaire et qui se charge de le désallouer lorsqu'il sera lui même désaloué. Si on doit le faire à la main, ce sera peut-être plus difficile. Toutefois, si ces widgets enfants pouvaient être des membres du parent, membres directs j'entends, sans pointeur, la gestion serait faite toute seule.

    Ensuite à la gestion de la surface gérée. C'est à dire que le widget va s'occuper de dessiner à l'écran une certaine surface, habituellement rectangulaire. Son widget parent ne s'en occupe pas. Mais pour cela, un widget parent a besoin de savoir où sout placés ses enfants, et pour cela, il fait appel à des fonctions ou variables membres connues, habituellement définies dans la classe widget mère commune. Cependant, en utilisant les templates pour effectuer ce layout, il doit être possible de se passer de la mère.

    Enfin, le widget est utilisé pour tout un tas de paramètres plus ou moins communs à différents types de widgets*: la visibilité, la police utilisée, la possibilité de focus clavier,*… Qui pourraient être ajoutés à chaque widget qui en a vraiment besoin.

    Citation Envoyé par koala01 Voir le message
    C'est, certainement, la pratique dont on a le plus l'habitude, mais je ne suis pas convaincu pour la cause que ce soit la *seule* manière de voir.

    Comment pourrait on s'en passer en travaillant sur plusieurs politiques clairement distinctes: le tracé (moteur de rendu), la "gestion du contenu" (les données que chacun est susceptible de représenter), la "connexion de signaux" et la gestion des "caractéristiques intrinsèques" (couleur, taille, ...)
    Je reste assez proche de l'implémentation parce qu'au final, il faudra bien l'implémenter en C++.

    Pour finir, une petite remarque sur la distinction librairie et framework. Dans ma conception de ces deux notions, la librairie est un composant que je peux ajouter à mon programme pour l'y utiliser. Le framework, à l'opposé, c'est mon programme qui vient s'insérer à l'intèrieur. La différence, énorme, entre les deux, c'est que si je veux utiliser 2 ou 3 librairies différentes dans mon programme, c'est possible. Par contre, créer un programme qui utilise plus d'un framework, ce n'est pas possible.

    Et donc dans cet esprit, je souhaiterais qu'un tel projet reste une librairie. L'IHM n'est pas forcément l'élément qui doit apporter le framework.

  20. #140
    Expert Confirmé
    Avatar de Klaim
    Homme Profil pro Joel Lamotte
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Nom : Homme Joel Lamotte
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 334
    Points
    3 334

    Par défaut

    De même, je préférerai juste une bibliothèque, qui soit très spécialisée et du coup très efficace dans son domaine, plutot qu'un framework.

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
  •