Ouai mais ca on sait bien que dans la vraie vie ca arrive malheureusement rarement. Et entre eduquer les gens ou trouver un solution technique, je crois que la solution technique a plus d'avenir :)
Question conne
Serait-il possible de transferer un journal pour le mettre en 1er page ?
Actuellement on se retrouve toujours avec:
- 1 journal contenant plein de commentaires
- 1 depeche sur le meme sujet beaucoup plus "pauvre" (et paradoxalement en page d'accueil alors que le journal "riche" en commentaires est "perdu" dans le site web)
Solution:
- modifier le journal en rajoutant des infos si besoin (les fameuses notes du moderateur + correction des fautes)
- transferer le journal en 1er page
Ainsi aucune information n'est dupliquee ni omise :)
Vous avez déjà entendu parler d'Emacs, de KDevelop… ?
"Visual Studio permet d'être bien plus productif que tout ce que j'ai pu tester sous Linux en 10 ans" (KDevelop et les autres inclus)
C'est mieux dit comme ca ?
Faut arrêter d'être sectaire, ça arrive à Microsoft et à pas mal d'autres boites de pondre des logiciels bien plus performants que leurs équivalents libres hein.
trouvez moi un OS+un IDE qui me fasse développer aussi vite en .Net que windows + visual studio
+10000
Je développe toujours sous Windows (Qt/C++) car Visual Studio permet d'être bien plus productif que gdb + vim
J'utilise des machines virtuelles qui me permettent de tester mon code sous Linux.
le temps de compilation entre gcc3 et gcc4 a pu doubler
Et c'est super pénible, surtout en C++
Ca ralentit énormément la productivité (processus modification code - compilation - test) et ca donne envie d'utiliser des langages interprétés.
Un compilo C/C++ qui se focaliserait sur la rapidité de compilation ça serait génial. Rien n'empêche après de fournir un binaire à l'utilisateur compilé avec GCC et toutes les optimisations qui vont avec.
Mouais ba je pense qu'il faut séparer 2 choses : l'adoption des balises audio/vidéo et l'adoption du codec theora. Les 2 sont dissociés car HTML5 n'impose pas un codec en particulier.
** coté serveurs
En gros si YouTube adopte la balise video c'est bueno.
YouTube c'est Google, Google c'est Chrome (et aussi Firefox), Chrome utilise WebKit qui supportera la balise video.
Il ne serait pas impossible que dans le futur YouTube et les autres proposent dans leur code if Flash version OK then Flash else HTML5
A mon avis, plus que Microsoft et IE, c'est YouTube et les autres qui vont être déterminant dans l'adoption de la balise vidéo.
Qt slot/signal a une syntaxe simple c'est vrai mais boost::signal (meme genre que les slots/signaux de gtkmm) a aussi des avantages, je l'ai trouvé plus puissant et moins contraignant. Par exemple Qt slot/signal ne permet pas de mettre des parametres par defaut dans les signaux, pas de verification a la compilation mais seulement au runtime ect... alors que boost n'a pas ses limitations.
Et puis moc pete regulierement les couilles a la compilation, les mots cles de Qt ne sont pas souvent reconnus par les IDE ect...
Si moc pouvait disparaitre ca serait pas un mal, quitte a rajouter quelques macros pour garder la même simplicité d'écriture. Il va surement y avoir des changements quand C++0x sera supporté.
Tout fourrer dans une seule librairie ce n'est pas ce que j'appelle de la programmation modulaire
Ce n'est pas parceque Qt propose un ensemble de librairies cohérentes, bien foutues et bien documentées que ce n'est pas de la programmation modulaire, au contraire. http://doc.trolltech.com/main-snapshot/modules.html
Si tu ne fais pas de SQL, tu ne depends pas de QtSQL, pareil pour QtWebKit, QtGui, Phonon, QtXML, QtNetwork ect...
tu n'as pas gouté à la joie du C++ et des compilo multiples
Il me semblait que sous Windows il y avait beaucoup moins de problème car les compilos les plus courants "comprennent" le format généré par Visual C++. En même temps j'ai jamais essayé, donc si tu dis que ça marche pas, je te crois :p
En revanche il est peut etre possible que Qt compilé avec MSVC fonctionne sous C++ Builder. En effet après il reste juste les .h et .dll/.lib à faire fonctionner.
Au contraire c'est vraiment pas du de choisir !
J'ai souvent lu que WxWidgets c'était pas vraiment pas le top (API façon MFC vieillotte, difficulté à obtenir une GUI propre sur chaque OS...). Par exemple VLC est passé de WxWidgets à Qt sans aucun regret du coté des devs (cf mailing-list).
Pour ce qui est du support des compilos, Qt supporte tous les compilos récents : GCC, MinGW, Visual C++ (MSVC > 7.1), Intel CC... http://trolltech.com/developer/supported-platforms
(GLib/GTK+ par comparaison ne compile pas avec Visual C++)
Perso j'utilise QTextBrowser de Qt-4.4, mais pour afficher une page Wikipedia c'est pas franchement le top : trop limité. GtkHTML n'est il pas aussi trop limité ?
Dans mon cas un composant plus performant comme Dillo aurait ete utile, j'ai pas trop envie de me trainer QtWebKit qui pompe bien 10Mo en plus :/
Sous Windows il est assez facile d'embarquer Internet Explorer via ActiveX et ca prend pas beaucoup de ram (puisque deja en memoire au final) mais c'est quand meme moyen comme solution pour un libriste (!)
Je super étonné qu'ils changent pour FLTK
J'aurais plutot vu Dillo comme un composant/widget pour Qt ou GTK facilement integrable dans d'autres programmes (comme Scintilla http://fr.wikipedia.org/wiki/Scintilla ).
Il y a beaucoup d'applications qui ont besoin d'un moteur HTML léger pour afficher l'aide, ou par exemple les lecteurs audio pour afficher la page Wikipedia d'un artiste. Pour ce type de fonctionnalités, sortir les bulldozeurs Webkit/Mozilla est inadapté.
Ou encore l'emplacement du "panneau de config" qui est dans le menu "tools" ou "edit"
D'ailleurs Qt gère en partie certaines de ces problématiques
cf http://doc.trolltech.com/4.4/qmenubar.html#details
je connais aucun toolkit capable de modifier les label écrits par les développeurs pour refleter le style verbal recommandé
Ouai enfin la c'est quand meme du chipo ou alors on parle pas du meme truc. Moi je pensais a ca par exemple : titre de la fenetre = "Nom de l'appli - nom du fichier ouvert" qui est peut etre different suivant les guidelines des OS. Ou encore l'emplacement du "panneau de config" qui est dans le menu "tools" ou "edit".
Si tu pinailles la dessus et 3 pauv #ifdef dans ton code pour arranger ca, alors je comprends pas pourquoi selon ton point de vue, les WinForms sous Linux/MacOS ne meriteraient pas le terme "experimental" :)
> Faire un theme natif, c'est pas du coloriage
Sans dec. J'ai déjà dis le contraire ?
C'etait en reponse a ton lien http://www.gnome-look.org/content/show.php/show.php?content=(...)
Si tu regardes le contenu, c'est justement du "coloriage", autrement j'aurais pas evoque ce sujet.
t'as jamais eu l'idée qu'on pouvait utiliser les widgets natifs dans un thème ?
Je crois qu'on tourne en rond "Faire un theme natif, c'est pas du coloriage mais utiliser l'API de la plateforme"
Qt ne résoud pas ce problème (ou très peu)
Rectificatif : Qt resoud bien mieux ce genre de problemes que n'importe qu'elle autre toolkit, et de tres tres tres loin.
C'est meme le fond de commerce de Trolltech. Ca fait plus de 10 ans que Qt fonctionne sur Win/Linux/Mac. Ca tourne meme sur WinCE en natif depuis peu (!)
style de nommage
En partie, ca depend ce que t'appelle style de nommage
Par exemple voici un wizard Qt sous differents OS : http://doc.trolltech.com/4.4/qwizard.html#wizard-look-and-fe(...)
Apres c'est sur que le titre d'une fenetre faudra peut etre faire des #ifdef mais c'est tout a fait normal.
C'est un thème comme un autre
Non justement ! le style MacOSX c'est pas juste une scrollbar bleue. Typiquement sous Windows il est impossible de faire la difference entre une appli Qt et une appli MFC/WTL. pareil sous MacOSX, Qt utilise Carbon et bientot Cocoa (ce qui va resoudre les derniers problemes connus).
Faire un theme natif, c'est pas du coloriage mais utiliser l'API de la plateforme et c'est pas franchement evident a faire. Avant que WinForms/GTK+ arrivent a un niveau equivalent du Qt de 2008 il va falloir attendre encore quelques longues annees.
Quand on lit la doc de Qt, il y a plein d'endroits ou il a des trucs specifiques a une plateforme ou une autre, des methodes qui ne font rien sur certaines plateformes ect... et c'est hyper bien foutu et pour aller plus loin il y a aussi des vrais exemples http://doc.trolltech.com/qq/qq23-layouts.htmlhttp://doc.trolltech.com/qq/qq19-buttons.html
WinForms ne pourra jamais faire ca car l'API est controlee par Microsoft et a ete concu seulement pour fonctionner sous Windows contairement a Qt qui est fait pour des le depart.
Au final je te rappelle quand même que ta remarque initiale portait sur le côté "expérimental"
Oui c'est vrai, c'est pourquoi j'ai indique que "je me suis un peu trop lache dans mon post" car la derniere fois que j'ai utilise C#, WinForms utilisait Wine et GTK+ sous Mac utilisait X11 (!)
pour quasiment tous les toolkits graphiques
AWT, WxWidgets, SWT et probablement un paquet d'autres... meme les WinForms/Mono puisqu'ils avaient commences par faire un backend GTK+
Il est probable que la majorite des toolkits graphiques utilisent cette methode. Par exemple les MFC et autres WFC sont des bindings par dessus les widgets win32.
Et perso j'etais resté sur l'idee que les WinForms/Mono etaient implementees en utilisant Wine d'ou mon post juste au dessus.
Qt c'est gentil [...] mais y'a encore du boulot à faire côté ergonomie et accessibilité.
Je suis tres curieux de connaitre les problemes d'ergonomie et d'accessibilite de Qt ! Et ensuite comparer avec WinForms, GTK+ et les autres.
Sous Windows ca s'ameliore mais y'a encore beaucoup de trucs a faire. Genre aucune boite de dialogue n'est native. En dehors des boutons et des scrollbars y'a encore pas mal de widgets qui n'ont pas de theme natif (genre les combobox). Sans compter que sous Windows, GTK+/GLib ne compile pas avec Visual C++ mais uniquement avec MinGW et ca peut etre pas mal handicapant.
Pour faire court, ce que les utilisateurs GTK+ supportent sous Windows et MacOSX, pas beaucoup de Linuxiens le supporteraient sur leurs propres systemes.
Que les WinForms étaient hardcodés par Intel
T'as bouffe quoi pour faire des blagues aussi droles ?
J'ai l'impression que je me suis un peu trop lache dans mon post...
Je viens de lire ca http://www.mono-project.com/WinForms
et en gros l'implementation des WinForms sous Mono c'est le meme principe que Qt : des primitives de dessin qui sont specifiques a la plateforme (~20% du code j'imagine) et tout le reste (~80%) multiplateforme. C'est un nouveau toolkit recode de 0.
Actuellement le theme des WinForms/Mono utilise un theme "Windows classic" mais rien n'empeche dans le futur (comme Qt) d'avoir des themes natifs.
Donc bref ironiquement les Windows Forms sont probablement le meilleur choix (vs GTK+) si un jour on souhaite que son soft ressemble a quelque chose sur toutes les plateformes.
Mono 2.0 supporte officiellement les Windows.Forms [...] Non c'est pas bancale
Ah oui, c'est vrai et ça ressemble même à ça : http://www.mono-project.com/Image:Monopaint.png
Ça botte quelqu'un pour son desktop Linux ?
On est quand même loin des frameworks comme Java/Qt ou les GUI sont un minimum intégrées à l'environnement cible sans compter que tout ça ça doit pas être super mature. Ca serait rigolo qu'un Qt C# stable arrive en sauveur http://www.qyoto.org/
La vérité c'est que Microsoft a tout fait pour que .NET ne soit pas multiplateforme. Si les WinForms march(ottent) sous d'autres OS c'est non-voulu ni supporté par son créateur et donc franchement pas fait pour (i.e il doit y avoir des grosses surprises)
C'est quand même super con d'avoir un tout nouveau langage/framework que l'on nous vends comme le meilleur du monde alors qu'il n'est même pas réellement multiplateforme. Mono palie tout simplement aux manquements de .NET
Conclusion: si j'avais à coder une appli multi-OS je ne le ferais clairement pas en C#/.NET/Mono
Si l'application est développée avec les outils MS, notamment les WinForms, l'application fonctionne (1) seulement sous Windows.
Si l'application est développée avec Mono, celle-ci va donc utiliser Gtk# et l'application ne tournera pas sous Mac et j'imagine que sous Windows ca doit être encore assez bancale. (1)
Java SWING ou SWT ne pose pas ce problème
Qt permet de développer pour plusieurs plateformes, WxWidgets et autres aussi.
Si utiliser .NET/Mono signifie qu'il faut recoder sa GUI pour chaque plateforme c'est un retour de 10 ans en arrière !
Existe il au moins une application graphique .NET/Mono qui soit réellement multiplateforme ?
[^] # Re: Transformer un journal en depeche de 1er page
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Free assigné pour violation de la GPL. Évalué à 3.
# Transformer un journal en depeche de 1er page
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Free assigné pour violation de la GPL. Évalué à 9.
Serait-il possible de transferer un journal pour le mettre en 1er page ?
Actuellement on se retrouve toujours avec:
- 1 journal contenant plein de commentaires
- 1 depeche sur le meme sujet beaucoup plus "pauvre" (et paradoxalement en page d'accueil alors que le journal "riche" en commentaires est "perdu" dans le site web)
Solution:
- modifier le journal en rajoutant des infos si besoin (les fameuses notes du moderateur + correction des fautes)
- transferer le journal en 1er page
Ainsi aucune information n'est dupliquee ni omise :)
[^] # Re: Cela fait longtemps que...
Posté par tanguy_k (site web personnel) . En réponse au journal Les nouveautés de Windows Seven. Évalué à 2.
"Visual Studio permet d'être bien plus productif que tout ce que j'ai pu tester sous Linux en 10 ans" (KDevelop et les autres inclus)
C'est mieux dit comme ca ?
Faut arrêter d'être sectaire, ça arrive à Microsoft et à pas mal d'autres boites de pondre des logiciels bien plus performants que leurs équivalents libres hein.
[^] # Re: Cela fait longtemps que...
Posté par tanguy_k (site web personnel) . En réponse au journal Les nouveautés de Windows Seven. Évalué à 1.
+10000
Je développe toujours sous Windows (Qt/C++) car Visual Studio permet d'être bien plus productif que gdb + vim
J'utilise des machines virtuelles qui me permettent de tester mon code sous Linux.
[^] # Re: Trolltech nous fait le coup de Flash
Posté par tanguy_k (site web personnel) . En réponse au journal Kinetic : une API d'animation pour Qt. Évalué à 3.
rooo le jolie troll ! c'est parceque c'est férié ?
Dans KDE/Plasma il y a souvent des animations/fondus/transitions quand on clique sur un bouton par exemple (voir aussi la demo de Qt : http://www.youtube.com/watch?v=f2qBUCghAJw ). Tout ca est fait a la "main" avec des timers.
Trolltech a donc créer une API pour Qt pour faciliter (et étendre) l'implémentation de ce genre d'effets.
D'une certaine façon Kinetic est un concurrent de Edje du projet E17 http://wiki.enlightenment.org/index.php/Edje
Exemple: http://www.youtube.com/watch?v=AU3wgP0_iyc
C'est très utile pour les media center genre GeeXboX ou MythTV
Trolltech n'a pas (encore) crée un plugin pour les navigateurs donc c'est vraiment pas le même but que Flash.
[^] # Re: pas tout jeune
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Campagne de dons pour le compilateur PCC. Évalué à 6.
Et c'est super pénible, surtout en C++
Ca ralentit énormément la productivité (processus modification code - compilation - test) et ca donne envie d'utiliser des langages interprétés.
Un compilo C/C++ qui se focaliserait sur la rapidité de compilation ça serait génial. Rien n'empêche après de fournir un binaire à l'utilisateur compilé avec GCC et toutes les optimisations qui vont avec.
[^] # Re: Ah oui
Posté par tanguy_k (site web personnel) . En réponse au journal Kinetic : une API d'animation pour Qt. Évalué à 10.
[^] # Re: et la marmotte...
Posté par tanguy_k (site web personnel) . En réponse au journal Webkit dans IE ?. Évalué à 2.
C'est pas sous LGPL WebKit ?
[^] # Re: bisounours
Posté par tanguy_k (site web personnel) . En réponse au journal Firefox 3.1et le support natif de Theroa/Vorbis. Évalué à 7.
* l'adoption des balises audio/video
** coté clients
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(H(...)
Déjà dans les prochaines versions de Gecko, WebKit et Opera. Pas dans Internet Explorer mais a mon avis Microsoft devra bien suivre car on est plus en 2001 avec 98% de pdm pour MS.
La courbe de IE7 a du mal et stagne depuis pratiquement 1 an
http://marketshare.hitslink.com/report.aspx?qprid=3&qpcu(...)
Alors que celle de FF3 monte en flèche
http://marketshare.hitslink.com/report.aspx?qprid=3&qpcu(...)
Safari décolle aussi et Google lance son navigateur
Ca va peut être les faire réfléchir...
** coté serveurs
En gros si YouTube adopte la balise video c'est bueno.
YouTube c'est Google, Google c'est Chrome (et aussi Firefox), Chrome utilise WebKit qui supportera la balise video.
Il ne serait pas impossible que dans le futur YouTube et les autres proposent dans leur code
if Flash version OK then Flash else HTML5
A mon avis, plus que Microsoft et IE, c'est YouTube et les autres qui vont être déterminant dans l'adoption de la balise vidéo.
Le problème c'est que HTML5 ne sort pas demain ni dans 6 mois. Même si une partie de HTML5 peu être déjà utilisée, ce n'est probablement pas avant 2012 que HTML5 sera complètement prêt cf http://wiki.whatwg.org/wiki/FAQ#When_will_HTML_5_be_finished(...)
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . En réponse au journal Qt 4.5 "Tech Preview" disponible. Évalué à 3.
Et puis moc pete regulierement les couilles a la compilation, les mots cles de Qt ne sont pas souvent reconnus par les IDE ect...
Si moc pouvait disparaitre ca serait pas un mal, quitte a rajouter quelques macros pour garder la même simplicité d'écriture. Il va surement y avoir des changements quand C++0x sera supporté.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . En réponse au journal Qt 4.5 "Tech Preview" disponible. Évalué à 5.
Ce n'est pas parceque Qt propose un ensemble de librairies cohérentes, bien foutues et bien documentées que ce n'est pas de la programmation modulaire, au contraire.
http://doc.trolltech.com/main-snapshot/modules.html
Si tu ne fais pas de SQL, tu ne depends pas de QtSQL, pareil pour QtWebKit, QtGui, Phonon, QtXML, QtNetwork ect...
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . En réponse au journal Qt 4.5 "Tech Preview" disponible. Évalué à 3.
Il me semblait que sous Windows il y avait beaucoup moins de problème car les compilos les plus courants "comprennent" le format généré par Visual C++. En même temps j'ai jamais essayé, donc si tu dis que ça marche pas, je te crois :p
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . En réponse au journal Qt 4.5 "Tech Preview" disponible. Évalué à 2.
Désolé je ne savais pas que ça avait changé.
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . En réponse au journal Qt 4.5 "Tech Preview" disponible. Évalué à 3.
http://www.google.com/search?sitesearch=lists.trolltech.com%(...)
pas tres folichon :/
Tu peux toujours essayer de compiler Qt avec C++ Builder, dans QtGlobal il y a bien Q_CC_BOR cf http://doc.trolltech.com/main-snapshot/qtglobal.html#Q_CC_BO(...) et il y a aussi un makespec win32-borland
Mais je doute que les versions récentes de Qt compilent avec :/
http://www.developpez.net/forums/d609411/c-cpp/bibliotheques(...)
En revanche il est peut etre possible que Qt compilé avec MSVC fonctionne sous C++ Builder. En effet après il reste juste les .h et .dll/.lib à faire fonctionner.
Qt compilé avec MSVC http://qt.windows.binaries.googlepages.com/index.html (Trolltech fournit seulement Qt compilé sous MinGW)
[^] # Re: Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . En réponse au journal Qt 4.5 "Tech Preview" disponible. Évalué à 6.
Au contraire c'est vraiment pas du de choisir !
J'ai souvent lu que WxWidgets c'était pas vraiment pas le top (API façon MFC vieillotte, difficulté à obtenir une GUI propre sur chaque OS...). Par exemple VLC est passé de WxWidgets à Qt sans aucun regret du coté des devs (cf mailing-list).
Pour ce qui est du support des compilos, Qt supporte tous les compilos récents : GCC, MinGW, Visual C++ (MSVC > 7.1), Intel CC...
http://trolltech.com/developer/supported-platforms
(GLib/GTK+ par comparaison ne compile pas avec Visual C++)
Pour ce qui est de Borland C++, c'est un compilo mort depuis 10 ans
http://en.wikipedia.org/wiki/Borland_C%2B%2B
Il y a CodeGear C++ Builder http://en.wikipedia.org/wiki/C%2B%2B_builder
Mais ce n'est apparemment pas supporté par WxWidgets non plus
http://www.wxwidgets.org/about/feature2.htm
Après googlage, C++ Builder ne fonctionnerait pas avec d'autres bibliothèques externes C/C++ car il n'est pas fait pour.
Bref si tu veux faire du multiplateforme en C++, utilise Qt, t'en seras très content.
# Impressionnant le rythme de sortie des versions !
Posté par tanguy_k (site web personnel) . En réponse au journal Qt 4.5 "Tech Preview" disponible. Évalué à 5.
[^] # Re: FLTK
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Dillo 2.0 : Le Web en toute légèreté. Évalué à 2.
Dans mon cas un composant plus performant comme Dillo aurait ete utile, j'ai pas trop envie de me trainer QtWebKit qui pompe bien 10Mo en plus :/
Sous Windows il est assez facile d'embarquer Internet Explorer via ActiveX et ca prend pas beaucoup de ram (puisque deja en memoire au final) mais c'est quand meme moyen comme solution pour un libriste (!)
# FLTK
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Dillo 2.0 : Le Web en toute légèreté. Évalué à 4.
J'aurais plutot vu Dillo comme un composant/widget pour Qt ou GTK facilement integrable dans d'autres programmes (comme Scintilla http://fr.wikipedia.org/wiki/Scintilla ).
Il y a beaucoup d'applications qui ont besoin d'un moteur HTML léger pour afficher l'aide, ou par exemple les lecteurs audio pour afficher la page Wikipedia d'un artiste. Pour ce type de fonctionnalités, sortir les bulldozeurs Webkit/Mozilla est inadapté.
[^] # Re: .NET et portabilité GUI = 2
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
D'ailleurs Qt gère en partie certaines de ces problématiques
cf http://doc.trolltech.com/4.4/qmenubar.html#details
[^] # Re: .NET et portabilité GUI = 2
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 3.
Ouai enfin la c'est quand meme du chipo ou alors on parle pas du meme truc. Moi je pensais a ca par exemple : titre de la fenetre = "Nom de l'appli - nom du fichier ouvert" qui est peut etre different suivant les guidelines des OS. Ou encore l'emplacement du "panneau de config" qui est dans le menu "tools" ou "edit".
Si tu pinailles la dessus et 3 pauv #ifdef dans ton code pour arranger ca, alors je comprends pas pourquoi selon ton point de vue, les WinForms sous Linux/MacOS ne meriteraient pas le terme "experimental" :)
> Faire un theme natif, c'est pas du coloriage
Sans dec. J'ai déjà dis le contraire ?
C'etait en reponse a ton lien http://www.gnome-look.org/content/show.php/show.php?content=(...)
Si tu regardes le contenu, c'est justement du "coloriage", autrement j'aurais pas evoque ce sujet.
t'as jamais eu l'idée qu'on pouvait utiliser les widgets natifs dans un thème ?
Je crois qu'on tourne en rond "Faire un theme natif, c'est pas du coloriage mais utiliser l'API de la plateforme"
Qt s'intègre très mal sous Gnome par exemple qui a une gestion de layout complètement différente
La c'est sur, on tourne vraiment en rond cf les liens au dessus
http://doc.trolltech.com/4.4/qdialogbuttonbox.html http://doc.trolltech.com/4.2/qt4-2-intro.html#desktop-integr(...) (ca existe depuis 2 ans) http://labs.trolltech.com/blogs/2008/10/02/qgtkstyle-now-on-(...)
[^] # Re: .NET et portabilité GUI = 2
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 5.
Rectificatif : Qt resoud bien mieux ce genre de problemes que n'importe qu'elle autre toolkit, et de tres tres tres loin.
C'est meme le fond de commerce de Trolltech. Ca fait plus de 10 ans que Qt fonctionne sur Win/Linux/Mac. Ca tourne meme sur WinCE en natif depuis peu (!)
ordre des boutons
http://doc.trolltech.com/4.4/qdialogbuttonbox.html
style de nommage
En partie, ca depend ce que t'appelle style de nommage
Par exemple voici un wizard Qt sous differents OS :
http://doc.trolltech.com/4.4/qwizard.html#wizard-look-and-fe(...)
Apres c'est sur que le titre d'une fenetre faudra peut etre faire des #ifdef mais c'est tout a fait normal.
boîtes de dialogue
Toutes les boites de dialogues sont natives avec Qt. Meme celles pour l'impression http://doc.trolltech.com/4.4/qprintdialog.html ou le systray http://doc.trolltech.com/4.4/qsystemtrayicon.html
Au passage, Qt s'integre parfaitement a GNOME depuis peu (meme les boites de dialogues) (ca fonctionne aussi sous Windows !)
http://labs.trolltech.com/blogs/2008/10/02/qgtkstyle-now-on-(...)
C'est un thème comme un autre
Non justement ! le style MacOSX c'est pas juste une scrollbar bleue. Typiquement sous Windows il est impossible de faire la difference entre une appli Qt et une appli MFC/WTL. pareil sous MacOSX, Qt utilise Carbon et bientot Cocoa (ce qui va resoudre les derniers problemes connus).
Faire un theme natif, c'est pas du coloriage mais utiliser l'API de la plateforme et c'est pas franchement evident a faire. Avant que WinForms/GTK+ arrivent a un niveau equivalent du Qt de 2008 il va falloir attendre encore quelques longues annees.
Quand on lit la doc de Qt, il y a plein d'endroits ou il a des trucs specifiques a une plateforme ou une autre, des methodes qui ne font rien sur certaines plateformes ect... et c'est hyper bien foutu et pour aller plus loin il y a aussi des vrais exemples http://doc.trolltech.com/qq/qq23-layouts.html http://doc.trolltech.com/qq/qq19-buttons.html
WinForms ne pourra jamais faire ca car l'API est controlee par Microsoft et a ete concu seulement pour fonctionner sous Windows contairement a Qt qui est fait pour des le depart.
Au final je te rappelle quand même que ta remarque initiale portait sur le côté "expérimental"
Oui c'est vrai, c'est pourquoi j'ai indique que "je me suis un peu trop lache dans mon post" car la derniere fois que j'ai utilise C#, WinForms utilisait Wine et GTK+ sous Mac utilisait X11 (!)
Neamoins entre
http://picasaweb.google.co.uk/icefox/AroraScreenshots#523144(...)
http://labs.trolltech.com/blogs/wp-content/uploads/2008/02/d(...)
http://code.google.com/p/arora/wiki/Screenshots
et ca
http://developer.imendio.com/sites/developer.imendio.com/fil(...)
http://www.mono-project.com/Image:Monopaint.png
Ba y'a trop pas photo
[^] # Re: .NET et portabilité GUI = 2
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 3.
AWT, WxWidgets, SWT et probablement un paquet d'autres... meme les WinForms/Mono puisqu'ils avaient commences par faire un backend GTK+
Il est probable que la majorite des toolkits graphiques utilisent cette methode. Par exemple les MFC et autres WFC sont des bindings par dessus les widgets win32.
Et perso j'etais resté sur l'idee que les WinForms/Mono etaient implementees en utilisant Wine d'ou mon post juste au dessus.
Qt c'est gentil [...] mais y'a encore du boulot à faire côté ergonomie et accessibilité.
Je suis tres curieux de connaitre les problemes d'ergonomie et d'accessibilite de Qt ! Et ensuite comparer avec WinForms, GTK+ et les autres.
Gimp ou Pidjin arrivent à ne pas être trop moches sous Windows ou MacOSX
Pour MacOSX, suffit de regarder les screenshots que j'ai balance au dessus
http://developer.imendio.com/sites/developer.imendio.com/fil(...)
http://developer.imendio.com/sites/developer.imendio.com/fil(...)
Sous MacOSX ton soft GTK+ a la meme gueule que sous Linux :/
Sous Windows ca s'ameliore mais y'a encore beaucoup de trucs a faire. Genre aucune boite de dialogue n'est native. En dehors des boutons et des scrollbars y'a encore pas mal de widgets qui n'ont pas de theme natif (genre les combobox). Sans compter que sous Windows, GTK+/GLib ne compile pas avec Visual C++ mais uniquement avec MinGW et ca peut etre pas mal handicapant.
Pour faire court, ce que les utilisateurs GTK+ supportent sous Windows et MacOSX, pas beaucoup de Linuxiens le supporteraient sur leurs propres systemes.
Que les WinForms étaient hardcodés par Intel
T'as bouffe quoi pour faire des blagues aussi droles ?
[^] # Re: .NET et portabilité GUI = 2
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 5.
Je viens de lire ca http://www.mono-project.com/WinForms
et en gros l'implementation des WinForms sous Mono c'est le meme principe que Qt : des primitives de dessin qui sont specifiques a la plateforme (~20% du code j'imagine) et tout le reste (~80%) multiplateforme. C'est un nouveau toolkit recode de 0.
Actuellement le theme des WinForms/Mono utilise un theme "Windows classic" mais rien n'empeche dans le futur (comme Qt) d'avoir des themes natifs.
Donc bref ironiquement les Windows Forms sont probablement le meilleur choix (vs GTK+) si un jour on souhaite que son soft ressemble a quelque chose sur toutes les plateformes.
[^] # Re: .NET et portabilité GUI = 2
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
Mono 2.0 supporte officiellement les Windows.Forms [...] Non c'est pas bancale
Ah oui, c'est vrai et ça ressemble même à ça :
http://www.mono-project.com/Image:Monopaint.png
Ça botte quelqu'un pour son desktop Linux ?
y'a GTK sous mac
Depuis 1 semaine LOL
Voila un screenshot : http://developer.imendio.com/sites/developer.imendio.com/fil(...)
Bref GTK Windows/Mac même combat que les WinForms sous Linux : personne ne veut de ça !
On est quand même loin des frameworks comme Java/Qt ou les GUI sont un minimum intégrées à l'environnement cible sans compter que tout ça ça doit pas être super mature. Ca serait rigolo qu'un Qt C# stable arrive en sauveur http://www.qyoto.org/
La vérité c'est que Microsoft a tout fait pour que .NET ne soit pas multiplateforme. Si les WinForms march(ottent) sous d'autres OS c'est non-voulu ni supporté par son créateur et donc franchement pas fait pour (i.e il doit y avoir des grosses surprises)
C'est quand même super con d'avoir un tout nouveau langage/framework que l'on nous vends comme le meilleur du monde alors qu'il n'est même pas réellement multiplateforme. Mono palie tout simplement aux manquements de .NET
Conclusion: si j'avais à coder une appli multi-OS je ne le ferais clairement pas en C#/.NET/Mono
# .NET et portabilité GUI = 2
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
Si l'application est développée avec Mono, celle-ci va donc utiliser Gtk# et l'application ne tournera pas sous Mac et j'imagine que sous Windows ca doit être encore assez bancale. (1)
Java SWING ou SWT ne pose pas ce problème
Qt permet de développer pour plusieurs plateformes, WxWidgets et autres aussi.
Si utiliser .NET/Mono signifie qu'il faut recoder sa GUI pour chaque plateforme c'est un retour de 10 ans en arrière !
Existe il au moins une application graphique .NET/Mono qui soit réellement multiplateforme ?
(1) fonctionne != experimental