Pour revenir sur l'histoire du wiki, KDE a mis en place un wiki pour les développeurs : TechBase
Il s'est avere que c'est un franc succes et ils ont decide il y a quelques jours de creer un wiki oriente utilisateurs : UserBase http://dot.kde.org/1221824063/
Les tutorials pour developper avec KDE sont sur TechBase http://techbase.kde.org/Development/Tutorials
Faire en sorte qu'une recherche sur Edge ou EFL donne quelque chose sur Google
En tout cas si vous voulez que la sauce prenne, y'a pas de miracle : communiquer, communiquer, communiquer !
Faire un wiki, deja rien que transformer ca http://homepages.pathfinder.gr/kazanaki/contrib/ en wiki, ca serait pas mal (la ca fait un peu HOWTO de 1996...)
Informer les gens sur le fait que c'est multiplateforme, ecrire des tutoriels (ou au moins pointer sur du code simple qui fait des trucs simples) et dans le futur essayer de faire une jolie doc a la Qt (http://doc.trolltech.com/ ), mettre des screenshots sur Wikipedia...
Faire en sorte qu'une recherche sur Edge ou EFL donne quelque chose sur Google.
Faire en sorte que le projet soit vraiment independant de Enlightenment.
Parceque malheureusement la visibilite des EFL est completement inexistante :/
Sans communication, c'est evident, c'est sur a 100%, ca va jamais prendre (deja qu'en communiquant c'est pas evident...)
J'avoue toujours avoir eu du mal sur les abstractions de moteur SQL, car il y a souvent de legere difference dans leur support du langage SQL lui meme et on finit toujours par plus ou moins avoir un truc qui fait pouf dans un coin.
Ca fait souvent pouf dans un coin, donc oui il vaut mieux tester avant de changer de backend mais en l'occurrence si pas d'abstraction alors il faut tout re-ecrire si jamais on veut changer, c con qd meme...
Par contre, je n'ai jamais utilise Phonon, et je n'en connais ni les capacite, ni les limite.
C'est encore jeune mais c'est vraiment bien, je code (un peu moins en ce moment, manque de temps) des backends pour Phonon http://code.google.com/p/phonon-vlc-mplayer/ + un player multimedia
et il n'y a pas que moi qui le dit : http://www.valdyas.org/fading/index.cgi/hacking/phonon.html
Amarok 2 utilise desormais Phonon
Phonon en lui meme est mature, en revanche les differents backends beaucoup moins mais ca va venir car il y a plein d'acteurs : Trolltech, Amarok/KDE, des devs de VLC...
C'est un peu le meme probleme qu'avec les abstractions SQL, ca fait souvent pouf dans un coin mais c'est quand meme vachement mieux que d'etre lie a vie (ou presque) a un seul moteur (c'est par exemple le cas de SMPlayer)
Il faut vraiment voir que la ou les EFL excelle, c'est lorsqu'on veut faire du soft pour un terminal genre media player ou des jeux en fait. Un traitement de texte ou un tableur en EFL, je doute que ca ai de l'interet...
Avoir dans les applications quelques effets graphiques facon EFL et une gestion des themes poussée, ca peu etre pas mal. On a bien du bling-bling dans le desktop (Compiz) alors pourquoi pas un peu dans les applications aussi.
Si Trolltech inclu un ersatz de EFL dans Qt, quelle sera la future des EFL ? un marche de niche ? un truc experimental et uniquement utilise dans la sphere E17 ?
Rien qu'en lisant le lien que tu fournis sur la genese de l'application
intuitivement j'ai mis le lien car ca me paraissait bien compliqué pour une simple demo :)
L'intro sur les EFL explique aussi en quoi c'est different de l'approche "traditionnel" http://homepages.pathfinder.gr/kazanaki/contrib/ch03.html
pour le SQL par exemple, il est plus simple d'utiliser directement l'API de SQLite plutot que de reinventer une abstraction entre les deux qui ne serviraient pas reellement a grand chose vu la simplicite d'une tel API.
L'intérêt d'avoir une abstraction c'est de pouvoir changer de moteur SQL en changeant simplement un paramètre + d'avoir une API consistante avec le reste. C'est quand même un bel avantage, meme rien que pour des tests.
J'utilise Phonon qui est abstraction multimedia qui a beaucoup ete decrie a ces debuts et le resultat est pourtant assez magnifique : 4 lignes de code et je peux lire une video ou un mp3 Et je peux changer d'engine suivant l'OS ou ce que je veux faire. Tout ca en gardant une API simple et consistante avec le reste du framework.
on a des engines natif pour Linux/Windows/Windows CE/MacOsX
Ca c'est intéressant ! je savais pas du tout.
Et ils communiquent pas trop la dessus... impossible de trouver un lien
J'ai remarque un truc : les EFL c'est sur le site web de Enlightenment, les snapshots sortent en meme temps que celles de Enlightenment, le SVN est le meme ect... Y'a pas mieux pour faire l'amalgame dans la tete des gens.
Et question conne : pourquoi diable avoir codé un nouveau toolkit ? c'etait pas possible d'integrer toutes ces idees dans GTK+ (Qt c'est plus difficile car controller par Trolltech) ? (bon ok changer le canvas de GTK+ ca doit pas etre simple...)
J'ai toujours vu Rasterman comme une grande gueule "je vais tous vous niquer avec mon truc" :) alors que j'ai souvent lu que imlib1 était un gros boulet qu'a du se trainer GNOME pendant un petit moment.
En tout cas les marketeux devraient etre content. A mon epoque, mes marketeux cheries me prenaient le chou pour foutre des effets partout avec des themes plus moches les uns que les autres dans l'application :/
SMOKE is a introspective wrapper around the Qt and KDE frameworks.
All classes, all methods, with all arguments, along with various flags reflecting staticness, virtuality, etc. are stored into cross-referencing arrays for fast lookups. One can thus read (and call) the whole Qt API by simply reading/searching these arrays.
J'avais meme lu a l'epoque (sur dot.kde quand les premiers bindings ont ete developpes par Richard Dale) qu'il etait techniquement plus facile de faire un binding automatise pour C++ que C. (En revanche a la mano c'est plus facile avec du C d'apres ce que j'ai compris).
C++ est plus verbeux et donne plus "d'informations" que le language C ou beaucoup de choses sont implicites. Par en C++ il y a toujours un constructeur et un destructeur, le C ne comporte pas cette sémantique et donc il faut utiliser des constructions implicites du type toto_new(), toto_delete()
Bref comme on a plus d'infos en C++, il est plus facile de creer automatiquement un binding.
Faut le prendre dans le sens "marketing" du terme. Tout comme GTK+ etait lie a GIMP en son temps. Et je pense que ca peut etre un handicap.
Typiquement, DR17 est percu comme une sorte de "DukeNukem Forever" et par conséquent j'imagine que la grande majorite des gens pensent la meme chose des EFL.
J'imagine que EFL doit etre plus simple/puissant puisqu'il existe le projet QEdje http://dev.openbossa.org/trac/qedje (mon raisonnement sans etre aller voir le code : si QEdje existe, ca doit etre que Edje doit avoir un avantage par rapport a Qt)
Dans Qt-4.5 il est prevu une API pour faire des animations GUI.
Qt est peut etre un peu moins doué pour les GUI avec des effets dans tous les sens. Gardons à l'esprit que Qt evolue tres vite et que ce manque va etre comblé rapidement.
En attendant, Qt dispo de fonctionnalites moins bling-bling mais nettement plus interessantes au quotidien qu'aucun autre framework ne propose : SQL, WebKit, XML, OpenGL, scripting, networking, multimedia, SVG, Windows/Linux/MacOSX...
le seul interet de QTopia par rapport aux EFL, c'est quand meme juste que les applis sont deja ecrite
"juste" ? mais c'est énorme comme avantage !
L'intérêt de Qt c'est à terme un paquet de logiciels. Par exemple KDE4 est en train d'être porté sur Maemo.
EFL c'est peut être super cool, super beau ect... mais malheureusement ca risque de rester anecdotique comme librairie, trop lié a un WM + écrasé entre GLib/GTK+ et Qt.
tu peux a mon avis faire des choses nettement plus joli et anime avec les EFL que tu ne peux le faire avec QTopia
J'aimerais bien voir un truc fait avec EFL qui ne soit pas faisable avec Qt...
Pourtant ca l'est cf mon commentaire juste en dessous.
La meilleure facon de voir si un projet est mort ou pas est de matter les logs SVN : http://dev.openwengo.org/trac/openwengo/trac.fcgi/browser pas de commits depuis plus de 10 mois (date a laquelle Wengo a licencie tout le monde). Maintenant le repo se trouve chez MBDSYS : http://hg.qutecom.org/ et la le log est beaucoup plus parlant :)
Wengo la boite qui développait WengoPhone a changé de business.
MBDSYS qui a repris le bébé a beaucoup mois de ressources que Wengo pour continuer le développement. A l'époque de Wengo, on était 7 personnes environ sur le logiciel.
D'ailleurs aucun des anciens dev (moi le premier) n'a codé à ma connaissance sur QuteCom donc c'est encore plus tendu pour MBDSYS d'avancer. Pour ma part, un ras le bol, l'envie de faire d'autres trucs... Je suis toujours la mailing-list de loin...
> J'adore les gens qui assène des vérité qu'ils sortent d'on ne sais où ?
Ma propre expérience + celle de pas mal d'autres dev.
> la plupart des applis gui en C qui marche très bien il y en a un paquet
Et ben dit toi que si ces applis avaient été développé en Python par exemple, et ben les développeurs auraient été plus vite ou/et auraient ajouté plus de fonctionnalités.
C'est comme ça, j'invente rien, n'importe quel dev qui a fait du C et du Python te dira que l'on développe plus vite en Python.
Il est par exemple aussi communément admis que l'on développe 2x plus vite en Java qu'en C++ (source : Bruce Eckel).
Ca veut pas dire que le C est un mauvais langage ou que les applis codées avec sont mauvaises, ça veut simplement dire que dans pas mal de cas (de plus en plus avec le temps), il est tout simplement inadapté.
Tout comme un jour C++, Java, C#... seront surement replacés par des langages plus performants.
Libre après aux gens d'utiliser des langages moins adaptés, je vais pas aller les bruler hein ! j'ai longtemps développé en C mais je suis pas marié avec un langage en particulier : j'utilise celui qui semble être le plus adapté pour ce que je veux faire ./
Oui c'est vrai, mais bon c'était plus du "proof of concept" qu'autre chose.
De toute façon l'intérêt est franchement pas évident vu que GTK+ / C existe.
> il est également temps d'abandonner Unix qui est aussi vieux
Ma phrase signifiait pas que "c'est vieux donc c'est nul" mais qu'il y a eu des avancés importante entre le langage C et les langages dit modernes tout comme entre la Ford T et la dernière Renault.
D'un autre coté je me sers tous les jours de la vaisselle de ma grand mère, on a pas encore fait mieux, et pourtant dieu sait que ça date !
> Promis le jour où il y a un binding C (officiel) pour Qt j'essaie pour voir.
AMHA Il n'y aura jamais de binding C pour Qt. Mapper Qt qui utilise intensivement le modèle objet par un système procédurale serait à mon avis beaucoup trop compliqué et donnerait un truc bancale.
Laissons le langage C pour le noyau, les drivers ect...
Pour les interfaces graphiques, des langages comme C++, Python, Java, C#, Ruby ect... sont infiniment plus adaptés. Ca tombe bien, il y a des bindings Qt pour ces langages.
Les bindings Python (PyQt) et Java (Qt Jambi) sont considérés comme stables et sont régulièrement utilisés par des applications, en revanche les bindings C# et Ruby ne sont pas encore vraiment utilisés et doivent être surement encore trop jeune.
Pour moi (je vais me faire moinser, tant pis), le fait que le projet GNOME souhaite à tout prix utiliser le langage C est une hérésie. Et Miguel de Icaza a du bien s'en rendre compte, d'où la création de Mono.
Bref pour les interfaces graphiques, il est temps d'abandonner le C qui date d'il y a 40 ans pour un truc plus moderne comme Python, le résultat n'en sera que meilleur.
Pour le web ca fait longtemps que l'on ne fait plus de CGI en C alors admettons que le C est aussi dépassé pour la création d'interfaces graphiques.
David Hirschmann
Director
David joined in May 2002 from UBS Warburg where he worked in the Investment Banking division focusing on financial sponsors coverage. Prior to joining UBS Warburg, David spent fifteen months at ABN Amro in Paris as a Credit Analyst working on structured and leveraged finance deals. David holds an Economic and Finance Degree from HEC, a French premier business school.
> ça n'a rien à voir avec de la branlette intellectuelle
Si clairement, c'est hyper pénible de devoir recompiler un soft. C'était marrant y'a 10 ans quand Linux commençait a être connu, mais 10 ans plus tard le souhait serait d'avoir un OS "userfriendly" qui pourrait avoir une vrai visibilité et pas seulement 1% de PDM.
(ouai parceque c'est qd même un peu le but, genre avoir 10% de PDM et répandre la philosophie du libre + que les constructeurs, webmasters, éditeurs ne nous ignorent plus).
Mildred a soulevé un problème à mon avis important (un frein - parmi d'autres - à l'adoption de Linux) : il n'y a aucun moyen d'installer la dernière version d'un logiciel facilement (sans recompiler je veux dire) On ne pourra pas empêcher les gens de vouloir les dernières versions des logiciels. Ce n'est pas possible. A mon avis, ce serait bien de commencer à réfléchir à une manière de résoudre ce problème.
Recompiler un soft n'est pas une alternative viable à ce problème : c'est un truc de geek et restera un truc de geek.
Nous somme ici des passionnés d'informatique et nous passons des heures à bidouiller nos linuxette. Il faut prendre du recul par rapport à ça et se rendre compte que pour un utilisateur normal c'est ridicule de lire un wiki + faire un ./configure juste pour installer le dernier soft.
De même l'utilisateur normal te sortira un gros "mais c'est tout pourri ton truc" s'il ne peut pas tester facilement le dernier truc qui vient de sortir.
Dsl on a pas les mêmes priorités dans la vie, perso j'ai plein d'autres choses à faire bien plus intéressantes que de m'amuser à recompiler mes softs.
J'appelle ça de la branlette intellectuelle.
LFS et recompiler le kernel 2.0.36 c'était à la mode y'a 10 ans.
Abiword n'utilise PAS GTK+ sous MacOSX et sous Windows !
cf http://www.redhatmagazine.com/2008/05/08/abiword-team-interv(...) We use the native toolkit on every platform. That means GTK+ on unix-like platforms. Cocoa on OSX [...] and the Windows API and GDI on Windows platforms. [...] one really annoying thing we have to deal with is having 3 separate graphics classes (render engines)–we really want to get rid of that.
GTK+ c'est moche sous Windows, sous MacOS c'est ignoble.
GTK+ est tres tres mauvais niveau mutliplateforme, faut vraiment etre de mauvaise fois ou aveugle pour soutenir le contraire (surtout comparé à Qt)
> faire "./configure;make;sudo make install" c'est pas la mort
Super, et on est en 2008... ça fait peur...
Compiler un soft c'est peut être pas compliqué, mais c'est ultra chiant et inutile, ça prend du temps pour rien.
- Il faut toutes les dépendances en paquet -devel (paye ton espace disque et ta bande passante)
- Faut récupérer le source du soft
- Lire la doc est souvent indispensable car il y a régulièrement des astuces ou autres
- Attendre que ca compile et si ca foire (ca arrive souvent cf tous les messages sur les forums), repartir à l'étape d'avant
- En plus ca pete légèrement le système de package et ca peut provoquer des conflits
Compiler VLC sur une distrib toute neuve ca doit bien prendre 2-3h, super, que du bonheur ! (1)
Il existe des gens sur terre qui ont autre chose a faire que passer leur temps a lire des wiki et recompiler des softs, genre mouler par exemple :p
Le problème soulevé par Mildred fait surement partie des problèmes qui font que Linux ne passera jamais les 5% de part de marché (2).
Déjà s'il n'y avait pas 350 distributions différentes (3) et surtout 15 systèmes de paquet différents ca aiderait grave.
> Le développement s'est sensiblement accéléré depuis que j'ai mon ASUS EeePC 900 !
C'est intéressant ça !
Peux tu nous indiquer les avantages et surtout les inconvénients d'utiliser un netbook pour du développement ?
La résolution réduite de l'écran c'est pas pénible pour éditer du texte ? le clavier n'est il pas inadapté ? souffre t-on d'un manque de puissance ? ect...
Ton expérience avec ce type de machine pourrait surement intéresser d'autres développeurs...
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . En réponse au journal E17, ça avance. Évalué à 2.
Il s'est avere que c'est un franc succes et ils ont decide il y a quelques jours de creer un wiki oriente utilisateurs : UserBase http://dot.kde.org/1221824063/
Les tutorials pour developper avec KDE sont sur TechBase http://techbase.kde.org/Development/Tutorials
Faire en sorte qu'une recherche sur Edge ou EFL donne quelque chose sur Google
En meme temps c'est normal ca s'appelle Edje et non Edge et le 1er lien donne ca http://wiki.enlightenment.org/index.php/Edje :p
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . En réponse au journal E17, ça avance. Évalué à 2.
Le futur c'est peut etre ca
http://dev.openbossa.org/trac/qedje
Qt/GTK + des bouts de EFL
En tout cas si vous voulez que la sauce prenne, y'a pas de miracle : communiquer, communiquer, communiquer !
Faire un wiki, deja rien que transformer ca
http://homepages.pathfinder.gr/kazanaki/contrib/ en wiki, ca serait pas mal (la ca fait un peu HOWTO de 1996...)
Informer les gens sur le fait que c'est multiplateforme, ecrire des tutoriels (ou au moins pointer sur du code simple qui fait des trucs simples) et dans le futur essayer de faire une jolie doc a la Qt (http://doc.trolltech.com/ ), mettre des screenshots sur Wikipedia...
Faire en sorte qu'une recherche sur Edge ou EFL donne quelque chose sur Google.
Faire en sorte que le projet soit vraiment independant de Enlightenment.
Parceque malheureusement la visibilite des EFL est completement inexistante :/
Sans communication, c'est evident, c'est sur a 100%, ca va jamais prendre (deja qu'en communiquant c'est pas evident...)
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . En réponse au journal E17, ça avance. Évalué à 3.
Ca fait souvent pouf dans un coin, donc oui il vaut mieux tester avant de changer de backend mais en l'occurrence si pas d'abstraction alors il faut tout re-ecrire si jamais on veut changer, c con qd meme...
Par contre, je n'ai jamais utilise Phonon, et je n'en connais ni les capacite, ni les limite.
C'est encore jeune mais c'est vraiment bien, je code (un peu moins en ce moment, manque de temps) des backends pour Phonon http://code.google.com/p/phonon-vlc-mplayer/ + un player multimedia
et il n'y a pas que moi qui le dit : http://www.valdyas.org/fading/index.cgi/hacking/phonon.html
Amarok 2 utilise desormais Phonon
Phonon en lui meme est mature, en revanche les differents backends beaucoup moins mais ca va venir car il y a plein d'acteurs : Trolltech, Amarok/KDE, des devs de VLC...
C'est un peu le meme probleme qu'avec les abstractions SQL, ca fait souvent pouf dans un coin mais c'est quand meme vachement mieux que d'etre lie a vie (ou presque) a un seul moteur (c'est par exemple le cas de SMPlayer)
Il faut vraiment voir que la ou les EFL excelle, c'est lorsqu'on veut faire du soft pour un terminal genre media player ou des jeux en fait. Un traitement de texte ou un tableur en EFL, je doute que ca ai de l'interet...
Avoir dans les applications quelques effets graphiques facon EFL et une gestion des themes poussée, ca peu etre pas mal. On a bien du bling-bling dans le desktop (Compiz) alors pourquoi pas un peu dans les applications aussi.
Si Trolltech inclu un ersatz de EFL dans Qt, quelle sera la future des EFL ? un marche de niche ? un truc experimental et uniquement utilise dans la sphere E17 ?
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . En réponse au journal E17, ça avance. Évalué à 7.
intuitivement j'ai mis le lien car ca me paraissait bien compliqué pour une simple demo :)
L'intro sur les EFL explique aussi en quoi c'est different de l'approche "traditionnel"
http://homepages.pathfinder.gr/kazanaki/contrib/ch03.html
pour le SQL par exemple, il est plus simple d'utiliser directement l'API de SQLite plutot que de reinventer une abstraction entre les deux qui ne serviraient pas reellement a grand chose vu la simplicite d'une tel API.
L'intérêt d'avoir une abstraction c'est de pouvoir changer de moteur SQL en changeant simplement un paramètre + d'avoir une API consistante avec le reste. C'est quand même un bel avantage, meme rien que pour des tests.
J'utilise Phonon qui est abstraction multimedia qui a beaucoup ete decrie a ces debuts et le resultat est pourtant assez magnifique : 4 lignes de code et je peux lire une video ou un mp3 Et je peux changer d'engine suivant l'OS ou ce que je veux faire. Tout ca en gardant une API simple et consistante avec le reste du framework.
on a des engines natif pour Linux/Windows/Windows CE/MacOsX
Ca c'est intéressant ! je savais pas du tout.
Et ils communiquent pas trop la dessus... impossible de trouver un lien
J'ai remarque un truc : les EFL c'est sur le site web de Enlightenment, les snapshots sortent en meme temps que celles de Enlightenment, le SVN est le meme ect... Y'a pas mieux pour faire l'amalgame dans la tete des gens.
Et question conne : pourquoi diable avoir codé un nouveau toolkit ? c'etait pas possible d'integrer toutes ces idees dans GTK+ (Qt c'est plus difficile car controller par Trolltech) ? (bon ok changer le canvas de GTK+ ca doit pas etre simple...)
J'ai toujours vu Rasterman comme une grande gueule "je vais tous vous niquer avec mon truc" :) alors que j'ai souvent lu que imlib1 était un gros boulet qu'a du se trainer GNOME pendant un petit moment.
En tout cas les marketeux devraient etre content. A mon epoque, mes marketeux cheries me prenaient le chou pour foutre des effets partout avec des themes plus moches les uns que les autres dans l'application :/
[^] # Re: Un air de renouveau, oui, mais de quelle année ?
Posté par tanguy_k (site web personnel) . En réponse à la dépêche GNOME 2.24 : un air de renouveau. Évalué à 6.
Voici l'astuce que t'as loupée :
http://techbase.kde.org/Development/Languages/Smoke
SMOKE is a introspective wrapper around the Qt and KDE frameworks.
All classes, all methods, with all arguments, along with various flags reflecting staticness, virtuality, etc. are stored into cross-referencing arrays for fast lookups. One can thus read (and call) the whole Qt API by simply reading/searching these arrays.
J'avais meme lu a l'epoque (sur dot.kde quand les premiers bindings ont ete developpes par Richard Dale) qu'il etait techniquement plus facile de faire un binding automatise pour C++ que C. (En revanche a la mano c'est plus facile avec du C d'apres ce que j'ai compris).
C++ est plus verbeux et donne plus "d'informations" que le language C ou beaucoup de choses sont implicites. Par en C++ il y a toujours un constructeur et un destructeur, le C ne comporte pas cette sémantique et donc il faut utiliser des constructions implicites du type toto_new(), toto_delete()
Bref comme on a plus d'infos en C++, il est plus facile de creer automatiquement un binding.
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . En réponse au journal E17, ça avance. Évalué à 2.
Faut le prendre dans le sens "marketing" du terme. Tout comme GTK+ etait lie a GIMP en son temps. Et je pense que ca peut etre un handicap.
Typiquement, DR17 est percu comme une sorte de "DukeNukem Forever" et par conséquent j'imagine que la grande majorite des gens pensent la meme chose des EFL.
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . En réponse au journal E17, ça avance. Évalué à 5.
C'est possible http://www.youtube.com/watch?v=f2qBUCghAJw&feature=relat(...)
C'est la demo qui est livree avec Qt sous Windows/Linux/MacOSX
(voila un post qui explique la genese de la demo Qt http://labs.trolltech.com/blogs/2007/04/11/qt-demo/ )
J'imagine que EFL doit etre plus simple/puissant puisqu'il existe le projet QEdje http://dev.openbossa.org/trac/qedje (mon raisonnement sans etre aller voir le code : si QEdje existe, ca doit etre que Edje doit avoir un avantage par rapport a Qt)
Dans Qt-4.5 il est prevu une API pour faire des animations GUI.
D'autres videos sur Youtube a propos des possibilités graphiques de Qt
http://www.youtube.com/watch?v=TLbO73oQaeU&feature=relat(...)
http://www.youtube.com/watch?v=uxQFY4mp_E0&feature=relat(...)
http://www.youtube.com/watch?v=uwE_UIHSWnY&feature=relat(...)
Qt est peut etre un peu moins doué pour les GUI avec des effets dans tous les sens. Gardons à l'esprit que Qt evolue tres vite et que ce manque va etre comblé rapidement.
En attendant, Qt dispo de fonctionnalites moins bling-bling mais nettement plus interessantes au quotidien qu'aucun autre framework ne propose : SQL, WebKit, XML, OpenGL, scripting, networking, multimedia, SVG, Windows/Linux/MacOSX...
[^] # Re: Le futur
Posté par tanguy_k (site web personnel) . En réponse au journal E17, ça avance. Évalué à 4.
"juste" ? mais c'est énorme comme avantage !
L'intérêt de Qt c'est à terme un paquet de logiciels. Par exemple KDE4 est en train d'être porté sur Maemo.
EFL c'est peut être super cool, super beau ect... mais malheureusement ca risque de rester anecdotique comme librairie, trop lié a un WM + écrasé entre GLib/GTK+ et Qt.
tu peux a mon avis faire des choses nettement plus joli et anime avec les EFL que tu ne peux le faire avec QTopia
J'aimerais bien voir un truc fait avec EFL qui ne soit pas faisable avec Qt...
[^] # Re: OpenWengo
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Ekiga 3.00 disponible !. Évalué à 2.
Pourtant ca l'est cf mon commentaire juste en dessous.
La meilleure facon de voir si un projet est mort ou pas est de matter les logs SVN : http://dev.openwengo.org/trac/openwengo/trac.fcgi/browser pas de commits depuis plus de 10 mois (date a laquelle Wengo a licencie tout le monde). Maintenant le repo se trouve chez MBDSYS : http://hg.qutecom.org/ et la le log est beaucoup plus parlant :)
# widgets transparents
Posté par tanguy_k (site web personnel) . En réponse au journal Sortie de Qt-4.4.2 + des infos sur Qt-4.5. Évalué à 2.
Donc encore plus de bling bling, je crois que notre pote Sarko va etre content :p
[^] # Re: OpenWengo
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Ekiga 3.00 disponible !. Évalué à 4.
MBDSYS qui a repris le bébé a beaucoup mois de ressources que Wengo pour continuer le développement. A l'époque de Wengo, on était 7 personnes environ sur le logiciel.
D'ailleurs aucun des anciens dev (moi le premier) n'a codé à ma connaissance sur QuteCom donc c'est encore plus tendu pour MBDSYS d'avancer. Pour ma part, un ras le bol, l'envie de faire d'autres trucs... Je suis toujours la mailing-list de loin...
[^] # Re: Choix
Posté par tanguy_k (site web personnel) . En réponse au journal Sortie de Qt-4.4.2 + des infos sur Qt-4.5. Évalué à 7.
Ma propre expérience + celle de pas mal d'autres dev.
> la plupart des applis gui en C qui marche très bien il y en a un paquet
Et ben dit toi que si ces applis avaient été développé en Python par exemple, et ben les développeurs auraient été plus vite ou/et auraient ajouté plus de fonctionnalités.
C'est comme ça, j'invente rien, n'importe quel dev qui a fait du C et du Python te dira que l'on développe plus vite en Python.
Il est par exemple aussi communément admis que l'on développe 2x plus vite en Java qu'en C++ (source : Bruce Eckel).
Ca veut pas dire que le C est un mauvais langage ou que les applis codées avec sont mauvaises, ça veut simplement dire que dans pas mal de cas (de plus en plus avec le temps), il est tout simplement inadapté.
Tout comme un jour C++, Java, C#... seront surement replacés par des langages plus performants.
Libre après aux gens d'utiliser des langages moins adaptés, je vais pas aller les bruler hein ! j'ai longtemps développé en C mais je suis pas marié avec un langage en particulier : j'utilise celui qui semble être le plus adapté pour ce que je veux faire ./
[^] # Re: Choix
Posté par tanguy_k (site web personnel) . En réponse au journal Sortie de Qt-4.4.2 + des infos sur Qt-4.5. Évalué à 2.
De toute façon l'intérêt est franchement pas évident vu que GTK+ / C existe.
[^] # Re: Choix
Posté par tanguy_k (site web personnel) . En réponse au journal Sortie de Qt-4.4.2 + des infos sur Qt-4.5. Évalué à 2.
Ma phrase signifiait pas que "c'est vieux donc c'est nul" mais qu'il y a eu des avancés importante entre le langage C et les langages dit modernes tout comme entre la Ford T et la dernière Renault.
D'un autre coté je me sers tous les jours de la vaisselle de ma grand mère, on a pas encore fait mieux, et pourtant dieu sait que ça date !
[^] # Re: Choix
Posté par tanguy_k (site web personnel) . En réponse au journal Sortie de Qt-4.4.2 + des infos sur Qt-4.5. Évalué à 9.
AMHA Il n'y aura jamais de binding C pour Qt. Mapper Qt qui utilise intensivement le modèle objet par un système procédurale serait à mon avis beaucoup trop compliqué et donnerait un truc bancale.
Laissons le langage C pour le noyau, les drivers ect...
Pour les interfaces graphiques, des langages comme C++, Python, Java, C#, Ruby ect... sont infiniment plus adaptés. Ca tombe bien, il y a des bindings Qt pour ces langages.
Les bindings Python (PyQt) et Java (Qt Jambi) sont considérés comme stables et sont régulièrement utilisés par des applications, en revanche les bindings C# et Ruby ne sont pas encore vraiment utilisés et doivent être surement encore trop jeune.
Pour moi (je vais me faire moinser, tant pis), le fait que le projet GNOME souhaite à tout prix utiliser le langage C est une hérésie. Et Miguel de Icaza a du bien s'en rendre compte, d'où la création de Mono.
Bref pour les interfaces graphiques, il est temps d'abandonner le C qui date d'il y a 40 ans pour un truc plus moderne comme Python, le résultat n'en sera que meilleur.
Pour le web ca fait longtemps que l'on ne fait plus de CGI en C alors admettons que le C est aussi dépassé pour la création d'interfaces graphiques.
# Troll
Posté par tanguy_k (site web personnel) . En réponse au journal Sortie de Qt-4.4.2 + des infos sur Qt-4.5. Évalué à 2.
merde le troll prend pas :/
[^] # Re: Ridicule
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie du codeur vidéo Dirac en version 1.0.0. Évalué à 2.
http://www.babsoncapitaleurope.com/Personnel/Default.aspx
David Hirschmann
Director
David joined in May 2002 from UBS Warburg where he worked in the Investment Banking division focusing on financial sponsors coverage. Prior to joining UBS Warburg, David spent fifteen months at ABN Amro in Paris as a Credit Analyst working on structured and leveraged finance deals. David holds an Economic and Finance Degree from HEC, a French premier business school.
[^] # Re: Parce que vendredi approche...
Posté par tanguy_k (site web personnel) . En réponse au journal Mozilla et Linux. Évalué à 2.
L'ennemi de mon ennemi est mon ami :p
[^] # Re: Installation sous Ubuntu Hardy
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de VLC Media Player 0.9.2. Évalué à 2.
Si clairement, c'est hyper pénible de devoir recompiler un soft. C'était marrant y'a 10 ans quand Linux commençait a être connu, mais 10 ans plus tard le souhait serait d'avoir un OS "userfriendly" qui pourrait avoir une vrai visibilité et pas seulement 1% de PDM.
(ouai parceque c'est qd même un peu le but, genre avoir 10% de PDM et répandre la philosophie du libre + que les constructeurs, webmasters, éditeurs ne nous ignorent plus).
Mildred a soulevé un problème à mon avis important (un frein - parmi d'autres - à l'adoption de Linux) :
il n'y a aucun moyen d'installer la dernière version d'un logiciel facilement (sans recompiler je veux dire)
On ne pourra pas empêcher les gens de vouloir les dernières versions des logiciels. Ce n'est pas possible. A mon avis, ce serait bien de commencer à réfléchir à une manière de résoudre ce problème.
Recompiler un soft n'est pas une alternative viable à ce problème : c'est un truc de geek et restera un truc de geek.
Nous somme ici des passionnés d'informatique et nous passons des heures à bidouiller nos linuxette. Il faut prendre du recul par rapport à ça et se rendre compte que pour un utilisateur normal c'est ridicule de lire un wiki + faire un ./configure juste pour installer le dernier soft.
De même l'utilisateur normal te sortira un gros "mais c'est tout pourri ton truc" s'il ne peut pas tester facilement le dernier truc qui vient de sortir.
[^] # Re: Installation sous Ubuntu Hardy
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de VLC Media Player 0.9.2. Évalué à 2.
J'appelle ça de la branlette intellectuelle.
LFS et recompiler le kernel 2.0.36 c'était à la mode y'a 10 ans.
[^] # Re: wiki down .. troll survives
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de VLC Media Player 0.9.2. Évalué à 9.
cf http://www.redhatmagazine.com/2008/05/08/abiword-team-interv(...)
We use the native toolkit on every platform. That means GTK+ on unix-like platforms. Cocoa on OSX [...] and the Windows API and GDI on Windows platforms. [...] one really annoying thing we have to deal with is having 3 separate graphics classes (render engines)–we really want to get rid of that.
GTK+ c'est moche sous Windows, sous MacOS c'est ignoble.
GTK+ est tres tres mauvais niveau mutliplateforme, faut vraiment etre de mauvaise fois ou aveugle pour soutenir le contraire (surtout comparé à Qt)
[^] # Re: Installation sous Ubuntu Hardy
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de VLC Media Player 0.9.2. Évalué à 5.
Super, et on est en 2008... ça fait peur...
Compiler un soft c'est peut être pas compliqué, mais c'est ultra chiant et inutile, ça prend du temps pour rien.
- Il faut toutes les dépendances en paquet -devel (paye ton espace disque et ta bande passante)
- Faut récupérer le source du soft
- Lire la doc est souvent indispensable car il y a régulièrement des astuces ou autres
- Attendre que ca compile et si ca foire (ca arrive souvent cf tous les messages sur les forums), repartir à l'étape d'avant
- En plus ca pete légèrement le système de package et ca peut provoquer des conflits
Compiler VLC sur une distrib toute neuve ca doit bien prendre 2-3h, super, que du bonheur ! (1)
Il existe des gens sur terre qui ont autre chose a faire que passer leur temps a lire des wiki et recompiler des softs, genre mouler par exemple :p
Le problème soulevé par Mildred fait surement partie des problèmes qui font que Linux ne passera jamais les 5% de part de marché (2).
Déjà s'il n'y avait pas 350 distributions différentes (3) et surtout 15 systèmes de paquet différents ca aiderait grave.
(1) devoir à la maison : recompiler Firefox
(2) http://www.xitimonitor.com/fr-fr/equipement-internaute/syste(...)
0.98% de part de marché en avril, LOL
(3) http://distrowatch.com/stats.php?section=popularity
[^] # Re: EeePC et developpement
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de Videoporama version 0.6. Évalué à 2.
http://linuxfr.org/forums/12/25841.html
J'imagine que pour le EeePC 701, la résolution doit etre un trop petite. Sur un 900 (8.9") c'est du 1024×600, pareil pour le MSI Wind (10").
# EeePC et developpement
Posté par tanguy_k (site web personnel) . En réponse à la dépêche Sortie de Videoporama version 0.6. Évalué à 2.
C'est intéressant ça !
Peux tu nous indiquer les avantages et surtout les inconvénients d'utiliser un netbook pour du développement ?
La résolution réduite de l'écran c'est pas pénible pour éditer du texte ? le clavier n'est il pas inadapté ? souffre t-on d'un manque de puissance ? ect...
Ton expérience avec ce type de machine pourrait surement intéresser d'autres développeurs...
# Hulu
Posté par tanguy_k (site web personnel) . En réponse au journal Débat applications webs vs applications standards, bientot Deezer sur IPod/IPhone ?. Évalué à -2.
c'est un youtube specialise dans les films et series, malheureusement seulement accessible aux US.
http://www.hulu.com/
http://en.wikipedia.org/wiki/Hulu