IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Farfelue Discussion :

À propos des compétences


Sujet :

Farfelue

  1. #1
    Membre chevronné
    Avatar de Goten
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 580
    Points : 2 205
    Points
    2 205
    Par défaut À propos des compétences
    Bonjour à tous,

    Je pense qu'il serait bien de faire le point sur les domaines de compétences de chacun, et je pense avant tout à la partie rendu, utilisation des primitives des OS. Je pense que peu d'entre nous ont se genre de compétence (et de là a les avoir sur toutes les plateformes...), du coup il serait bon de savoir qui peut faire quoi. Afin pour les autres de pouvoir peut être, à défaut, ce former non?
    Car une bibliothèque d'ihm, sans rendu, c'est vite limité. :').


    Je commence : pour ma part et comme je l'ai dis à koala : c'est un domaine que je ne maitrise pas du tout, donc que ça soit unix, windows et pire mac, je ne connais pas du tout les primitives des plateformes pour "dessiner".

    Et vous?
    "Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu

  2. #2
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Je vais être honnête: jusqu'à présent, je n'ai pas croisé la moindre personne (et je me compte dans le lot) qui ait une quelconque compétence sur le sujet, que ce soit sur windows, mac ou linux

    Il faudra donc trouver des volontaires pour se former sur le sujet

    Te sens tu motivé pour te former principalement aux primitive GD/GD++

    Qui serais motivé pour se former aux primitive xorg

    Il va de soi que, idéalement, il faudrait plusieurs personnes pour chacun des OS, histoire de pouvoir se partager le travail, et d'avoir une sorte de "bouée de sauvetage" en cas de besoin

    Chers volontaires, comptez vous
    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

  3. #3
    Invité
    Invité(e)
    Par défaut
    Sur Windows, je dois pouvoir contribuer un peu. Je travaille beaucoup en IHM, essentiellement avec des frameworks tous faits (Borland), mais je sais faire quelques trucs dégoutants : sousclasser une fenêtre, gérer des messages, dessiner avec le GDI ou le GDI+. Par ailleurs, j'ai lu pas mal du code de bas niveau de la VCL de Borland (qui forme, en fait, une série de wrappers au dessus des primitives de l'OS, c'est très probablement ce qu'on sera amené à fait, d'ailleurs...) Enfin, j'ai accès, par le travail, à une personne qui connait cela plutôt bien.

    Et oui, ce genre de truc m'amuse, donc je suis volontaire...

    Francois

  4. #4
    Membre chevronné
    Avatar de Goten
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 580
    Points : 2 205
    Points
    2 205
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Te sens tu motivé pour te former principalement aux primitive GD/GD++
    Sachant que je suis à 99% du temps sur unix :'). Je préfère encore Xorg :p.
    "Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu

  5. #5
    Membre émérite
    Inscrit en
    Avril 2010
    Messages
    1 495
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 1 495
    Points : 2 274
    Points
    2 274
    Par défaut
    Bonjour à tous,

    Avant toute chose, koala01, je te félicite pour ta persévérance.

    Enfin, à titre d'information, comme je sais que vous vous êtes orientés vers GCC pour compilateur, et en ce qui concerne Windows, sachez que la Lib gdiplus n'est pas disponible nativement sous MinGW (w32api), il n'y a que gdi32. Sauf erreur de ma part, il en est de même avec MinGW64 qui utilise MinGW32 en interne.

  6. #6
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Je sens que je viens de me trouver deux responsables (rendering linux et rendering windows)

    Enfin, si vous voulez bien "vous y coller" (de toutes manières, je ne serai jamais bien loin, et je ferai également mon effort pour m'initier aux deux )

    Ce qui serait "sympa" pour que tout aille dans le même sens serait déjà de réfléchir au moyen de créer une interface commune permettant de gérer les primitives de manière similaire.

    De cette manière, nous "n'aurons qu'à" déterminer celles qui sont utilisées à coup de compilation conditionnelle
    Citation Envoyé par minnessota
    Bonjour à tous,

    Avant toute chose, koala01, je te félicite pour ta persévérance.
    Merci
    Enfin, à titre d'information, comme je sais que vous vous êtes orientés vers GCC pour compilateur, et en ce qui concerne Windows, sachez que la Lib gdiplus n'est pas disponible nativement sous MinGW (w32api), il n'y a que gdi32. Sauf erreur de ma part, il en est de même avec MinGW64 qui utilise MinGW32 en interne.
    Ca, ca peut être un problème...

    Je vais donc me renseigner rapidement auprès de l'équipe wingw-w64 pour savoir s'il est envisageable d'ajouter le support de gdiplus...

    D'expérience, ils me semblent moins "réfractaires" à ce genre d'ajout

    Par contre, nous risquons de devoir nous y coller pour ce qui est de l'implémentation

    [EDIT]Ceci dit, nous pourrions peut être nous baser sur le travail effectué par notus sur le sujet...

    Il *semblerait* que le créateur de cette bibliothèque ait mis au point un système cohérent sur le sujet (mais bon, cela nécessite vérification )
    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

  7. #7
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par minnesota Voir le message
    Enfin, à titre d'information, comme je sais que vous vous êtes orientés vers GCC pour compilateur, et en ce qui concerne Windows, sachez que la Lib gdiplus n'est pas disponible nativement sous MinGW
    Salut,

    Quel serait à ton avis le cout de son ajout? J'ai la sensation qu'il faudrait grosso modo ajouter un .h (dispo chez nos amis de microsoft, j'uitlise un header qui s'appelle gdiplus.h, qui inclut plein d'autres trucs qui s'appelle gdiplus*.h, et qui est fourni par Microsoft) qui "emballe" les primitives, et éventuellement, prévoir un système de chargement de la dll quand on bosse sous un système où elle n'est pas par défaut (Win2000).

    Je veux dire, c'est juste une dll, non? Ou y a-t-il une subtilité que je ne vois pas? (ce ne serait pas la première fois...)


    Pour ceux qui connaissent pas, les GDI c'est ce qui sert à dessiner chez Windows, le GDI+ c'est une extension qui permet toutes sortes de rendus, de transparences, de gestion de formats d'image, etc... SI on veut un look moderne, c'est un must (et ca marche sur tous les windows depuis 2000)


    Ca me fait penser à un truc (Goten, ca doit te concerner aussi). Il serait *très* utile que Farfelue inclue *tous* les header Microsoft (ou Linux) correspondant à l'API. Les graphiques, et les pas graphiques. De cette manière, toute l'API de l'OS est rendue disponible par un simple "#include osapi" ou un truc du genre. Et l'utilisateur peut appeler des trucs tordus si cela l'amuse.

    Juste pour vous donner une idée... Mon cher Borland ne gère pas, à l'origine, le GDI plus dans ses composants de base (il appelle par défaut les procédures de dessin de base, qui reposent sur le GDI). Mais comme l'interface GDIplus est exposée par le framework, c'est très facile de dériver un composant qui l'utilise pour dessiner "joliment" un composant, sans avoir à refaire toute la logique "métier" du widget (les messages, l'interaction clavier, tout le cirque)

    Pour linux, je ne sais pas dans quel mesure ces fichiers sont standardisés (c'est du noyau). Pour Windows, la difficulté viendra de l'assez grand nombre de versions de l'OS...

    Francois

  8. #8
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par fcharton Voir le message
    Salut,

    Quel serait à ton avis le cout de son ajout? J'ai la sensation qu'il faudrait grosso modo ajouter un .h (dispo chez nos amis de microsoft, j'uitlise un header qui s'appelle gdiplus.h, qui inclut plein d'autres trucs qui s'appelle gdiplus*.h, et qui est fourni par Microsoft) qui "emballe" les primitives, et éventuellement, prévoir un système de chargement de la dll quand on bosse sous un système où elle n'est pas par défaut (Win2000).

    Je veux dire, c'est juste une dll, non? Ou y a-t-il une subtilité que je ne vois pas? (ce ne serait pas la première fois...)
    Il y a, effectivement, quelques subtilités

    1- il faudra disposer de la bibliothèque d'importation de la dll (qui se nommera libgdiplus.a) Ce n'est pas très difficile à faire avec les outils ad-hoc (gendef et autre), mais ca doit être fait

    2- il faut voir la licence et le contenu des fichiers d'en-tête.

    Ce deuxième point est potentiellement plus porblématique car cela peut passer par le passage par un système de "chambre noire" et par une éventuelle adaptation des différents symboles utilisés.
    Pour ceux qui connaissent pas, les GDI c'est ce qui sert à dessiner chez Windows, le GDI+ c'est une extension qui permet toutes sortes de rendus, de transparences, de gestion de formats d'image, etc... SI on veut un look moderne, c'est un must (et ca marche sur tous les windows depuis 2000)
    C'est pour cela qu'il serait intéressant d'en profiter pour le rendu windows
    Ca me fait penser à un truc (Goten, ca doit te concerner aussi). Il serait *très* utile que Farfelue inclue *tous* les header Microsoft (ou Linux) correspondant à l'API. Les graphiques, et les pas graphiques. De cette manière, toute l'API de l'OS est rendue disponible par un simple "#include osapi" ou un truc du genre. Et l'utilisateur peut appeler des trucs tordus si cela l'amuse.
    Il *faut* effectivement arriver à donner une façade commune au système linux et windows, par contre, l'ajout dans la bibliothèque de l'ensemble des fichiers d'en-tête utilisés par les différents systèmes me semble être une mauvaise idée.

    Ne serait-ce que parce que cela impliquerait sans doute l'ajout de... tout xorg sous linux, et que, de manière générale, c'est le genre de chose qui échoit au compilateur
    Juste pour vous donner une idée... Mon cher Borland ne gère pas, à l'origine, le GDI plus dans ses composants de base (il appelle par défaut les procédures de dessin de base, qui reposent sur le GDI). Mais comme l'interface GDIplus est exposée par le framework, c'est très facile de dériver un composant qui l'utilise pour dessiner "joliment" un composant, sans avoir à refaire toute la logique "métier" du widget (les messages, l'interaction clavier, tout le cirque)
    Il faut quand même veiller à rester en accord avec la philosophie du projet, hein

    Nous n'échapperons pas à une certaine quantité d'implémentation bas niveau, mais, tant qu'à faire, autant veiller à la limiter au maximum
    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

  9. #9
    Membre chevronné
    Avatar de Goten
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 580
    Points : 2 205
    Points
    2 205
    Par défaut
    Je sens que je viens de me trouver deux responsables (rendering linux et rendering windows)

    Enfin, si vous voulez bien "vous y coller" (de toutes manières, je ne serai jamais bien loin, et je ferai également mon effort pour m'initier aux deux )
    Ne compte pas *exclusivement* là dessus en ce qui me concerne. Pour produire du code de production, je fais rarement confiance aux gens qui se forment sur l'instant... et comme ça va être mon cas, je me fait pas confiance =).
    Plus sérieusement, j'ai peur que ça soit quelque chose d'assez complexe, et un *chaperon* maitrisant bien la chose serait peut être un plus. Je vais en parler autour de moi :p.


    (par contre, quand viendra la partie metaprog, là je veux bien chaperonner xD)
    "Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu

  10. #10
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par koala01 Voir le message
    1- il faudra disposer de la bibliothèque d'importation de la dll (qui se nommera libgdiplus.a) Ce n'est pas très difficile à faire avec les outils ad-hoc (gendef et autre), mais ca doit être fait
    Effectivement, sauf à partir du principe qu'on lie dynamiquement (c'est une lib système normalement présente sur tout système windows post 2000...). Mais d'accord là dessus...

    Citation Envoyé par koala01 Voir le message
    2- il faut voir la licence et le contenu des fichiers d'en-tête.
    Ca c'est facile, c'est du microsoft de base. Tu l'as avec Windows pour faire tourner des machines windows... Je pense qu'il faudrait que farfelue fonctionne avec les fichiers Microsoft natifs, c'est cela qui va être un rien compliqué, vu que notre logique est différente des principes de programmation Windows (enfin, je pense, hein?)

    En gros, il va falloir inventer un système générique et transparent, qui permet d'appeler de l'API "à l'ancienne", sans pour autant pourrir les jolis paradigmes modernes dont farfelue se nourrira... (p... qu'est ce que je parle bien ce soir... ca doit être parce que je tape ceci au jardin, en contemplant un ciel vide d'avions...)

    Citation Envoyé par koala01 Voir le message
    Il *faut* effectivement arriver à donner une façade commune au système linux et windows, par contre, l'ajout dans la bibliothèque de l'ensemble des fichiers d'en-tête utilisés par les différents systèmes me semble être une mauvaise idée.
    Oui, maintenant, la question que je me pose est la suivante. Pour tout un tas de choses de base, on va "isoler" l'utilisateur de l'API et des trucs dégoutants qui se passent à bas niveau. Par exemple, il me parait logique que l'utilisateur n'ait pas besoin d'allouer des Device Context, ni qu'il ait besoin de gérer la palette d'un bitmap.

    Cependant, il restera toujours des choses que nous ne gérons pas. Soit parce que ces éléments, trop spécifiques Windows, n'ont pas été retenus dans notre facade, soit juste parce qu'on n'a pas voulu, pas eu le temps, etc...

    Pour ces "parties manquantes", il me semble malin de permettre à l'utilisateur de pouvoir les utiliser s'il le souhaite. Même s'il faut pour cela ouvrir dans farfelue une porte sur quelque chose d'un peu crade... La vraie force de la librairie, ce sera de le permettre sans "casser" le reste.

    Citation Envoyé par koala01 Voir le message
    Il faut quand même veiller à rester en accord avec la philosophie du projet, hein
    En fait, je crois que c'est exactement ca la philosophie du projet... Cette approche générique et non intrusive, qui fait qu'on peut ajouter des choses "différentes" (comme des appels bas niveaux), sans pour autant transformer le programme en une platée de pâtes au fromage.

    Francois

  11. #11
    Rédacteur

    Avatar de ram-0000
    Homme Profil pro
    Consultant en sécurité
    Inscrit en
    Mai 2007
    Messages
    11 517
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Consultant en sécurité
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mai 2007
    Messages : 11 517
    Points : 50 367
    Points
    50 367
    Par défaut
    Je continue l'idée lancée par Goten car je trouve aussi qu'il est important de se présenter afin au moins de connaitre les domaines de compétences des uns et des autres.

    Développeur depuis 20 ans maintenant, essentiellement en C puis en C++ (en fait, je devrais plutôt dire "C with classes").

    Une solide expérience réseau et sécurité dans les réseaux (cela ne va pas être trop utile pour ce projet mais sait t'on jamais, X11 est aussi un protocole réseau).

    Je développe essentiellement sur Windows (mais je ne rechigne pas à coder sur des *nix).

    Si il fallait se replonger dans le GDI Windows, pas de problème, je le ferai avec plaisir.

    Je peux aussi participer à la documentation du projet en français et en anglais (même si je ne m'appelle par William Shakespeare). C'est l'aspect considéré comme le plus rébarbatif mais c'est le plus utile pour la suite et je pense qu'il est important de démarrer l'aspect documentation dès le début afin de poser des bases solides.
    Raymond
    Vous souhaitez participer à la rubrique Réseaux ? Contactez-moi

    Cafuro Cafuro est un outil SNMP dont le but est d'aider les administrateurs système et réseau à configurer leurs équipements SNMP réseau.
    e-verbe Un logiciel de conjugaison des verbes de la langue française.

    Ma page personnelle sur DVP
    .

  12. #12
    Membre émérite
    Inscrit en
    Avril 2010
    Messages
    1 495
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 1 495
    Points : 2 274
    Points
    2 274
    Par défaut
    Ce lien devrait peut-être vous aider:
    http://lists.zerezo.com/mingw-users/msg00862.html
    Enfin, pour une interface au look de Windows ce n’est pas indispensable.

    Sinon, il y a directx qui supplante pas mal gdi.

  13. #13
    Expert éminent
    Avatar de Melem
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2006
    Messages
    3 656
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Électronique et micro-électronique

    Informations forums :
    Inscription : Janvier 2006
    Messages : 3 656
    Points : 8 389
    Points
    8 389
    Par défaut
    Je développe en C90 et en C++03. Je commence petit à petit à utiliser du C++11 (j'aime particulièrement les lambda expressions), bien que je n'ai jamais touché à boost (à part quelques lectures pour la culture). Pour ce qui est de la ma plateforme de prédilection, c'est Windows (mais connaissances raisonnables en programmation linux). Je serai donc avec l'équipe qui sera chargée de l'implémentation pour Windows.

    Pour Windows justement, je propose d'utiliser GDI plutôt que GDI+ parce que c'est galère d'utiliser GDI+ avec un autre compilateur que Visual, et c'est encore plus galère (même avec Visual) si on veut aussi cibler les plateformes mobiles. De plus, je vois GDI+ plus comme une API développée pour servir de base à certaines APIs .NET que le véritable successeur de GDI. Windows XP existe depuis bientôt 10 ans et les développeurs d'applications natives Windows préfèrent toujours utiliser GDI et depuis Windows 7, Direct2D aussi, plutôt que GDI+.

  14. #14
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Melem Voir le message
    De plus, je vois GDI+ plus comme une API développée pour servir de base à certaines APIs .NET que le véritable successeur de GDI. Windows XP existe depuis bientôt 10 ans et les développeurs d'applications natives Windows préfèrent toujours utiliser GDI et depuis Windows 7, Direct2D aussi, plutôt que GDI+.
    On doit pas connaître les même, alors... depuis quelques années (on va dire depuis la sortie de Vista et d'Office 2007, et la généralisation du look qui va avec), j'ai l'impression que de plus en plus de developpeurs windows se sont mis à GDI+.

    Mais c'est vrai que ca a mis du temps à venir, comme pas mal de choses chez Microsoft, en fait...

    C'est un peu technique, nettement plus compliqué que GDI (qui en gros ne fait que des traits, des rectangles, des ellipses, et des fontes de base), mais ca fournit quand même pas mal de fonctionnalités utiles (l'antialiasing des fontes, les gradients, les couleurs à 4 composantes par défaut, les formats "non standard", comme le PNG...).

    On peut bien sur partir de GDI, ne serait ce que pour la compatibilité, mais je pense qu'il faudrait au moins essayer GDI+ (au passage, c'est juste une dll, au pire des cas, tu l'appelles avec un GetProcAdress, et en avant...)

    Sur DirectX/Direct2D, mon impression est que c'est moins adapté que GDI/GDI+ aux fonctions usuelles de l'IHM (en gros, dessiner des rectangles, éventuellement avec des coins ronds, les remplir, et écrire du texte), et que c'est un rien plus lourd (en charge pour la machine, je veux dire).

    Si on allait par là, il faudrait probablement se poser la question d'OpenGL, qui a l'avantage d'être multiplateforme. Ce qui m'ennuie avec OpenGL, c'est le "poids" de la surcouche.

    Francois
    Dernière modification par Invité ; 19/04/2010 à 10h15.

  15. #15
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par fcharton Voir le message
    Effectivement, sauf à partir du principe qu'on lie dynamiquement (c'est une lib système normalement présente sur tout système windows post 2000...). Mais d'accord là dessus...
    Ce qu'il y a, c'est qu'il faut, au moment de l'édition des liens, que ld (car c'est lui qui s'en occupera) sache que "telle fonction" est fournie par gdiplus.dll.

    Autrement, il te sortira un erreur "undefined reference to (function) ".
    Ca c'est facile, c'est du microsoft de base. Tu l'as avec Windows pour faire tourner des machines windows... Je pense qu'il faudrait que farfelue fonctionne avec les fichiers Microsoft natifs, c'est cela qui va être un rien compliqué, vu que notre logique est différente des principes de programmation Windows (enfin, je pense, hein?)
    Je parlais de la licence des fichiers d'en-tête...

    On ne peut pas "simplement" se contenter de les copier du dossier include de VS ou de Borland dans le dossier include de Gcc.

    Il y a plusieurs raisons à cela:

    Ils sont fournis sous la licence attachée au compilateur.

    Tu peux donc créer une application (commerciale ou non) qui utilise les fichier d'en-tête, mais tu risque de ne peux pas pouvoir donner les fichiers d'en-tête à tout le monde et n'importe qui.

    Par contre, tu peux écrire toute une documentation sur ces fichiers d'en-tête, et je peux, sur base de la lecture de celle-ci, créer un fichier d'en-tête adapté à mon compilateur, pour autant que je n'aie jamais regardé le fichier d'en-tête d'origine

    Ensuite, il y a fatalement une série de symboles préprocesseur dans ces fichiers d'en-tête qui sont dépendants du compilateur lui-même.

    Il faut donc veiller à "adapter" le fichier d'en-tête de manière à ce qu'il utilise les symboles équivalents du compilateur avec lequel on souhaite travailler et qui sont différents du compilateur "dont sont tirés" les fichiers d'en-tête.

    En gros, il va falloir inventer un système générique et transparent, qui permet d'appeler de l'API "à l'ancienne", sans pour autant pourrir les jolis paradigmes modernes dont farfelue se nourrira... (p... qu'est ce que je parle bien ce soir... ca doit être parce que je tape ceci au jardin, en contemplant un ciel vide d'avions...)
    exactement
    Oui, maintenant, la question que je me pose est la suivante. Pour tout un tas de choses de base, on va "isoler" l'utilisateur de l'API et des trucs dégoutants qui se passent à bas niveau. Par exemple, il me parait logique que l'utilisateur n'ait pas besoin d'allouer des Device Context, ni qu'il ait besoin de gérer la palette d'un bitmap.
    C'est bien l'idée, en effet

    Cependant, il restera toujours des choses que nous ne gérons pas. Soit parce que ces éléments, trop spécifiques Windows, n'ont pas été retenus dans notre facade, soit juste parce qu'on n'a pas voulu, pas eu le temps, etc...
    C'est effectivement le risque... à nous de faire en sorte que cette partie manquante soit, a terme, aussi limitée que possible
    Pour ces "parties manquantes", il me semble malin de permettre à l'utilisateur de pouvoir les utiliser s'il le souhaite. Même s'il faut pour cela ouvrir dans farfelue une porte sur quelque chose d'un peu crade... La vraie force de la librairie, ce sera de le permettre sans "casser" le reste.
    Effectivement, mais, encore une fois, l'idéal sera réellement de faire en sorte que l'utilisateur de Farfelue n'aie "même pas besoin ni envie" d'aller "repêcher" une fonction non exposée par la facade

    Citation Envoyé par goten
    Ne compte pas *exclusivement* là dessus en ce qui me concerne. Pour produire du code de production, je fais rarement confiance aux gens qui se forment sur l'instant... et comme ça va être mon cas, je me fait pas confiance =).
    C'est une approche des plus sensées...

    Le problème, c'est que, si on décide "d'attendre d'avoir trouvé" un type qui maitrise le sujet pour s'y mettre, autant se serrer la main, reconnaitre notre erreur et faire fermer l'hébergement, car les chances d'en trouver un rapidement sont pour le moins limitées.

    Si c'est pour ne réellement commencer le dev que dans six mois ou un an, quand ont aura trouvé "la perle" qui sera suffisamment à l'aise en GDI+ ou en xorg, le projet sera "mort né"

    Autrement dit, ton approche est très saine, mais "faute de grives on mange des merles" et, en attendant de trouver les perles qui nous font défaut, il faudra bien que nous fassions "contre mauvaise fortune bon coeur"
    Plus sérieusement, j'ai peur que ça soit quelque chose d'assez complexe, et un *chaperon* maitrisant bien la chose serait peut être un plus.
    Effectivement...

    Mais encore une fois, il ne faut pas que cette recherche du "chaperon idéal" ne nous empêche d'avancer malgré tout et bloque le projet.

    Autrement, nous n'avancerons pas, et, comme il n'y a encore rien de fait, le projet sera mort né
    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. #16
    Membre émérite
    Inscrit en
    Avril 2010
    Messages
    1 495
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 1 495
    Points : 2 274
    Points
    2 274
    Par défaut
    Salut à tous,

    Citation Envoyé par koala01 Voir le message
    Le problème, c'est que, si on décide "d'attendre d'avoir trouvé" un type qui maitrise le sujet pour s'y mettre, autant se serrer la main, reconnaitre notre erreur et faire fermer l'hébergement, car les chances d'en trouver un rapidement sont pour le moins limitées.

    Si c'est pour ne réellement commencer le dev que dans six mois ou un an, quand ont aura trouvé "la perle" qui sera suffisamment à l'aise en GDI+ ou en xorg, le projet sera "mort né"

    Autrement dit, ton approche est très saine, mais "faute de grives on mange des merles" et, en attendant de trouver les perles qui nous font défaut, il faudra bien que nous fassions "contre mauvaise fortune bon coeur"
    Effectivement...

    Mais encore une fois, il ne faut pas que cette recherche du "chaperon idéal" ne nous empêche d'avancer malgré tout et bloque le projet.

    Autrement, nous n'avancerons pas, et, comme il n'y a encore rien de fait, le projet sera mort né

    Peut-être devriez-vous songer à unir vos efforts autour d'une librairie spécialisée et multiplateforme ?
    Je pense notamment à Anti-Grain Geometry (AGG) qui me semble être le candidat idéal pour votre moteur de rendu. Elle jouit d'une très bonne réputation et elle est par exemple utilisée, je crois, dans wxWidgets.

    Jeter un coup d'œil sur le site ainsi que sur ses quelques exemples. Il y a matière à réflexion. Sans cela, la partie Unix du projet risque de souffrir pas mal, et ce serait fort dommageable.

  17. #17
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par minnesota Voir le message
    Salut à tous,




    Peut-être devriez-vous songer à unir vos efforts autour d'une librairie spécialisée et multiplateforme ?
    Je pense notamment à Anti-Grain Geometry (AGG) qui me semble être le candidat idéal pour votre moteur de rendu. Elle jouit d'une très bonne réputation et elle est par exemple utilisée, je crois, dans wxWidgets.

    Jeter un coup d'œil sur le site ainsi que sur ses quelques exemples. Il y a matière à réflexion. Sans cela, la partie Unix du projet risque de souffrir pas mal, et ce serait fort dommageable.
    Il faut quand même se rappeler que la politique de base de Farfelue est:

    1. De limiter au maximum les dépendances envers les bibliothèques tierces (la seule dépendance, en dehors des primitives OS et de la STL admise pour le noyau étant boost)
    2. De ne pas "simplement" apporter une surcouche à une bibliothèque existante
    Je ne dis pas qu'il faut renoncer à s'inspirer de antigrain (tout comme il y a de nombreuses autres bibliothèques dont il est possible de s'inspirer), mais il y a de la marge par rapport au fait de placer une dépendance forte vis à vis de cette bibliothèque (ou de toute autre bibliothèque du style)
    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. #18
    Membre émérite
    Inscrit en
    Avril 2010
    Messages
    1 495
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 1 495
    Points : 2 274
    Points
    2 274
    Par défaut
    Citation Envoyé par koala01 Voir le message
    s'inspirer de antigrain
    L'utiliser c'est une chose, s'en inspirer, ça risque d'être difficile, elle est bougrement complexe.


    Citation Envoyé par koala01 Voir le message
    la politique de base de Farfelue
    Je suis au courant. N'aie pas d'inquiétude. Je pensais juste que Anti-Grain pouvait faire exceptions.

  19. #19
    Invité
    Invité(e)
    Par défaut
    Ce qui m'inquiète le plus, avec des solutions de type "moteur de rendu", c'est le poids (en charge CPU et mémoire) de tels systèmes.

    On voudrait de rester "près" de l'OS, ou plus précisément, de n'avoir qu'une couche d'abstraction entre les primitives OS et les fonctions de base de Farfelue, pour garantir une faible empreinte (mémoire et CPU) de farfelue. Ce qui permet que ces ressources (toujours limitées) servent ailleurs (dans le code métier, par exemple...)

    Maintenant, rien n'empêcherait de "porter" AntiGrain comme un moteur de rendu supplémentaire. Plus cela va, plus je me dis que nous allons devoir offrir un "langage graphique", extensible, qui fera le lien entre Farfelue et les lib de dessin externes. A la base ce langage devrait être très simple, et pouvoir s'exprimer en terme de primitives de base (GDI disons...), mais il devra pouvoir s'étendre pour accomoder des implémentations plus riches (comme les moteurs de rendu évolués).

    Intuitivement, je me dis que tout ceci ressemble terriblement à des Policies... et que donc, on est probablement dans la bonne voie.

    Francois

  20. #20
    Membre chevronné
    Avatar de Goten
    Profil pro
    Inscrit en
    Juillet 2008
    Messages
    1 580
    Détails du profil
    Informations personnelles :
    Âge : 33
    Localisation : France

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 580
    Points : 2 205
    Points
    2 205
    Par défaut
    Ben l'idée de base derrière la portabilité à mon avis, c'est de viré le prépocesseur pour le remplacé par des classes de traits. (enfin du prépocesseur y'en aura à l'appel).
    Je veux dire, imaginons qu'on est une classe rendu, qui s'occupe de délégué les appels aux différentes primitives des différents OS.
    il "suffit" que cette classe soit composé de méthode statique pour avoir un appel portable sans trop de contrainte :

    render<osTraits>::drawLine(//...);

    Derrière ça consisterait en spécialisation plutôt qu'en macro. Et ça permettrait de venir greffer d'autres moteur de rendu plus aisément.
    "Hardcoded types are to generic code what magic constants are to regular code." --A. Alexandrescu

Discussions similaires

  1. Aide a propos des TMenuEdit
    Par scooper dans le forum C++Builder
    Réponses: 9
    Dernier message: 27/05/2004, 16h39
  2. Une question à propos des thread
    Par tscoops dans le forum C++Builder
    Réponses: 4
    Dernier message: 07/11/2003, 15h03
  3. A propos des 'File management Functions' de Windows
    Par znaidi dans le forum Windows
    Réponses: 3
    Dernier message: 01/04/2003, 17h01
  4. A propos des modèles d'objet (avec sources)
    Par DevX dans le forum C++Builder
    Réponses: 14
    Dernier message: 01/12/2002, 13h22

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo