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
De toute façon, Qt ne répond pas au critères que j'ai donné.
Peut-être que je ferais un front-end en Qt et un autre en GTK, histoire que tous les utilisateurs de Linux soient contents. Le plus gros de la GUI sera géré par la lib que je dois choisir ici.
? pourtant tes critère sont bien ceux là non??Envoyé par three minute hero
Enfin, tu fait comme tu veut
Qt fait du vectoriel ? J'ai cru comprendre que non…
Et puis j'aimerais bien jouir d'une accélération graphique.
De toute façon, comme je le disais, je souhaite offrir (si la charge de travail n'est pas trop importante) une GUI native pour un maximum d'utilisateurs. Dans un premier temps ça sera donc du wxWidgets, et peut-être du Qt pour ne pas mourir idiot et pour faire plaisir aux utilisateurs de KDE. Et pourquoi pas carrément du GTK, du MFC et du <insérer ici le nom de la lib graphique native de Mac>… mais pour ça on verra plus tard !
Je suis très tenté par Cairo, apparemment. Mais l'idée que ce soit du C (wrappé) ne m'enchante guère. Ça me rappelle Gtk(mm)… j'aime bien Gnome, mais c'est tout de même pas ce qu'il y a de plus réactif.
Mouerf… j'ferais mieux de me lancer au lieu de tergiverser ! Et rien n'interdit de changer d'avis dans le futur.
juste pour faire mon chieur, Qt le fait.
Mais bon aprés c'est la licence qui peut etre chiant.
Je ne connait pas trop wxWidget. Parait que c'est pas mal
(J'insiste : la SFML, c'est du hors sujet ici alors ?)
Qt utilise OGL en back-end (aussi DirectX en beta).
Qt est de loin le meilleur choix. Tu loupes franchement quelque chose.
Le point le plus important en ce moment je trouve, c'est leur extension Javascript pour scripter une appli. On a donc une partie tres performante en C++ et une partie tres souple tres dynamique en Javascript.
et bof pour la licence....
Sinon y as gtkmm. Qui semble plus C++ que Qt.
Mais bon, gtk c'est pas facile pour developper sous windows (plein de chose as installer)
moi j'adore qu'un produit comme Qt puisse etre accessible.
et franchement € 2630 pour faire un produit commercial dessus, c'est franchement pas cher, sans compter le lot d'innovations qu'ils apportent de version en version...
et les arguments du genre "c'est pas du vrai C++" ne sont vraiment pas recevables.
C'est du vrai C++ avec quelques precautions pour rester compatible avec tous les compilos. Ils ont fait un framework pour etre productif, pas pour etre fier d'utiliser les dernieres techniques a la mode qui marche sur la version beta du compilo.
Dire que GTK ont refait du "C++" avec du C ... vraiment quelle perte d'energie, recreer tous les mecanismes du C++ a la main, mais vraiment quelle perte de temps, et surtout de manque de facilité dans son evolution ...
Ce n'est pas compilable par un compilateur C++.et les arguments du genre "c'est pas du vrai C++" ne sont vraiment pas recevables.
Il y a une première passe qui analyse le code, reconnait leur langage (C++/MOC), et génère du C++.
Il est parfaitement possible par exemple d'implémenter C++, Java, ou n'importe quel autre langage en fait, avec un préprocesseur qui génère du C.
Le langage dans lequel on programme au final est-il du C pour autant ?
Pour une entreprise oui. mais pour un particulier...
Tu n'est pas obligé d'utiliser leur preprocesseur. Mais tu va galéré. Franchement ce n'est pas pire que les template, en ce sens ou il faut un préprocesseur pour générer du code qui sera compilé.
Puis on va pas leur en vouloir d'avoir grandement simplifier l'écriture des communications entre widget. Regarde les signal/slot de Boost, c'est le même concepte, sauf qu'il faut plus de code.
et franchement qu'est ce que ca change d'utiliser moc ?
c'est meme transparent avec qmake et perso je ne m'en preoccupe pas.
Aussi grace a moc, ils ont pu implement leur moteur Javascript hyper genialement.
C'est finalement juste un "probleme" ideologique pour vous....
se restreindre avec un toolkit inferieur ? "juste" a cause de moc... faut quand meme faire gaffe de pas passer a coté de quelque chose de genial au prix du sacro saint C++ sans moc...
Je suis d'accord avec tout ça, QT est vraiment bien adapté pour ces besoins, surtout si une interface graphique doit être réalisée, autant tout faire en QT. Cependant QT n'est pas spécialisé dans le dessin vectoriel, je suppose donc que si mozilla a choisi Cairo et non QT c'est qu'il y a des raisons, sans doute a cause des performances. En terme de fonctionnalités, pour ce qui est du dessin vectoriel je pense que c'est kif kif entre Cairo et QT. Par contre, si l'on souhaite disposer de très bonnes performances et de plus de fonctionnalités je pense qu'il n'y a pas mieux que AGG !
Si tu utilises QT je te conseil fortement de ne pas utiliser OpenGL ou DirectX avec, pas du tout adapté pour des dessins 2D qui demandent de la finesse !
Pfiou, j'aurais pas pensé lancer un tel troll.
Je n'en sais rien, j'ai pas cru voir que ça faisait du vectoriel. Et à vue de pif ça m'a pas l'air très éprouvé.
Voir le reste de mon message…
Je développe sous Linux !
Et en effet, c'est nettement plus standard.
Je n'exclue pas le développement d'un module propriétaire. 2630€ sont autant d'euros que je me ferais un plaisir d'économiser !
J'utilise un outil très pratique de génération de code à partir de diagrammes de classe UML. Si le développeur de cet outil (libre et gratuit) a le manque d'envie légitime de supporter les écarts anti-standards de toutes les lib qui existent, l'argument est foutrement recevable.et les arguments du genre "c'est pas du vrai C++" ne sont vraiment pas recevables.
Là, par contre, je plussoie. Mais tant que ça n'a pas de répercutions sur l'utilisateur (de la lib, et final), ils font ce qui leur chante…Dire que GTK ont refait du "C++" avec du C ... vraiment quelle perte d'energie, recreer tous les mecanismes du C++ a la main, mais vraiment quelle perte de temps, et surtout de manque de facilité dans son evolution ...
C'est vrai que Qt est intéressant dans le fait que ce soit une solution tout-en-un. Mais je n'aime pas trop l'idée de rendre mon code globalement dépendant d'une lib, j'aime pouvoir me dire que je pourrais changer du jour au lendemain sans devoir réécrire plus que ce qui encapsule la lib.
Les performances ne peuvent être meilleures qu'un Cairo qui passe par le hard, non ?
Les fonctionnalités… AGG facilite-t-il l'export PS/PDF et l'impression ?
En fait, qu'est ce qu'AGG a de plus que Cairo point de vue fonctionnalités ?
Ce ne sont pas des questions rhétoriques ! C'est pas évident de trouver de la doc sur AGG.
Quelqu'un connait OpenVG ?
Ça a l'air très sympa, ça aussi…
Question subsidiaire :
C'est pas bien clair dans mon esprit. Quand on parle d'API, ça veut dire que c'est juste une interface non-implémentée ?
Si le hard est utilisable évidemment Cairo sera plus rapide. Ca fait maintenant plus d'un an que je n'ai pas bossé là dessus, au moment ou je m'y suis intéressé il me semble que l'accélération n'était disponible qu'avec Linux. Il faudrait donc chercher un peu plus d'informations à ce sujet. Cependant, pour le moment le dessin vectoriel est presque toujours logiciel et non matériel car d'une carte graphique à l'autre des différences apparaissent (facteurs d'anti-aliasing différents par exemple). A mon avis il va faloir encore un bon moment avant que l'utilisation du matériel soit bonnne avec Cairo !Les performances ne peuvent être meilleures qu'un Cairo qui passe par le hard, non ?
Non, mais le principe d'AGG est de construire ton propre moteur de rendu vectoriel, l'avantage est que tu y insère uniquement les briques qui te sont utiles. Par exemple le moteur de rendu de Cairo n'est pas modifiable, pour réaliser un dessin particulier il est possible qu'une brique du moteur soit utilisée sans que çe soit utile. C'est aussi parce que AGG fonctionne sur ce principe que je dirais qu'il peut être plus rapide.Les fonctionnalités… AGG facilite-t-il l'export PS/PDF et l'impression ? En fait, qu'est ce qu'AGG a de plus que Cairo point de vue fonctionnalités ?
Pour l'export vers PS/PDF rien n'est prévu dans AGG malheuresement.
Bon, compte tenu du fait que Cairo est plus facile à utiliser, je ferais mieux de commencer à l'utiliser. Si je finis par le trouver trop juste point de vue performances, je passerai à AGG.
En plus je suis sous Linux, et Windows et Mac jouissent déjà de Guitar Pro. Ça ne me dérange donc pas de privilégier Linux dans un premier temps !
Merci à tous de m'avoir aidé à diriger mon choix !
Après m'être posé le même genre de questions pour un rendu graphique d'une appli scientifique, je me suis résolu à utiliser le nouveau wxGraphicsContext et fonctions associées de wxWidgets (puisque tu sembles venir de là). Ca marche pas mal, en fait, parce que ça utilise Cairo sous gtk, gdiplus sous windows, etc. Donc on a accès à tout ce qui manquait dans wxWidgets avant: antialiasing, alphalending, transformations...
Et sinon je confirme que Qt a un excellent rendu vectoriel.
Géniaaaal BiozicElle est nouvelle cette classe, non ? C'est la première fois que je la vois…
*vérifie*
Ben non, c'est juste qu'elle est pas répertoriée sur cette page : http://www.wxwidgets.org/manuals/sta...l#classesbycat
Par contre elle l'est ici : http://www.wxwidgets.org/manuals/sta....html#classref
et je me demande bien pourquoi…
Belle trouvaille, quoi qu'il en soit ! J'ai bien fait de glaner dans mes vieux topic
Merci !
C'est vrai que cette partie de wxWidgets n'est pas hyper-documentée... Pourtant, quand on y ajoute wxGCDC (une interface wxDC quasiment complètement implémentée mais encore moins documentée), on se retrouve à être capable de transformer une appli wxWidgets un peu old-fashioned en appli au rendu moderne même sous Windows
Par contre, côté performances, on descend de quelques étages, mais tout a un prix.
Répondre avec citation
Partager