On est vendredi et les devs de OpenShot ont pensé à nous.
http://www.openshotvideo.com/2013/04/development-update-schedule-and-funds.html
En effet, le projet va migrer de Gtk+ vers Qt5.
Les arguments des développeurs sont:
- Les performances
- Un code plus simple
- Un meilleur support des différentes plateformes
- De vrais outils pour coder
- Meilleure API
- Meilleurs outils de debug
Voilà, en même temps, la vrai question, c'est quand est ce que GNOME passe à Qt ?
# Trollons
Posté par cedric . Évalué à 10.
Chouette, c'est vendredi et vendredi, c'est troll !
Bon, troller sur le dos d'un cadavre qui n'a meme plus la force de se moderniser, c'est pas tres sympa. Mais on est vendredi, et c'est permi. GTK n'evolue plus. Ils n'ont pas compris l'interet du scenegraph, sont de plus en plus lie a la plateforme GNOME pour etre utilisable et il se retrouve a juste ajouter des nouveaux widgets alors que c'est toute l'infrastructure qu'il faudrait revoir.
A l'oppose Qt depuis la separation de Nokia se porte nettement mieux, evolue dans une direction clair (meme si l'abandon du backend software de qtquick dans la 5.0 est a mon avis une erreur) et a un nombre important de developpeur actif sur leur technologie. Ils sont portable et donne de l'importance a la portabilite de leur plateforme. Il n'y a pas de concurrence possible entre Qt et GTK.
La seule chose qui est domage avec Qt, c'est que KDE utilise vraiment trop de resource et ca donne une mauvaise image de leur techno… Et voila, un petit troll discret pour etre sur que l'on ne va pas en rester la.
[^] # Re: Trollons
Posté par manatlan (site web personnel) . Évalué à 10.
De toutes façons, à moyen/long terme … il n'y aura plus ni Qt, ni Gtk ;-)
Tout sera en html5 ;-)
[^] # Re: Trollons
Posté par cedric . Évalué à 9.
La, tu vas trop vite dans le troll. Mais j'ai un contre !
L'erreur fondamental de HTML5, c'est que chacun y vas de son implementation et de sa version. Ca cree une fragmentation titanesque de la plateforme. Plus le temps passe et plus le cout de cette complexite se faira sentir. C'est pas comme si on n'avait pas deja eu le probleme dans le passe. Pour les vieux, les navigateurs WAP avec leur adaptateur de contenu ou le Java MIDP avait eu ce probleme.
Hors aujourd'hui, on voit bien la reussite du modele GNU/Linux, avec une implementation unique, il suffit de cross compiler pour une architecture et tu as le resultat identique partout. De plus le natif offre des avantages de performances non negligeable, sauf a vouloir vivre absolument deux ans dans le passe, parce que c'etait mieux avant.
Donc la logique veut qu'a terme un noyau graphique unique et portable emerge. Qt est bien parti pour dans le domaine. Il y aura forcement quelques solutions concurrentes qui seront a Qt, ce que les BSD sont a GNU/Linux. Mais au final, le natif reprendra sa place apres les incartades de l'HTML5.
[^] # Re: Trollons
Posté par manatlan (site web personnel) . Évalué à 3.
Je blaguais un peu dans mon précédent commentaire.
Certes je poussais le troll un poil plus loin.
Mais, sincèrement, le desktop a base de technos html5/js, j'y crois dur comme fer.
On y vient petit à petit quand même. Le javascript est en train de s'imposer dans les desktops. Et les initiatives à la "chrome os" ou firefox os" fleurissent.
Sur mobile également, la tendance au html5 se confirme. Avec des apis comme le offline, canvas, les guis, websockets, et l'accès aux spécificités natives (qui sont en train de se faire normaliser) : Il ne restera plus grand choses aux applis natives.
Certes, openshot en html5, c'est pas pour tout de suite …
Mais ça reste du domaine du possible ! cf les effets http://webcamtoy.com/fr/
[^] # Re: Trollons
Posté par gnumdk (site web personnel) . Évalué à 8.
Non, c'est l'inverse, sur le mobile, tout le monde a abandonné le html5 pour du natif… Il n'y que Mozilla sur ce créneau…
[^] # Re: Trollons
Posté par cedric . Évalué à 4.
Et les operateurs qui croient toujours dans les standards en commite…
Quand a mozilla, ils n'ont pas trop le choix, ils n'ont aucune existence dans le mobile et si ca continu, ils seront irrelevant. C'est juste une question de survie.
[^] # Re: Trollons
Posté par dave_null (site web personnel) . Évalué à 1.
Pour ceux qui veulent du court terme. J'attends de voir ce qu'ils en pensent de leurs applications en Objectiv-C dégueulasse dans 10 ans.
[^] # Re: Trollons
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
L'objective-C, je connais pas, mais tu prends une appli Qt4 de 2005, tu peux quasiment la recompiler telle quelle sans trop changer quoique ce soit.
[^] # Re: Trollons
Posté par dave_null (site web personnel) . Évalué à 0.
Du moment que tu ne veux pas t'en servir sur ce qui se vend le plus actuellement, c'est pas mal.
[^] # Re: Trollons
Posté par groumly . Évalué à 2.
Moi j'aurais tendance a vouloir m'en servir sur les peripheriques qui servent le plus actuellement. A savoir, pas ceux auquels tu pense.
Que samsung vende tout plein de telephone, c'est tres bien pour eux. Mais moi, je regarde les stats d'utilisation dans le vrai monde, et les chiffres sont sans appel.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par gnumdk (site web personnel) . Évalué à 3.
Euh, je vois pas en quoi une appli web devrait être plus propre qu'une appli native…
T'as une théorie la dessus ?
[^] # Re: Trollons
Posté par cedric . Évalué à 10.
Surement le fait d'avoir 15 milles layer d'abstraction et de code dependant de la version du navigateur sans oublier de prendre en compte l'alignement des planetes. Il faut beaucoup d'imagination pour imaginer une techno plus propre, plus stable et plus perenne dans le temps… ou pas !
[^] # Re: Trollons
Posté par napster2core . Évalué à 3.
Vu le nombre de noob et autre qui voudrons faire leur app delamortquitue en 10 secondes codée avec les pieds, je vois un sérieux problème qui se profil à l'horizon.
Si tu ne sais pas demande, si tu sais partage !
[^] # Re: Trollons
Posté par groumly . Évalué à 0.
Qu'est ce que l'objc a de degueulasse?
Apple a un peu foutu la zone recemment, et encore, le vieux code compile toujours pareil, j'en ai entendu qui avait du code vieux de 15 qui compilait toujours tres bien.
Le js avec un nouveau framework qui dechire tout tous les 6 mois par contre…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par claudex . Évalué à 0.
Le JS qui a 15 ans compile toujours aussi.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Trollons
Posté par groumly . Évalué à 5.
Sur. le probleme c'est la maintenance de tes dependences une fois que toute la communaute a bouge vers le nouveau framework qui dechire sa race.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par dave_null (site web personnel) . Évalué à 1.
La syntaxe, l'environnement, le fait que si l'on veut faire du Cocoa décent (plus avancé que sur NextStep) il faille acheter un mac ?
Mais globalement, c'est surtout que c'est un langage bien trop bas niveau par rapport à ce dont t'il sert généralement (faire des IHM).
[^] # Re: Trollons
Posté par groumly . Évalué à 2.
C'est quoi le probleme de la syntaxe?
Pour 99% c'est du c, le pourcent restant c'est du message send avec des params nommes plutot elegant…
Tu lui reproches quoi a l'environnement? Xcode est plus que decent ces derniers temps, instruments est redoutablement efficace, interface builder de tres haut vol. et t'as la palanquee d'outil unix standard par dessus tout ca.
T'as pas du ecrire beaucoup de cocoa toi pour dire une anerie pareille. C'est pas du ruby, c'est clair, mais pour l'essentiel, c'est pas pire que du java, et a des annees lumieres du c++.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par dave_null (site web personnel) . Évalué à 1.
Le problème de la syntaxe ? C'est à 99% du C et le pourcentage restant et un ensemble assez étrange avec des hacks sur les tableaux, des arobases qui traînent, des + et des - très lisibles, etc… Après il y a pire, comme le C++, mais je préfère des syntaxes différentes comme le Python, le Ruby et même le JavaScript.
Je reproche à l'environnement d'être propriétaire, fermé et de fonctionner uniquement sur mac. Par contre il est efficace et je trouve qu'il est plus agréable à utiliser que eclipse pour android.
«C'est pas pire que du Java» résume assez bien ce que je pense de l'objective C pour faire de l'IHM.
Après je ne fais que constater selon mes connaissances, j'ai eu des TDs de base sur Cocoa donc je n'ai pas l'expérience dessus, mais de mon point de vue c'est un mode de développement assez rétro et bien différent de ce qui se fait dans le monde du web, avec des projets comme AngularJS par exemple (qui a une utilisation de javascript pas très heureuse malheureusement, parce que trop «magique»).
[^] # Re: Trollons
Posté par tanguy_k (site web personnel) . Évalué à 1.
Qu'appelles tu trop magique ? (je fais du AngularJS)
(Je sais c'est HS mais bon…)
[^] # Re: Trollons
Posté par dave_null (site web personnel) . Évalué à 1.
L'utilisation du nom des paramètres pour l'injection des dépendances par défaut, c'est de la magie pour moi (voir http://docs.angularjs.org/guide/di).
Après c'est aussi l'utilisation de nombreuses fonctions anonymes. Tout reste logique, mais la syntaxe peut être assez complexe.
Quand on fait une connerie, il n'est pas rare de se trouver devant une page blanche avec éventuellement un message d'erreur compréhensible dans la console. Mais sinon j'adore AngularJS et c'est ma nouvelle passion.
[^] # Re: Trollons
Posté par tanguy_k (site web personnel) . Évalué à 1.
C'est juste le pattern Dependency Injection / Inversion of Control, c'est simple et propre. Par contre la minification casse les couil*** et complexifie la syntaxe inutilement.
Pour moi le plus complexe c'est les directives avec les $apply, $digest, le principe de la compilation et du linkage ect…
Je comprends pas bien non plus les differences entre service, factory…
Et la doc n'est pas encore top, mais ils vont s'en occuper : https://plus.google.com/+AngularJS/posts/LXbG929Lbnr
idem
[^] # Re: Trollons
Posté par groumly . Évalué à 1.
Donc en fait, il est tres bien, l'environnement, mais tu l'aimes pas pour des questions de gout?
T'es au courant que clang est 100% open source, tout comme tous les autres outils sinon?
Je parlais du cote bas niveau la. Le langage est a des annees lumieres de ce que propose java, notamment grace au fait que nil est safe, les categories et bien evidemment les blocks.
Aaah, on y arrive, tu connais pas la technologie, t'as fait un hello world, suivi d'un hello world 2.0 avec une UITableView et 2 cells differentes (sans utiliser de nibs, evidemment, l'IoC c'est trop demander), mais tu pense que?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par dave_null (site web personnel) . Évalué à 4.
Cocoa opensource ? IOS opensource ? Mac os X opensource ? XCode opensource ?
Tu gères des pointeurs, les chaînes de caractères doivent commencer par un @ parce que sinon c'est juste un char *, tu te tapes encore ces .h, pour moi c'est quand même pas un langage super haut niveau. Alors peut-être que tu le préfères par rapport à Java, mais il ne faut pas oublier que dans Objective-C, il y a C. (bon, il y a aussi C dans C#, mais tu ne peux pas coder en C dans du C#).
Pour mes connaissances, effectivement je ne suis pas allé bien plus loin que ce que tu cites, même si j'ai utilisé des nibs et compagnie, mais ça tombe bien je n'avais pas besoin d'aller plus loin. C'était dans le cadre d'un module de découverte, et j'ai eu une introduction à PhoneGap, HTML5 de base, Android, iOS, Microsoft Pixel Sense et même XUL pour le fun. Je devais ensuite choisir la technologie à utiliser pour un projet.
Je n'ai donc pas choisi le développement IOS en Objective-C pour plusieurs raisons : obligé d'avoir un mac (que l'on me fournissait pourtant), c'est moche, j'aime pas, c'est vraiment très moche, sapucestpaslibre, j'aime pas.
Par contre des gens de mon groupe de TD ont choisi iOS, ce qui a permis de profiter de leur expérience. Je ne regrette pas mon choix.
[^] # Re: Trollons
Posté par groumly . Évalué à 1.
Ceux la, non. Ton compilo il est libre. ld est libre. 95% de ce qui vient avec les devs tools sont libres. Tu veux pas utiliser xcode? tres bien, utilise emacs et des makefile si ca te chante.
Comme dans tous les langages, a commencer par java… Tu crois que ca veut dire quoi le P de NPE?
Le probleme de C/C++ c'est de melanger valeur et pointeurs allègrement, la partie Objective de C ne te laisse pas faire *pointeur.field = @"something".
Objc gere ce probleme exactement de la meme facon que les autres langages de haut niveau: t'as des pointeurs et pis c'est tout.
Le cas ou t'as des struct, t'es dans le monde du C, et c'est plutot rare (meme GCD est en passe de se faire objectifier, avec support d'arc et tout le tralala).
tu preferes l'approche C++ ou c'est un bordel sans nom?
La pour le coup, je ne peux qu'abonder dans ton sens.
Ouais, enfin sorti de manipuler des CGRect/CGPoint/CGSize et qq appels a CoreGraphics, le C d'objective C, en pratique, tu le vois pas beaucoup. Par contre t'as un langage qui met sa tannee a Java/C++ sur les temps de demarrage (critique dans le monde mobile) et qui a des performances tres honorables considerant le haut niveau qu'il procure.
En gros, ce langage, c'est ce que C++ aurait du etre.
Ok, donc t'as pas choisi iOS pour des raisons a la cons.
Note, ya pas de mal, hein, ya suffisament de techno pour pouvoir dire "je veux pas faire de machin parce que, et pis c'est tout" et pas avoir a s'en justifier.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par flagos . Évalué à 4.
Et windows aussi il me semble.
[^] # Re: Trollons
Posté par barmic . Évalué à 4.
Et tizen je crois.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trollons
Posté par cedric . Évalué à 4.
Uniquement pour les 3rd party, aucune application du systeme ne l'utilise et vu la difference de performance, ce n'est pas pret d'arriver. Mais bon, c'est le buzzword du moment et comme de toute facon, tout le monde doit faire par defaut du HTML5, ils annoncent. Ca fait toujours plaisir au marketing.
[^] # Re: Trollons
Posté par tanguy_k (site web personnel) . Évalué à 1.
C'est tout a fait faux, la plupart des projets s'orientent vers HTML5 grace a Titanium et surtout PhoneGap.
L'idee : une application native qui embarque un composant type web view + le "vrai" code en HTML5.
Les entreprises ne veulent pas developper plusieurs fois la meme application : Objective-C (iOS), Java (Android), C# (WP), Qt (BlackBerry, Ubuntu mobile)…
Tout le monde veut un truc commun et standard => HTML/CSS/JS
L'exception qui confirme la regle c'est le retournement de Facebook vis a vis de HTML5 cf 1 2
Et l'arrive de Qt sur Android et iOS arrive trop tard et ne changera rien. Pour avoir fait du PhoneGap/HTML5, c'est AMHA encore jeune donc les entreprises qui ont les moyens font du natif, mais c'est clairement l'avenir.
[^] # Re: Trollons
Posté par groumly . Évalué à 3.
Le pire des deux mondes:
- un merdier a deployer, avec des utilisateurs qui updatent jamais
- des performances moisies avec une mauvaise UX et une utilisation cpu/ram indecente pour ce que ca fait
- pas d'acces a des truc de base (le spinner notamment), donc tu te retrouves a (mal) reinventer des composants pourtant standards.
Pas vraiment non, vu le marche de l'emploi pour developeur ios natif, c'est pas la tendance, du tout.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par tanguy_k (site web personnel) . Évalué à 1.
Avec PhoneGap pour Android, tu obtiens un .apk standard compile avec les outils fournit par Google : Android Developer Tools/Eclipse.
Pareil sous WP : compilation avec Visual Studio.
Si deployer une appli hybride est le merdier, alors deployer une appli native est tout autant le merdier.
Oui c'est vrai.
C'est le but : etre independant de la plateforme.
Qt, Java Swing et GTK+ suivent le meme principe. Un QPushButton n'est pas cree en utilisant le widget bouton de Windows mais a l'aide de primitives graphiques (point, droite, courbe…). C'est d'ailleurs une bien meilleure approche que wxWidgets, Java AWT et SWT qui eux s'appuient sur les widgets de la plateforme cible.
Pour autant, Qt, Swing et GTK+ ont un systeme de styling qui permet de reproduire (plus ou moins) fidelement les widgets de la plateforme visee.
Rien n'empeche d'utiliser jQuery Mobile, Bootstrap Twitter, un autre truc et de creer un style qui reproduise celui de iOS, Android ou WP.
Le natif aura evidemment toujours bonne allure.
Je ne me fais pas de soucis pour les dev iOS mais en ce qui concerne la tendance AHMA tu te mets le doigt dans l'oeil.
[^] # Re: Trollons
Posté par groumly . Évalué à 2.
C'est precisement mon point. Le deployment des applis natives est un enorme probleme. On a beau avoir de l'automation dans tous les sens et passer qq jours a tester l'appli, j'ai toujours une grosse boule dans le ventre quand je clique sur le bouton "make this app ready for sale", et les 24 heures qui suivent me voient checker la page d'analytics frenetiquement pour detecter le moindre probleme.
T'as une tres bonne experience utilisateur, mais t'as des contraintes de deployment et de support tres forte.
Avec les web pur, t'as une moins bonne experience utilsiateur, mais tu peux avancer beaucoup plus vite et un bug est vachement moins genant tu fais un roll back et pis c'est marre.
Les applis hybrides te donnent le pire des deux mondes: faut toujours faire des mises a jour et les deployer sur chaque telephone, et par dessus le marche tu te tapes une UX pourrie et des perfs miserables.
La plupart des applis phonegap sur le store se tapent des notes pourries, et les quelques application vraiment high profile appreciees sont toutes natives. La seule exception etait facebook (et ils se tapaient 2 etoiles sur le store avant leur rewrite natif).
Et ca cree une mauvaise experience utilisateur. Ca se comporte differement, et l'utilisateur est pas content et frustre parce que ca marche pas comme il s'y attend.
Si, le bon sens. C'est une connerie sans nom. Les utilisateurs n'ont aucun probleme avec le look du web. Par contre quand tu singe le look natif d'iOS, l'utilisateur veut de la performance native. Reactivite et pas attendre 3 seconds que l'ecran commence a se charger. Si tu fais du web, fait du web, dans un browser, ne t'amuses pas a singer le look natif parce que tu vas te prendre une claque.
Hahaha. merci pour la barre de rire. Clair qu'un graphe google trend est revelateur de la qualite et le succes de ce qui se trouve sur le store!
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par tanguy_k (site web personnel) . Évalué à 1.
Tu parles de performance et d'experience utilisateur. On est d'accord depuis le debut, le natif c'est mieux (le "Oui c'est vrai" n'etait pas suffisamment claire ?)
Moi je reponds a ton premier commentaire "sur le mobile, tout le monde a abandonné le html5 pour du natif".
Le graphe Google trends te parait peut etre ridicule, mais force est de constater que ca buzz autour de HTML5 sur le mobile => c'est donc loin d'etre abandonne.
HTML5 propose une experience utilisateur moins bonne et pourtant ca interesse de plus en plus les editeurs/developpeurs.
L'experience utilisateur n'est pas le seul critere, le cout de developpement en est un autre. Les entreprises n'ont souvent pas les moyens de redevelopper une appli pour iOS, WP, Android, BB et peut etre bientot FirefoxOS, Ubuntu, Tizen, Jolla.
Laisse le temps a tout ca de progresser (perf des smartphones, perf des moteurs HTML/JS, amelioration des librairies) et on en reparle dans 2-3 ans.
[^] # Re: Trollons
Posté par fredix . Évalué à 3.
Merci tu viens d'admettre que HTML5 ne marchera jamais sur les smartphones :) :)
Bin oui que tu le veuilles ou non c'est l'utilisateur qui décide ce qui fait le succès d'une app. Et si son expérience est moins bonne en HTML5 parce que tu veux faire des économies, tu es mort.
Oui on en reparle dans 2-3 ans, d'ici là je compte bien à ce qu'Ubuntu phone ait pu gratter des parts de marché avec des apps en Qt … :)
[^] # Re: Trollons
Posté par groumly . Évalué à 2.
Desole, mais non. Je traine ma bille dans ce domaine depuis qq temps deja. Personne de serieux par chez moi vient en disant "on va faire un truc de ouf en html5". Les derniers a avoir fait ca, c'etait linkedin, et ca a ete un desastre.
Ceux qui se lancent dans le html5, c'est des boites avec un departement ingenierie faible, ou un departement produit a la papa qui s'interesse plus a des stats bidons qu'a la reelle performance de leur produit.
Ca tombe bien, a moins d'etre un geant, t'as pas besoin d'autre chose que d'ios.
Android est en pratique peu utilise, et par des utilisateurs cheap (je l'invente pas, tous les chiffres de traffic que j'ai vu donne android loin derriere ios en terme de traffic reel), ms paye en ce moment pour le dev des applis, et a de toutes facons un traffic risible.
Le reste, c'est tellement anecdotique que les supporter est equivalent a supporter un development custom pour uzbl sur haiku.
Ouvres les yeux bordel. Regardez les chiffres de traffic reel plutot que de vous interesser uniquement aux chiffres de vente.
Prends les petites startup qui debarquent avec des applis nouvelles et des nouveaux concepts. Combien developpent pour ios d'abord, et se soucient du reste apres? Combien d'appli dans le top 100 sur le store sont en html5?
Le html5, c'est tres bien. Mais c'est a proscrire pour des applis. Tu fais un site mobile avec moulte html5, et c'est parfait, tout le monde sera content.
Et tu crois qu'ils seront ou apple et google avec leur sdk dans 2-3 ans? Au meme point que meme temps ou qu'ils auront progresse?
Et tu te rends compte que 2-3 ans dans ce domaine, c'est eternite?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par fredix . Évalué à 9.
C'est triste ton avis sur le desktop.
[^] # Re: Trollons
Posté par groumly . Évalué à 10.
Chromeos fait un four, firefoxos va suivre le meme chemin. Si meme MS n'arrive pas a rentrer sur le marche avec tous leur fric et leur force de frappe, je doute que mozilla puisse y rentrer.
Le marche est verouille a l'heure actuelle, au moins pour les 2-3 annees a venir, et probablement plus. La situation est similaire au desktop au milieu des annees 90 avec deux grands os qui se tirent la bourre. Ya des alternatives, mais elles restent tres largement minoritaires.
Ouais, alors ce que j'en vois moi, c'est que le html5 sur mobile marche pas terrible, la faute a des performances plutot bof et a un manque d'acces au api natives.
Les toolkits hybrides produisent des applis ni faites ni a faire: les emmerde de deployment du natif et les mauvaise perfs et experience du web. Les applis ecrites avec sont le plus souvent mal notees par les utilisateur qui ne les aiment pas du tout.
Quand meme facebook declare que le html5 pour les applis mobiles ca marche pas, faudrait se poser des questions. C'est pas des branques en la matiere, et si ya bien quelqu'un qui a etre emmerde par des gens qui updatent pas les applis, c'est bien eux, vu la vitesse a laquelle ils bougent sur le web.
Sinon, j'ai envie de dire: oh, oui, ajoutons des threads, un acces direct au FS, l'acces a la carte son, graphique et les peripheriques d'entree. Et l'acces au window manager aussi.
Et ensuite, comme ca sera toujours trop lent, on commencera a compiler. Et pis apres, on ecrira un framework, compile lui aussi, installe de base sur les machines, et on pourra linker contre ca et diminuer la taille des binaires.
Yen a qui se rendent compte qu'ils sont en train de reinventer le desktop natif?
Qu'on ne se meprenne pas, le html5 est tres bien, tres utile et a fait un joli bond en avant. Mais considerer qu'il va remplacer le natif c'est aussi idiot que de considerer que le natif va remplacer le web.
Les deux sont complementaires, on a besoin des deux, et on s'en sert dans differents cas.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par fredix . Évalué à 5.
Il y a des encore des gens censés ici ! je les croyais tous parti… Bin oué ils réinvente le natif, et ils en sont fier. Enfin heureusement il y a jolla mobile et Ubuntu phone et je veux bien parier sur un des 2 pour grappiller des parts de marché en quelques années. La grosse force de Canonical est d'avoir un OS desktop et serveur ce qui peut leur permettre de proposer un écosystème cohérent et unifié sur de multiples devices, ça rappelle une certaine pomme mais avec une forte dose de libre.
[^] # Re: Trollons
Posté par groumly . Évalué à -2.
Gne?
Qu'est ce que l'unification et la coherence d'OS qui n'ont strictement rien a voir apporte?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par fredix . Évalué à 1.
La cohérence apporte un look and feel identique sur desktop/tablette/smartphone/TV et l'unification via le cloud ubuntu One pour la synchro des prefs et des datas utilisateurs.
[^] # Re: Trollons
Posté par Frank-N-Furter . Évalué à 6.
Le Microsoft du début des années 2000 vient d’appeler et voudrait que tu viennes bosser sur sa super plateforme pleine d’avenir, Windows Mobile.
Ce que les gens veulent, c’est avoir accès facilement a leurs documents sur n’importe quel appareil, après ils sont capables de comprendre qu’un appareil avec une surface d’affichage/contrôle de 4’ ne s’utilise pas de la même manière qu’un appareil avec un écran de 21’, un clavier et une souris.
Depending on the time of day, the French go either way.
[^] # Re: Trollons
Posté par fredix . Évalué à 1.
Tu auras sans doute remarqué que l'interface Metro de windows 8 ressemble fortement à l'interface à tuile de Windows phone…
Idem Ubuntu phone propose la barre unity à gauche comme sur le desktop. Sans parler des couleurs et du design qui rappelle l'éditeur respectif sur chacun de leurs devices.
[^] # Re: Trollons
Posté par groumly . Évalué à 2.
Et les utilisateurs apprecient tellement que le prochain SP proposera l'option de desactiver metro…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par gnumdk (site web personnel) . Évalué à 5.
Tu nous feras plaisir de pas lire les news de travers…
Il y aura "peut être" une clé de registre pour démarrer directement sur le bureau, pas pour désactiver métro…
[^] # Re: Trollons
Posté par Frank-N-Furter . Évalué à 1.
Oui, d'essayer de faire entrer des paradigmes Desktop sur des mobiles, ils sont passés a forcer des concepts d'UI mobile sur le desktop, toujours sans tenir compte des spécificités des plateformes. Là où Apple fait ça par petites touches, je te rajoute quelques gestures à chaque itération d'OS X, et une ou deux fonctionnalités inspirées d’iOS. Mais au final ça reste deux environnements distincts.
Mais l’avenir nous dira qui a raison, et tu pourras toujours mettre l’échec d’Ubuntu sur le dos d’Apple en disant qu’ils utilisent de la magie noire pour empêcher les gens de voir la grandeur des produits Ubuntu.
Depending on the time of day, the French go either way.
[^] # Re: Trollons
Posté par xcomcmdr . Évalué à 3.
C'est pas le cas de Ubuntu. Unity sur PC s'utilise bien mieux si on utilise les raccourcis claviers, et le look entre Unity/PC et Unity/smartphone est assez différent et s'adapte aux spécificités des deux.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Trollons
Posté par flan (site web personnel) . Évalué à 1.
Et encore, il y en a en trop…
Le Launchpad (en gros, une grille présentant les applications installées, un peu comme sur Gnome3), par exemple : pour supprimer une application, il faut cliquer longtemps sur l'élément, pour que les éléments gigotent et qu'apparaisse alors une croix de suppression sur laquelle on clique.
Ce comportement est très pratique en tactile, mais inutilisable sur un ordi avec clavier et souris : permettre un raccourci clavier ainsi qu'un clic secondaire avec l'option de suppression aurait été beaucoup plus ergonomique.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Trollons
Posté par FantastIX . Évalué à 2. Dernière modification le 06 mai 2013 à 13:28.
… je suis même pas sûr qu'ils le sachent eux-mêmes!
[^] # Re: Trollons
Posté par Sufflope (site web personnel) . Évalué à 2.
Mais euh c'est quoi le rapport entre cohérence de l'interface et Qt/GTK versus HTML5 ?
[^] # Re: Trollons
Posté par fredix . Évalué à 5.
Aucun, juste que Canonical a un avantage sur Jolla car ils ont aussi un OS desktop.
[^] # Re: Trollons
Posté par Maclag . Évalué à 1.
Je n'ai pas d'avis tranché sur natif vs html5, je n'ai pas les compétences techniques pour ça.
Par contre, dans le factuel, à ça:
j'ai retrouvé ça à répondre:
http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story
Et là je me dis que si Facebook pense que HTML5 c'est pas prêt, c'est qu'ils feraient bien de zieuter ce que font leurs dévs aussi…
[^] # Re: Trollons
Posté par tanguy_k (site web personnel) . Évalué à 6.
L'etude de Sencha est moisie : aucune donnees sur l'occupation CPU, la RAM, le temps de demarrage de l'appli… + le code source n'est pas disponible.
Voici un example de vrai comparaison avec des chiffres pour revenir sur Qt : QML vs EFL
[^] # Re: Trollons
Posté par cedric . Évalué à 2.
Faut pas oublier le lien vers le followup pour une comparaison dans l'embarque :
https://phab.enlightenment.org/phame/live/1/post/simple_efl_vs_qml_comparison_again/
J'aimerais bien faire une comparaison sur la consomation d'energie, mais je n'ai pas d'outil pour faire les mesures. Si quelqu'un a une idee.
[^] # Re: Trollons
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
powertop ? y'a pas des outils autour de Oprofiles qui donne la consommation électrique d'un processus ?
"La première sécurité est la liberté"
[^] # Re: Trollons
Posté par cedric . Évalué à 2.
Le probleme de powertop, c'est qu'il mesure l'activite durant la decharge de la batterie. Si la batterie ne se decharge pas assez vite pour etre mesurer, alors il pense qu'il n'a pas consomme d'energie. En espacant au maximum les points de mesure, cela resoud le probleme… pour l'usage de powertop. Dans le cas d'un benchmark tel que celui-ci, je pense qu'il serait plus pertinent d'avoir une trace de la consomation en temps reel et qu'on puisse lq piloter en simultane de l'execution du benchmark. En gros, je cherche une sonde materiel qui puisse memoriser une trace et se faire piloter via usb.
[^] # Re: Trollons
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
En gros, tu veux un whattmètre usb ? Cela doit exister je pense.
"La première sécurité est la liberté"
[^] # Re: Trollons
Posté par cedric . Évalué à 2.
Si tu me trouves une reference, je suis preneur (de preference, un truc que je peux faire marcher avec du soft libre ;-) )
[^] # Re: Trollons
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Ce truc là ?
http://www.yoctopuce.com/FR/products/capteurs-usb/yocto-watt?gclid=CNWc_5zy8bYCFZIPtAod1kYAMg
J'ai l'impression que le soucis est de trouver un wattmètre qui ne se contente pas de faire une multiplication des tensions RMS et des courants RMS, ce qui ne veut rien dire.
"La première sécurité est la liberté"
[^] # Re: Trollons
Posté par gnumdk (site web personnel) . Évalué à 2.
Non, ils font de la R&D chez Facebook!!! Ça c'est de l'info!
On en reparlera quand l'appli HTML5 aura remplacée la native…
[^] # Re: Trollons
Posté par Sufflope (site web personnel) . Évalué à 3.
Oui alors rien à voir. MS ils peuvent aligner le pognon qu'ils veulent, les kikoolol qui font la mode sur twitbook et pour qui déjà Fx c'est hasbeen par rapport à Chrome, tu crois franchement qu'ils vont s'enthousiasmer pour un bousin où la plateforme de dév. standard c'est Windows + Visual ? Sérieux ? (remarque on peut pas forcément leur donner tort).
Alors qu'au moins FxOS c'est in, c'est HTML5.
Forcément, quand Apple décide lors d'une màj de fournir un webkit volontairement bridé pour les applis HTML5, BIZARREMENT, ça marche moins bien après, çatalors
Bah faut croire que si… (et merci de ne pas ressortir "oui mais on a pas comparé la conso avec l'appli Sencha", on s'en tape, si l'appli FB rame l'utilisateur il s'en fout qu'elle consomme 10Mo de moins, il râle). Remarque quand on choisit PHP comme socle pour son business, faut pas espérer être crédible ensuite.
[^] # Re: Trollons
Posté par fredix . Évalué à 4.
Sauf que le PHP chez Facebook n'a rien à voir avec ce que tu connais puisqu'il est compilé et que l'instance facebook est un binaire.
[^] # Re: Trollons
Posté par groumly . Évalué à 2.
95% des gens qui achetent un smartphone ne savent meme pas ce que plateforme de dev veut dire, va falloir trouver un autre excuse.
MS PAYE les boites en ce moment pour ecrire leurs applis. Ils viennent de nous offrir $100k pour porter notre appli. On sait meme pas si l'appli va nous rapporter ca en un an, ios fait 2 fois ca par semaine…
Bizarrement aussi, on voit pas grand monde faire du html5 offline dans safari, qui a pourtant nitro full patate. Et si c'est pour faire du html5, evite le store, ca t'eviteras qq maux de tete. Je comprends pas le concept d'un appli html5 sur un store. C'st chiant a deployer, faut subir les reviews du store, et tu te tapes des perfs de merde. C'st quoi le concept? Pourquoi ne pas faire une vraie appli html5 a la google gears?
L'utilisateur, il s'en rend pas compte directement. Mais quand son telephone tient 10 sur batteries au lieux de 18, il gueule. Quand ses applis se font killer a droite a gauche parce que js est un porc sur l'occupation memoire, il gueule aussi.
Et quand il se tape des transitons pourries, il est pas content non plus. Que machin fasse une vraie comparaison et qu'il nous sorte les stats de profiling, on en reparle (et on comparera le temps passe sur leur applis html5).
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Marrant, tu n'as pas utilisé les 3 lettres qui commencent par E et finit par L (avec un F au milieu).
"La première sécurité est la liberté"
[^] # Re: Trollons
Posté par saltimbanque (site web personnel) . Évalué à 8.
bah quitte à changer ils pourraient aussi passer à Clutter… mais c'est plutôt l'inverse qui a été retenu, que Clutter devienne utilie à Gtk+ (autrement par que la voie GtkClutter.
Dire que l'infra Gtk+ n'évolue pas, … dans ce cas dites qu'elle n'évolue pas dans le bon sens, ou pas assez si vous voulez, mais en tout cas ça évolue, il ne s'agit vraiment pas que d'ajouter des widgets.
pour chacun de ces sujets, libre à vous de troller, mais alors faites le avec soin! sinon un troll pas propre ça pue.
[^] # Re: Trollons
Posté par cedric . Évalué à 2.
Oui, je me disais que pour ce troll, ce n'etait pas necessaire, mais bon, vendredi n'est pas encore fini ;-)
[^] # Re: Trollons
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Juste au dessus, il parle de cluter. Il y a de quoi faire, non ?
Et sinon niveau doc/IDE, il y a des trucs utilisables par des non-experts pour les EFL ?
"La première sécurité est la liberté"
[^] # Re: Trollons
Posté par cedric . Évalué à 0.
Ah, bah, trolldi est passe. Domage ;-)
[^] # Re: Trollons
Posté par freem . Évalué à -2.
Et comment oublier wxwidgets?
[^] # Re: Trollons
Posté par Nicolas Boulay (site web personnel) . Évalué à 9.
si on peut.
"La première sécurité est la liberté"
[^] # Re: Trollons
Posté par freem . Évalué à 2.
On peut oui, mais wxwidgets semble être bien plus utilisé que les EFL.
Accessoirement, c'est portable.
[^] # Re: Trollons
Posté par cedric . Évalué à 4.
Windows est plus utilise que Linux sur le desktop. Argumentaire de masse toujours imparable.
Et les efls sont certainement plus portable que wxwidgets, a partir du moment ou tu as un framebuffer et un debut de libc, ca passe.
[^] # Re: Trollons
Posté par freem . Évalué à 5.
Désolé de considérer que les applications que je fais doivent pouvoir tourner sur la plus grande quantité possible de cibles.
Je vais même t'aider un peu. D'ailleurs, en tant que personne qui les promeut, sache que tu me déçois énormément de ne pas avoir toi-même cité une partie de ce passage du site officiel:
Mais peut-être est-ce dû aux nombreuses portions de phrase qui donnent une impression de truc pas fini?
Si j'utilise des lib de préférence portable, c'est justement pour ne pas avoir besoin de galérer à vérifier quelle fonctionnalité l'est ou pas, personnellement.
Enfin bon… il y a une façon simple de savoir si les gens préfèrent les EFL à wxWidgets ou le contraire, et c'est de voir des applications célèbres les utilisant. Sans même prendre la peine de réfléchir, wxWidgets a FileFilla.
[^] # Re: Trollons
Posté par small_duck (site web personnel) . Évalué à 3.
Et pgAdmin!
[^] # Re: Trollons
Posté par cedric . Évalué à -1.
J'aurais du faire une quote, parce que bon, la, ton argumentaire, c'etait: "parce que c'est plus utilise, c'est donc un meilleur choix". Maintenant tu en changes la comprehension…
Ca ne change rien a ce que j'ai dis. Les EFL tournent sur plus de materiel que wxWdiget ne pourra jamais le faire. C'est juste un fait. La portabilite des EFL fait que si ta machine n'est pas suffisante pour, alors tu peux oublier tous les autres framework. Apres qu'on ne garantisse pas l'equivalence de fonctionalite, en tant que logiciel libre, c'est un peu normal. C'est le boulot d'une societe de faire la partie QA. En temps que logiciel libre, on fait que ca marche bien pour notre usage et on resoud autant que possible les bugs rapporte par nos utilisateurs. D'ailleur je crois qu'on n'a pas besoin du support X11 pour OS X, elle n'est pas a jour cette page !
C'est marrant, mais je n'ai jamais utilise la moindre application fait avec wxWidgets. Tu m'aurais dis Qt, GTK, meme XUL, j'aurais dis OK, mais wxWidget, c'est vraiment pas le genre d'application que j'utilise. Et pourtant j'ai cherche dans la liste de leur site, mais nop. D'ailleur quand on voit la liste, c'est vraiment de l'institutionnel, pas vraiment un domaine que je croise souvent.
[^] # Re: Trollons
Posté par freem . Évalué à 2.
Le meilleur choix n'est pas toujours le meilleur choix technique (sinon windows serait beaucoup moins utilisé…). Et avoir plus d'utilisation peut permettre d'avoir aussi plus de retours. Je viens de regarder rapidement (10min). Jolie interface d'ailleurs, mais je trouve ça fouilli. Question de goûts, ça.) sur le site des EFL, je n'ai pas trouvé les infos que je chercherais, ou pas aussi vite, si je devais demain écrire une appli from scratch pour mon boulot et que je devais convaincre mon chef (quelqu'un à bien réussi à convaincre un chef de google que ça peut être une bonne idée pour google drive):
pas de screenshot (on parle de toolkit graphiques quand même non?)ah si je l'ai trouvé, en petit. Faut cliquer 3 fois dessus pour arriver à une image de taille correcte par contre.Pour être réellement honnête, je suis tombé sur des incohérence de conception dans l'API de wxwidgets qui m'ont assez pourri la vie (la gestion du menu principal est chiante. Ca va si c'est pour faire un truc en dur, mais quand tu veux générer automatiquement des menus à partir d'un arbre de données… bref) mais de façon générale c'est pas trop lourd à l'exécution (pas un foudre de guerre non plus, clairement) et y'a moyen d'arriver vite fait à ses besoins.
L'avantage selon moi comparé à Qt, c'est l'absence d'outil intermédiaire dans la chaîne de compilation (outil qui m'a empêché de contribuer à un projet utilisant Qt parce que je n'ai jamais réussi à l'intégrer dans mes IDE, qui ne sont pas QtCreator qui n'est pas du tout à mon goût.).
Si tu me dis que les EFL sont portables et légères, tu me parles dans un langage qui me plaît, c'est le genre de trucs que j'aime réellement. D'ailleurs, je veux bien te croire, mais tu dis toi même que la page des systèmes supportés est obsolète… difficile de juger donc. Et je n'ai vu aucune preuve sur le site qu'une application EFL puisse tourner sous windows. Pour moi, c'est important, car 90% au bas mot des utilisateurs des appli que je fais risquent d'être sous cet OS.
De mon côté j'en vois au moins 4 que j'aie utilisé (je parle pas de celles que j'ai jamais testé, mais j'en connais):
C::B est assez connu chez les dev C++, et FileZilla est le 9ème projet le plus téléchargé de sourceforge (selon wikipedia, il a été 7ème à un moment).
Si tu me dis que tu n'en connais aucun des deux… c'est possible, mais surprenant. Peut-être que je les connais parce que je viens du monde windows, cela dit.
Par contre côté EFL je n'en vois vraiment aucune. A part E17… et il me semble que ça mis quelques années avant qu'il finisse par sortir, non?
Ca, c'est vrai pour le LL développé comme hobby par des barbus pour leur plaisir (moi quand je code pour mon plaisir, c'est des trucs en console d'ailleurs, alors vais pas cracher dans la soupe).
Si on prend des projets majeurs style LO, Firefox, projets autour (et dans) desquels je parie qu'on peut trouver des entreprises, trouver du support semble assez faisable, et ils font le maximum pour que leur produit fonctionne bien sur toutes les plate-formes qu'ils disent supporter officiellement.
Si j'utilise Firefox, je suis a peu près sûr qu'il marchera aussi bien sous Linux que sous Windows et que j'aurai les même fonctionnalités. Idem pour LO.
Chose que l'on retrouve dans wxWidgets: ce qui bloque le passage à la 3.0 sont des problèmes de compatibilité avec Mac OS. Preuve qu'ils testent et supportent réellement les différentes plates-formes, sinon ils auraient juste balancé la nouvelle release et basta.
Perso, je pense que les projets libres peuvent faire de la Q&A, et surtout que s'ils veulent des utilisateurs, ils le doivent.
Pour moi, commercialement parlant, utiliser les EFL en dehors du cadre très strict d'un matériel vraiment peu puissant est une mauvaise idée.
WxWidgets de ce côté semble quand même plus robuste.
[^] # Re: Trollons
Posté par Kekun (site web personnel, Mastodon) . Évalué à 10.
Il me semble avoir entendu qu'une fusion de GTK+ et de Clutter est prévue pour GTK+4, Clutter est, il me semble, basé sur les graphes de scène, peut-être remanieront-ils GTK+ de manière à les prendre en compte ?
[^] # Re: Trollons
Posté par freem . Évalué à -3.
Ce que je regrette avec les outils graphiques "modernes" c'est qu'ils tiennent absolument à faire le café…
Réseau, IHM, multi-thread… ça va jusqu'a réimplémenter les outils standards comme vector et string!
J'ai parfois l'impression que Qt souffre d'un NIH assez pointu… (longue vie à la tradition du vendredi)
[^] # Re: Trollons
Posté par dave_null (site web personnel) . Évalué à 10.
Historiquement, QString et QVector ont étés créés avant std::string et std::vector.
[^] # Re: Trollons
Posté par barmic . Évalué à 1.
Historiquement c'est il y a 15 ans… Si ça n'était que ça ils auraient pu évoluer depuis.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trollons
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
Tu parles de std::string et std::vector ? :)
[^] # Re: Trollons
Posté par Maclag . Évalué à 4.
Historiquement, KDE a remonté beaucoup de choses dans Qt pour pouvoir se concentrer sur d'autres choses, et ensuite, ils n'avaient plus d'implémentation en libkde (plus besoin).
Historiquement, Qt aurait pu remonter le plus de choses possibles aussi dans les bibliothèques standards et se concentrer sur des choses plus intéressantes/importantes.
[^] # Re: Trollons
Posté par Moonz . Évalué à 10. Dernière modification le 26 avril 2013 à 14:21.
Quelle librairie standard ? L’implémentation de la librairie standard C++ de GNU ? Microsoft ? Borland ? Intel ?
À l’époque de Qt la plupart des fonctionnalités étaient là dans la lib standard C++, le problème c’est que Qt visait la portabilité et que la moitié des implémentations n’étaient pas compatibles (sans compter le support médiocre des templates C++ par les compilateurs de l’époque qui les a forcé à se diriger vers un truc maison, moc).
De plus la modification de la librairie standard de C++, c’est quelque chose de bien plus lourd (comité de normalisation) qu’une simple bibliothèque gérée par une seule entitée. Si c’était si facile que ça de modifier la lib standard C++ boost n’aurait pas de raison d’être.
[^] # Re: Trollons
Posté par Guillaume Denry (site web personnel) . Évalué à 9. Dernière modification le 26 avril 2013 à 11:43.
Idéalement, je souhaiterais également une myriades d'outils puissants d'horizons diverses et qui s'accordent parfaitement bien entre eux, mais la vie réelle n'est pas comme ça et quand Trolltech a décidé de prendre les choses en main, de ne pas attendre l'émergence d'outils formidables d'horizons divers, et d'élargir les fonctionnalités de son toolkit tout en gardant une cohérence globale de l'API, ça n'a à mon avis, pas été une mauvaise chose. Principalement parce que Qt est (devenu tôt) libre.
Le point « négatif », c'est qu'on est en effet sans cesse en train de se demander à quel point il faut « maquer » son appli avec Qt. N'utiliser que QtGui comme VLC par exemple, ou bien intégrer complètement QtCore (ou d'autres modules) en profondeur.
Je vois donc au moins trois gros avantages pour Qt :
- Son API limpide et bien pensée, ce qui peut faire envisager plus facilement un départ le jour où on tombe sur un meilleur toolkit dans un domaine spécifique. Ca arrive rarement, en général, le projet Qt intègre assez vite ces nouvelles technos via une API.
- Le fait qu'il soit libre
- Le fait qu'il soit très activement développé et réactif, capable de s'adapter sans cesse à l'écosystème mouvant du développement
[^] # Re: Trollons
Posté par freem . Évalué à 1.
Honnêtement, j'ai vraiment juste voulu nourrir le troll :)
Je comprend l'intérêt des gros framework, utiles pour les applications de type mastodonte (les plus courantes, celles qui intègrent le gestionnaire de fenêtre directement pour mieux faire doublon avec l'OS) mais je trouve regrettable que pas mal de petites applications suivent le même chemin.
Et surtout, je trouve très très regrettable qu'il y ait très peu de toolkit graphiques qui ne soient pas des framework… je ne suis même pas sûr d'en connaître un seul en fait.
[^] # Re: Trollons
Posté par cedric . Évalué à 4.
Le probleme, c'est qu'a partir du moment ou tu veux faire un toolkit graphique. Tu as besoin d'une gestion des event. Tu as besoin d'asynchrone. Tu as besoin de thread. En gros, tu as besoin d'une main loop ! Tu as besoin de discuter avec des process separe, alors tu rajoutes une petite couche reseau pour te connecter au divers demon dont ton framework a besoin pour founir des services plus sur et plus efficacement. Et voila, tu finis forcement avec un framework parce que c'est juste le seul moyen d'implementer un toolkit graphique optimal. Et tant qu'a etre optimal, autant l'etre aussi pour les plus petites applications…
[^] # Re: Trollons
Posté par Philippe F (site web personnel) . Évalué à 1.
Tu as surtout et avant tout besoin d'une bonne boucle d'évènement. D'ailleurs les threads ont été rajoutés très tardivement dans Qt, genre dans Qt 3. Et globalement, ca reste peu recommandé.
Par contre, avoir un évènement "rappelle-moi quand il y a des données sur ma socket sans bloquer le GUI en attendant", c'est top et ca se fait sans threads…
[^] # Re: Trollons
Posté par cedric . Évalué à 9.
Tu fais comment la decompression d'image sans bloquer ta main loop. Tu fais comment l'upload de texture sans bloquer ta main loop. Tu fais comment le rendu d'une frame sans bloquer ta main loop. Donc oui, c'est necessaire d'avoir une bonne boucle d'evenement, mais ce n'est pas suffisant. Aujourd'hui faire un toolkit graphique performant sans utiliser de thread, ca va etre… comment dire… bloquant ! :-)
[^] # Re: Trollons
Posté par freem . Évalué à 0.
Peut-être que toutes les applications n'ont pas besoin de décompresser des images et textures lourdes, tout simplement.
Si je prends le cas de Code::Blocks, de Visual Studio, de galculator… je ne crois pas que ces outils aient le moindre besoin de décompresser des images lourdes.
Le multi-thread est utile dans mes exemples, mais surtout pour les 2 IDE, et n'est pas vraiment lié à l'IHM, plutôt de l'auto-complétion de code.
Accessoirement, vue la puissance de calcul des machines modernes, on pourrait objecter qu'on ne le sentirai pas.
Attention, je ne remets pas en cause l'utilité des threads: je me moque de mon karma mais quand même, faut pas pousser. Juste qu'ils ne sont pas nécessaires dans la plupart des applications qui n'ont pas de tâches lourdes à faire. Et créer un thread à un coût, en ressources mais aussi en débogage.
[^] # Re: Trollons
Posté par Yukito (site web personnel) . Évalué à 3.
Euh… J'utilise régulièrement les threads Qt, et ça marche très bien. Pour une application de calcul (scientifique ou autre) avec une interface graphique, par exemple, je pense même que Qt est un très bon choix.
[^] # Re: Trollons
Posté par Philippe F (site web personnel) . Évalué à 3.
Je voulais surtout souligner que pour faire du GUI et pour faire de l'asynchrone, le besoin n'est pas comme semble l'indiquer le commentaire précédent "les threads" mais une bonne boucle d'évenement.
Les threads sont utiles pour gérer une tâche longue sans bloquer le GUI (calcul, IO), mais pas pour faire un bon GUI réactif.
Trop de gens pensent que les threads sont la panacée de l'asynchrone, à tort !
Pour ce qui est de l'intégration des threads dans Qt, j'ai un peu décroché depuis Qt3 mais à l'époque, je trouvais ça pas très naturel vis a vis du fonctionnement du reste du framework. Il y avait des limitations. Beaucoup de progrès ont été fait depuis et c'est très bien !
[^] # Re: Trollons
Posté par groumly . Évalué à 3.
L'event based, c'est bel et bien, ca marche, clairement, cf le js.
Mais quand meme, devoir toujours interompre ce que tu fais, c'est relou.
Tu dois dezipper un fichier de 1gb, tu preferes quoi:
- tout balancer sur une queue gcd ou un thread, ou tu peux avoir un code tres clair: ouverture du fichier bloquante, dezipper un stream
- devoir tout interrompre en permanence, avec des callbacks de partout, rendant le debug vachement plus dur, a potentiellement devoir stocker des trucs localement, te forcant a avoir des objets non thread safe?
Les threads c'est dur a gerer, c'est clair, et dans un environement a la js de base, c'st overkill dans 90% des cas.
A l'inverse, quand j'ecrit mon ImageService qui redimensione, crop et applique de CIFilter sur des images haute resolutions, le code est deja assez complique comme ca pour pas avoir a s'emmerder avec des QtRunMainLoop de partout (et accessoirement, je peux tout faire sur la stack et eviter des problemes de thread safety). Et GCD t'offre du cpu throttling en cadeau bonux.
A l'inverse, tu peux te retrouver bloquer avec de l'event based, flex avait une libraire de parsing json qui faisait tout d'un bloc, des que ton arbre depassait les 100-200kB, tu te retrouvais avec des freeze d'ui et tu pouvais pas y faire grand chose.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par freem . Évalué à 1.
Evidemment que le thread est mieux dans ce cas. Maintenant, décompresser un fichier n'a pas grand chose à voir avec l'IHM que je sache…
[^] # Re: Trollons
Posté par groumly . Évalué à 1.
Et alors?
Tu preferes te fader ton pooling de thread a la main "parce que c'est pas une IHM"?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Trollons
Posté par freem . Évalué à -5.
Pour faire court: j'apprécie quand les outils que j'utilise ne sont pas liés les uns aux autres.
Je considère que si jamais je détecte un bug dans un tel outil, je peux le corriger.
Ça m'est d'ailleurs déjà arrivé, parce qu'un outil n'intégrant pas 10 000 fonctionnalités différentes, autrement suivant les principes du KISS, est bien plus simple à fixer.
Voila pourquoi je n'apprécie pas les gros framework comme Qt ou WxWidgets (contrairement à ce que j'ai pu laisser entendre pour des fins de trollage :p).
Vu que j'ai pas le choix, je m'en sers, mais c'est principalement parce que je ne connais pas de bibliothèque de toolkit n'accomplissant que leur tâche.
Oui, dans l'absolu, je préfèrerai un outil qui me permette de gérer les thread, un autre qui gère la traduction, un différent pour l'IHM, un distinct pour l'encodage, etc…
Même qu'ils soient regroupés sous un même nom, tant que je peux les utiliser complètement indépendamment les uns des autres, comme pour boost (quoique, certaines lib boost dépendent d'autres lib boost).
A mon sens, Qt est un langage qui ne s'assume pas: modification de la chaîne de compilation, ré-implémentation et volonté de remplacement de la STL, etc.
Il me semble idéal pour remplacer Java quand on veux plus de perf, en échange d'une syntaxe un peu plus complexe, par exemple.
Langage basé sur le C++, et qui se compile en générant du C++ ok, mais c'est bien ainsi que C++ à commencé: ça ne faisait que générer du C à partir de code C++, grâce à l'outil cfront. Ensuite, j'imagine qu'il fallait encore compiler…
[^] # Re: Trollons
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Tu le dis toi-même, certaines libs boost dépendent d'autres lib boost.
Un gros effort depuis Qt3 a été fait pour découper Qt en modules les plus indépendants possibles les uns des autres, ce qui rend le framework beaucoup moins monolithique, il est possible de n'utiliser que QtCore et avoir un binaire léger lorsqu'on a besoin que des structures de données évoluées de Qt. Ou bien QtCore et QtNetwork si on veut faire une appli réseau en CLI.
Le principe KISS est justement respecté avec l'interdépendances des libs, tu délègues la gestion des chaines et leurs différences encodages possibles à une lib pour ne pas la réinventer dans la tienne et rendre ton bouzin compliqué.
[^] # Re: Trollons
Posté par freem . Évalué à -3.
J'aurai dû ajouter l'adjectif "rares" :) (et le fait que la seule dépendance que j'aie eu pour le moment est envers la lib "system" qui est devenue partie intégrante du standard. Mais je suis loin de les avoir toutes utilisées…)
Et si on continue sur les points forts de boost, il faut préciser que la plupart de ses lib ne sont que des headers. Niveau simplicité d'usage, on peut difficilement faire mieux (et Qt passe donc hors catégorie sur ce point, voir la suite).
On dirait que ça a bien évolué alors. Tant mieux. Plus que la chaîne de compilation à simplifier, alors?
Parce que ce point à été (et restera encore un certain temps je pense) un vrai point bloquant.
On peut dire ce qu'on veut, mais la mécanique des signaux si chère à Qt possède ce défaut majeur qui est de rendre la compilation bien plus casse-pieds, alors que les autres framework s'en passent très bien.
Dès lors que tu ne veux pas utiliser l'IDE officiel, tu galères. En tout cas, à l'époque de mon BTS KDevelop galérais (y'a 7 ans en gros) lui qui était pourtant écrit avec Qt (je me rappelle qu'il fallait invoquer l'outil à la main… moc, c'est ça?), il y a 3 ans Visual Studio 2008 galérait (je sais pas maintenant si c'est plus simple, mais j'en doute), Code::Blocks galèrait encore y'a 3 ans, utiliser la ligne de commande sous windows imposait d'utiliser une ligne de commande customisée par et pour Qt (mais qui ne connaissais du coup que les modifs faites par et pour l'installateur de Qt, irrecevable pour moi)…
Il n'y a bien que Qt Creator et CMake qui ne galèrent pas. Pour le coup, vu que je n'utilise plus trop d'IDE, je pourrais peut-être m'y remettre, mais l'idée de risquer d'en chier avec la compilation pour une fonctionnalité dont tout les autres framework se passent allègrement me rebute.
J'imagine qu'on va me dire qu'il utiliser l'outil qu'une seule fois et blablabla… mais de mémoire, il faut l'utiliser à chaque modification de l'interface, ce qui peut arriver souvent… Enfin, arrivais, avant l'arrivée des technos ou l'interface n'est plus codée en dur. Mais là encore, les autres le font aussi bien sans ajouter leur outil dans la chaîne.
Ce qui est certain de toute façon, c'est que pour au moins un projet que j'aimais bien (rolisteam), et pour lequel j'avais envie de contribuer et tant pis pour la lib Qt sous-jacente que je ne maîtrisais pas (j'avais des souvenirs du BTS mais ça datait déjà) je n'ai jamais réussi à compiler, sauf à utiliser QtCreator, mais ce truc n'a vraiment jamais été à mon goût, moi qui préfère les interfaces minimalistes.
[^] # Re: Trollons
Posté par tanguy_k (site web personnel) . Évalué à 4.
C'est modulaire depuis la sortie de Qt 4.0 en 2005 (QtCore, QtGui, QtNetwork, QtXml…)
Qt 5 va encore plus loin.
Qt 3 il est vrai n'etait pas modulaire.
Ouai faut pas exagerer non plus. Il suffit d'appeller un outil (moc) avant la compilation.
Certes c'est une etape supplementaire donc c'est penible par definition, mais ca n'a rien de dramatique comme tu le laisses entendre.
QMake, CMake, SCons, Waf… font ca automatiquement.
Meme pour Visual Studio, il y a un add-in qui existe depuis un paquet d'annees.
Et si tu veux ecrire ca a la main toi meme pour GNU Make par exemple, ca prends 2 lignes :
Y'a quand meme des trucs un peu plus insurmontable que ca en developpement logiciel non ?
[^] # Re: Trollons
Posté par freem . Évalué à -5.
Il y a aussi des framework qui n'imposent pas de restriction aussi ridicule. J'irai même jusqu'a dire que Qt est le seul à le faire…
[^] # Re: Trollons
Posté par Guillaume Denry (site web personnel) . Évalué à 4. Dernière modification le 30 avril 2013 à 17:01.
Les mots ont un sens. Que veux-tu dire par "ridicule" ? Qt est un framework d'âge plutôt vénérable et est porteur d'un héritage technique dont chaque nouveau composant (j'allais dire "sédiment") pouvait trouver justification à chaque étape de son intégration => Trolltech trouvait le C++ une bonne base pour faire du développement multi-platforme mais n'étant pas satisfait par l'état des technologies de RTTI et des systèmes d'évents du moment (je pense principalement pour des raisons de portabilité), choisit de développer via un système de macros et de sur-couche au langage des outils supplémentaires pour simplifier la vie du développeur.
C'est quand même surprenant ta fixette, je connais pas ou peu de monde à ce point bloqué par cette phase de génération de moc en regard des énormes avantages que présente Qt en échange.
Pendant longtemps j'ai fait du Qt avec emacs et qmake s'est toujours occupé de générer les moc à ma place sans que je n'ai guère à m'en soucier.
Ensuite, je suis passé à cmake et là aussi, on trouve des modules cmake pour s'occuper de ça même si c'était un peu plus laborieux pour moi au départ. (l'écriture des règles cmake me semblait un peu plus ardue au départ que le spectre restreint des commandes qmake)
Il n'est bien sûr pas évident que si (l'ex) Trolltech démarrait ce framework de nos jours il choisirait C++ (encore que, pour des raisons de performances, pas sûr…), mais franchement, je trouve qu'ils sont vraiment parvenus à garder une cohérence globale exceptionnelle, et à reléguer cette histoire de moc dans un périmètre assez restreint pour qu'on ne s'en soucis guère.
[^] # Re: Trollons
Posté par freem . Évalué à 1.
Relis un peu plus haut. La dernière fois que j'ai eu affaire à ce truc, ça a été loin d'être si évident. Bien entendu, ça remonte à plusieurs années et, depuis, mes connaissances et les logiciels que j'utilise on pas mal évolué (j'ai notamment découvert cmake, moi qui ne connaissais que la compilation via les IDE ou en ligne de commande à cette époque).
Je suis conscient qu'ils ont un gros héritage technique, qu'ils ont manifestement (à en lire les réponses) plutôt pas mal réussi à gérer et surtout réduire (modularité du code, notamment).
Je suis aussi conscient que C++11 est bien trop récent pour qu'ils en utilisent les nouveautés dans le coeur (quoique, vu qu'ils se basent sur des outils libres, peut-être qu'ils ont une branche stable ou c'est supporté?) mais il me semble que depuis 2003 (date du standard précédent) il est possible de faire la même chose que ce que Qt fait (au sujet des signaux je parle bien entendu) sans utiliser cet outil.
Pour le coup, oui, je trouve ridicule de conserver cet outil.
Au fait, je me demande ce que donne l'utilisation de cmake sous windows? Avec nos distros linux, cet outil voit sa tâche largement facilitée par le fait que les fichiers de dev soient dans des endroits standards, mais sous windows, ce n'était pas encore le cas la dernière fois que j'ai regardé.
Faudra que je teste, peut-être demain, je dois bien avoir une vieille licence d'xp qui traine…
[^] # Re: Trollons
Posté par Batchyx . Évalué à 3.
Un processus à part, avec qui tu communique, et sur lequel tu à bien plus de contrôle que sur un thread. Tu peut définir plus finement sa priorité, ce que tu partage avec lui, et, point bonus, si jamais ton imbécile d'utilisateur idiot change d'avis, tu peux tuer ton processus et l'oublier, pas comme avec les threads ou tu est obligé de faire des hacks foireux.
[^] # Re: Trollons
Posté par Olivier Serve (site web personnel) . Évalué à 5.
Du coup, tu consommes plus de mémoire, tu perds du temps lors de la communication avec ledit process sans compter les changements de contexte.
Ce n'est pas non plus la panacée.
[^] # Re: Trollons
Posté par rewind (Mastodon) . Évalué à 3. Dernière modification le 29 avril 2013 à 22:38.
Je regarde l'API de zlib qui permet de décompresser en flux au fur et à mesure donc je fais un widget qui permet d'afficher la progression de la décompression que je mets à jour au fur et à mesure que je décompresse. Ça ne fige pas l'interface, ça permet à l'utilisateur d'avoir un rendu et pas besoin de thread ou de process séparé.
[^] # Re: Trollons
Posté par cedric . Évalué à 3.
Et tu garantis comment le maintiens de 60fps quelque soit la charge de ta machine ? Il est juste certain qu'avec ton design, ca va lagge…
[^] # Re: Trollons
Posté par freem . Évalué à 1.
Pourquoi ne pas laisser au noyau la charge de faire son boulot efficacement, c'est à dire: gérer les processus?
[^] # Re: Trollons
Posté par rewind (Mastodon) . Évalué à 1.
Je ne peux pas les garantir et toi non plus. Parce qu'avec une charge très élevée, tu auras beau faire ce que tu veux, tu ne pourras rien garantir du tout sur le nombre de fps (une des raisons est que le noyau Linux n'est pas un noyau temps réel).
Ensuite, avec mon design, le seul truc qui va un peu gêner, c'est que la décompression sera un poil plus lente parce qu'elle est intégrée une boucle d'affichage. Mais il fallait montrer que c'était possible, pas que ça aille vite.
[^] # Re: Trollons
Posté par Guillaume Denry (site web personnel) . Évalué à 3. Dernière modification le 30 avril 2013 à 14:51.
Euh, j'espère ne pas me tromper mais ce que veut dire Cédric, c'est comment tu sais que la fragmentation de ton algorithme de décompression pour sera faite correctement même pour des petites machines, ou bien des contextes de surcharge intensive du processeur, c'est-à-dire en ayant une garantie minimale de rentrer assez souvent dans la boucle d'événements pour l'IHM ?
Le threading permet un réglage fin de tout ça, délégué à l'OS, mais dans le cas d'un monothreading, l'atomicité de ton traitement de décompression est statique, c'est toi qui le choisit, par exemple, tous les 10Ko de donnée décompressées, et non pas à l'instruction comme l'est le threading classique.
C'est quand même moche.
'fin bon, c'est un peu con, on est juste en train de discuter de l'avantage ou non des threads, déjà été fait mille fois :)
[^] # Re: Trollons
Posté par rewind (Mastodon) . Évalué à 1.
Non, on discute des threads dans une UI. Personnellement, je suis pour les threads parce que de nos jours, on n'a pas un seul ordi qui ne soient pas multicœur. Mais dans le cas des UI, ce n'est pas forcément un avantage. Le modèle à événements et le modèle thread se marie assez mal. Ou alors, pour des cas très très précis, et hyper bien délimité. Il est vrai que le cas présenté pourrait en faire partie mais j'ai juste voulu montrer que ce n'était absolument pas une obligation, rien de plus.
[^] # Re: Trollons
Posté par neil . Évalué à 3. Dernière modification le 26 avril 2013 à 19:15.
Pas depuis Qt 4.8. Sous Qt 5, le rendu OpenGL (pour Qt Quick) est automatiquement mis dans un thread séparé, et tout est conçu pour marcher avec des threads. Enfin, sauf sous X par défaut (donc c’est pas obligatoire). Mais oui, Qt permet toujours de faire pas mal de truc sans threads.
[^] # Re: Trollons
Posté par ElChinese . Évalué à 1.
<mode vieux con>
Ce qui est super sympa quand il n'y a justement pas moyen d'avoir des threads, comme dans Windows 3.11, d'où Windows Socket API (WSA, 1992)
</mode vieux con>
[^] # Re: Trollons
Posté par freem . Évalué à 1.
Ton point de vue se défend, mais je ne suis pas convaincu.
Je vais prendre deux exemples simples: wesnoth et flare. Ce sont des jeux, mais ils ont quand même des contrôles graphiques permettant les actions habituelles: cases à cocher, bouton cliquable, zone de saisie, etc.
Je vais prendre chacun des points que tu as levé, et on va voir s'ils y sont intégrés.
Je pourrais aussi citer aptitude, maintenant que j'y pense, qui a le mérite de ne pas être un jeu, mais je ne pense pas qu'il y ait conflit avec la plupart des points précédents.
En fait, je viens de me souvenir de FLTK. Jamais utilisé parce que le projet m'a l'air quelques peu chaotique, mais il semble bien que ça sois relativement proche d'un toolkit ne faisant que s'occuper des IHM.
[^] # Re: Trollons
Posté par cedric . Évalué à 4.
Tres bien comme exemple Wesnoth. Le fait qu'il ne s'appuie pas sur un toolkit 2D performant fait qu'ils ont du reinventer pas mal de chose et contrairement a un projet dont c'est le but, ils sont loin d'etre aussi performant qu'il pourrait l'etre. Ils ont aussi du mal a pouvoir faire de l'OpenGL/OpenGL ES.
Avec un framework plus complet, ils auraient beneficie d'une boucle de rendu performante. D'un demarrage plus rapide en partageant des ressources avec le reste du systeme. Peut etre aussi une solution plus securise en separant le process qui charge les ressources du process principal.
Mais ils ont decide d'utiliser un toolkit plus simple. En fait, c'est un framework, mais juste plus bas niveau, la SDL. Pour le reseau, je ne pense pas me tromper en disant qu'ils utilisent SDL_Net. Donc ils ont bien utilise un framework. D'ailleur la SDL, n'est pas vraiment un toolkit graphique, vu que les primitives graphiques qu'elle fournit sont tres limite et que les applications doivent redevelopper quasiment toute leur boucle de rendu.
Pour FLTK, je n'ai aucune idee de ces limites, mais c'est aussi gros que les EFL. Donc pour un toolkit qui ne fait que l'IHM, tu "gagnes" pas grand chose..
[^] # Re: Trollons
Posté par freem . Évalué à 2.
Yep, je me demandais si quelqu'un allait réagir au sujet de l'IHM de wesnoth qui est… hum… primitive et lente :) (essayer d'utiliser le "nouveau" lobby mène à une mort par ennui certaine à force d'attendre que la machine accepte de se mettre à jour)
Par contre…
SDL et SDL_net ne sont pas des framework, mais des bibliothèques, qui n'imposent pas leur mainloop: c'est à l'utilisateur de l'implémenter.
Accessoirement, le but de ces outils est juste de donner un accès au matériel sans se prendre la tête, pas de faire des IHM, et je veux bien que tu m'indiques quel composant de wesnoth utilise le réseau pour permettre la communication entre 2 threads, je suis curieux. Si c'était le cas, ce serait moins lourd d'attendre après l'IA je pense.
Tu as répondu pour wesnoth. Tu pourrais répondre la même chose pour flare (mais tu ne connais peut-être pas ce jeu) sauf que les problèmes de perf ne sont pas aussi critiques (le jeu est moins lourd, et pas fini, ça doit aider).
Par contre, tu as laissé aptitude de côté? Et je vais ajouter ncmpcpp aussi, tiens.
Ncurses est utilisée par pas mal de programmes (plus que les EFL ou FLTK je pense :) ) et ne me semble pas implémenter les outils qui te semblent vitaux? Pourtant les IHM d'aptitude et de ncmpcpp ne sont vraiment pas crades, si on accepte de ne pas avoir de dégradés et autres fioritures graphiques.
[^] # Re: Trollons
Posté par cedric . Évalué à 4.
Non, je ne connais pas flare du tout.
Non, mais serieux, Ncurses quoi ! On parle d'interface graphique quand meme ! Parce que bon, c'est pas juste les degrades et les fioritures graphiques en moins, c'est toute l'ihm qui fait penser aux annees 80, la ! Sur que ca demande pas autant d'effort de pousser quelques characteres colorise face a des millions de pixels. Donc forcement, on n'a pas trop besoin de se poser de question. Et puis le cote asynchrone on s'en tappe un peu, les utilisateurs sont habitue a ce que ca bloque sur ce genre d'interface ! Quelle blague !
[^] # Re: Trollons
Posté par freem . Évalué à 0.
Une interface graphique, c'est un truc qui sert à utiliser un programme sans galérer à taper des lignes de commandes super lourdes pour moi.
Si c'est pour voir du picasso, mieux vaux aller dans un musée, ça marchera mieux. Remplace les "quelques characteres colorise" par des zolies nimages colorisées et tu l'as, ton interface moderne…
Comme tant de gens, tu confond moderne et joli.
[^] # Re: Trollons
Posté par cedric . Évalué à 1.
Desole, mais une interface en ncurse, ce n'est ni moderne ni joli. C'etait moderne dans les annees 70. Depuis, il y a eu Xerox, l'Apple II, XWindow et d'autre truc comme ca. C'est bien de troller, mais quand meme croire qu'il suffit de remplacer les quelques characteres colorise par des nimages pour avoir une interface moderne, c'est juste soit de la mauvaise fois, soit de l'incompetence. Vu qu'on est entrain de troller, je suis plus tenter par la premiere explication ;-)
[^] # Re: Trollons
Posté par freem . Évalué à 3.
Je ne dis pas que c'est moderne et/ou joli. Je dis juste que c'est aussi moderne (et bien plus moche, faut avouer) que 90% des applications récentes que j'aie vu.
Au final, les IHM sont toujours à base de boîtes de dialogues, de zones de saisie, de boutons à cocher etc… la grande différence c'est bien souvent tout ce qui a trait au thème de l'application: couleurs, fontes, écritures en gras taille 18, bla bla bla.
Ah, j'oubliai, il y a le support des périphériques de pointage qui est apparu (bah oui tu cites xerox quand même) mais ncurses aussi la supporte.
En fait, il y a les icônes qui manquent, je viens d'y penser. Mais ça doit être lié à ma manie de les enlever quasi-systématiquement sur mes logiciels du quotidien :D
:-)
[^] # Re: Trollons
Posté par zebra3 . Évalué à 2.
C'est vrai que ncurse est trop rapide pour être moderne ; une appli moderne d'aujourd'hui doit être lente à charger :-)
Au moins avec ncurse, je n'ai pas l'impression d'attendre la moitié du temps.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Trollons
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Il parait que les EFL sont rapide aussi.
Cela me rappelle un des première utilisateurs de Lisaac qui avait été soufflé de voir qu'un hello-world Lisacc, utilisant une pop-up ne faisait que 12ko d'exe sans lib externe.
"La première sécurité est la liberté"
[^] # Re: Trollons
Posté par Philippe F (site web personnel) . Évalué à 10.
Un troll Qt/Gtk/STL, ca fait bien 10 ans que j'en ai pas vu un beau.
Aller, je me lance: std::string a très peu de chose à voir avec une QString. Ah si, le seul point commun, c'est que c'est un conteneur.
Mais voyons ce qu'on fait couramment avec une chaîne de caractère de nos jours:
- la stocker en latin1() pour l'afficher dans de vieux outils qui utilise encore le latin1: 1 point pour QString, 0 pour std::string
- la convertir en UTF8() pour un format d'échange standard: 1 point pour QString, 0 pour std::string
- connaitre son encodage pour pas se rater dans les conversions: 1 ponit pour QString, 0 pour std::string
- la couper en petits bouts: 1 point pour QString, 0 pour std::string
- vérifier si elle contient une chaine particulière, si elle commence par une chaine particulière, si elle se termine par une chaine particulière: 1 point pour QString, 0 pour std::string
- y stocker des floats, doubles, entiers, autres chaines de caractère: 1 point pour QString, 0 pour std::string
- la parcourir avec des itérateurs standard du C++: 1 point pour QString, 1 point pour std::string .
Conclusion: la std::string n'a a peu près rien à voir avec une QString. Les trucs les plus pénibles à faire avec une chaine de caractères de nos jours (conversion d'encodage, affichage de valeur facon printf), vérification de contenu, découpage, … se font en un appel sur une Qtring et en 50 lignes de code dans le meilleur des cas en std::string.
[^] # Re: Trollons
Posté par guppy . Évalué à 1.
Tu exagères un peu je trouve :
float pi = 3.141592;
std::ostringstream f;
f << pi;
std::string result = f.str();
Ça fait 50 lignes ça ?
std::string chaine = "bidule";
if (chaine.find("idu") != std::string::npos)
;
A part pour les problématiques d'encodage, std::string me semble équivalente à QString.
Encore que pour ces fameux problèmes, il semble y avoir des solutions, mais je n'ai jamais eu besoin de m'y pencher.
[^] # Re: Trollons
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
ça reste toujours moins concis et expressif que :
QString str = QString::number(pi);
:)
[^] # Re: Trollons
Posté par monsieurmoche . Évalué à 10.
Avec C++11 on peut faire ça, désormais :
On peut difficilement faire mieux !
[^] # Re: Trollons
Posté par freem . Évalué à 3.
Toi, tu sais que tu viens de changer ma vie?
[^] # Re: Trollons
Posté par Philippe F (site web personnel) . Évalué à 5.
Quand je dis faire des trucs façon printf, je mets la barre un peu plus haut que afficher juste un float:
La version recommandée est plutôt:
Vas-y en STL, je compte les lignes.
Je veux bien voir la conversion d'encodage aussi, juste pour rire.
La STL, ça reste quand même un truc limite académique, avec une utilité pratique très limitée. Dès que tu fais un programme qui intéragit avec le monde extérieur, ce sera très très très insuffisant. Heureusement, il y a des framework qui tiennent la route pour boucher les trous, comme boost. D'ailleurs si tu regardes de près dans boost, il doit plus rester beaucoup de STL, je pense qu'on peut lui faire le même procès qu'à Qt.
[^] # Re: Trollons
Posté par freem . Évalué à 0.
Vraiment, je te conseilles de consulter cette page avant de continuer à parler de std::string :D
Tu y remarqueras que la découpe et la recherche se font très bien, le stockage de float se fait aussi sans souci.
Les 3 points qu'il te reste sont tous liés à l'encodage. Je ne sais pas si C++11 à intégré des fonctionnalités liées aux conversions d'encodage, mais ce qui est sûr, c'est qu'on peut au moins utiliser d'autres encodages depuis: http://en.wikipedia.org/wiki/C%2B%2B11#New_string_literals
[^] # Re: Trollons
Posté par Troy McClure (site web personnel) . Évalué à 2.
wow je decouvre la fonction stod(string &) du c++11, quelle abomination ! The function uses strtod to perform the conversion ça promet encore plein de surprises en fonction de la locale qui est configurée, je pensais que tout le monde avait compris la leçon , depuis le temps. Au moins QString est plus coherente en utilisant tout le temps la locale C.
# Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par manatlan (site web personnel) . Évalué à 4.
En QT, il y a déjà l'excellentissime KdeEnlive ! Qui est a des milliards d'années lumières de ce que peut faire openshot.
En lisant les com sur le post du blog d'openshot. Ils disent "pygtk is dead, the last important commit where on 2010 or 2011".
Oui, pygtk est deprecated depuis un bail maintenant. Et gtk encourage les devs python/gtk à utiliser PyGObject (https://live.gnome.org/PyGObject) ! Qui est une sacrée techno d'introspections et évite à devoir maintenir des bindings de oufs. J'irai même jusqu'à dire que gobject est une techno du futur ;-)
Ils font fausse route, ils avaient un bon créneau : un editeur video sous gtk/gnome. Là, ils vont entrer en "concurrence" avec kdeenlive. (cependant, en étant mauvaise langue, c'est vrai qu'openshot avait déjà un look de petite appli kde/qt, avec des icones spaces)
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par gnumdk (site web personnel) . Évalué à 3.
N'importe quoi, on juge pas un outils sur son toolkit graphique mais sur ce qu'il fait…
OpenShot vise le logiciel de montage vidéo simple ce qui est tout sauf le cas de kdenlive…
De plus, il font un outils en pure Qt ce qui ne changera absolument rien pour les utilisateurs de Gnome hormis le fait que l'outil sera sûrement plus réactif.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par manatlan (site web personnel) . Évalué à 2.
Pas plus tard qu'il y a deux semaines, j'ai du faire un montage …
J'ai tenter openshot en premier. Et je suis très vite passé à kdenlive. Ne serait ce que pour mettre un titrage décent ;-)
openShot est tellement simpliste que tu ne peux pas faire grand chose. D'ailleurs, certains services web proposent déjà plus qu'openshot en terme de montage ;-)
Et faut pas exagérer, kdenlive est très simple à prendre en main ! Même pour qqu'un qui n'a jamais monté ! Au moins aussi simple qu'openShot.
Mais je suis d'accord : on juge pas un outil sur son toolkit graphique mais sur ce qu'il fait…
Si je suis sur kde, que j'ai le choix entre openShot et kdenlive : il n'y a pas photo ;-)
Et je suis pro gnome/gtk/unity … :-)
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par gnumdk (site web personnel) . Évalué à 4.
Euh, perso j'utilise Kdenlive mais je sais que ma maman serait bien incapable de s'en servir et même moi parfois je galère à faire certain trucs…
T'inquiètes, j'utilise KDE mais je conseille Unity aux gens.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Tu as comparé avec l'outil de montage de blender ? Il m'a l'air bien complet mais très dure à prendre en main.
"La première sécurité est la liberté"
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par ParaDoxe . Évalué à 1.
Oui, il est très complet. La seul chose qui lui manque c'est la syncro automatique des séquences en se basant sur leur poste audio.
Mais il n'est pas complexe, si tu connais un tout petit peut Blender et le montage vidéo. Mais il est prévu pour un usage pro, donc les outils qu'il propose n'intéresseront pas tata Ganine qui veut monter la vidéo de son anniversaire.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par xcomcmdr . Évalué à 1.
Exactement mon cas, kdenlive m'a permis de faire exactement ce que je voulais très rapidement.
OpenShot, je ne m'y retrouvais pas.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par Alex . Évalué à 3.
Preuve que qt est plus ergonomique
bref l'ergonomie dépend du toolkit, openshot a donc bien fait de choisir Qt, CQFD
---> []
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . Évalué à -6.
Pour moi, le toolkit graphique joue quand je sélectionne un logiciel à installer sur ma machine. Diminuer les dépendances est une question de perf pour moi.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par Prosper . Évalué à 4.
Ta machine a 10 ans ?
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . Évalué à 1.
J'ai 3 machines:
Ca réponds à ta question?
Sinon, pour les machines portables, il parait que les batteries préfèrent qu'on ne charge pas trop la ram ou le proc, pour une meilleure autonomie.
Accessoirement, quand je code, j'aime bien que les interfaces graphiques bouffent pas la moitié des ressources de ma machine. La compilation C++ est assez longue comme ça, pas besoin d'en rajouter, pas vrai?
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par gnumdk (site web personnel) . Évalué à 3.
Oui, je pense aussi que ça doit être dur de faire tourner Qt sur du matériel comme celui là…
T'en vois beaucoup toi des applications qui activent de la transparence sur leurs widgets ?
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . Évalué à -4.
Youpi. Ca marche sur 1/3 de mes machines… Ca marche bien entendu aussi sur le netbook, je le sais, et peut-être même sur l'ordinosaure. Par contre, sauf sur la machine de bureau, ça augmente sensiblement la charge.
Mais je présume qu'il est inutile de chercher à te convaincre que charger 2 bibliothèques qui servent à faire la même chose augmente la charge du système…
Sur leurs widgets particulièrement non. De toute façon tu as raison, celles utilisant la transparence ça n'existe bien entendu pas…
D'ailleurs tu ne peux pas imaginer le temps que ça m'a pris pour inventer les fausses preuves contenues dans les liens que j'ai mis… au moins 20s.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par dave_null (site web personnel) . Évalué à 2.
Je ne comprends pas trop ton problème. Un ordinateur est fait pour être utilisé et ça n'embête pas grand monde d'avoir une charge système plus élevée quand on utilise son ordinateur.
En plus tu as des machines capables de largement encaisser deux bibliothèques. Tu cherches à faire tendre ton load average vers 0 ?
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . Évalué à 1.
Oui, l'ordinateur est fait pour être utilisé, et non je ne cherche pas a faire tendre le load average vers 0.
Je cherche juste à ce que ma machine réagisse le plus vite possible à mes demandes, et à ce que les temps de compilation diminuent le plus possible.
Et la, force est de constater que quand j'utilisais un IDE ou même des environnements graphiques classiques sur mon netbook, ces besoins n'étaient pas satisfaits: la machine mettait du temps à réagir à mes injonctions et la compilation faisant saturer la ram, la machine swappait terriblement. Dans le genre ralentisseur de compilation, c'est pas mal. En plus quand ça swapait je pouvais rien faire d'autre pour au moins 5 minutes.
Et pourtant, je faisait attention à n'avoir que des outils utilisant GTK. Je ne doute pas une seconde que si j'avais utilisé XFCE avec, par exemple, KDevelop, j'aurai souffert encore plus.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
J'ai aussi un EEEPC, j'ai mis un ssd dedans cela change tout :)
Et puis, je suis passé à 2 Go, il y a quelques mois (30€?), cela aide un petit peu, mais beaucoup moins que le SSD.
"La première sécurité est la liberté"
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . Évalué à 0.
Le ssd est pas dans mes moyens actuels (si je pouvais j'en mettrai un dans le netbook et 2 dans la tour ) mais pour la ram j'ai trouvé une solution très simple et très efficace: i3 + lxterminal.
Vim comme éditeur de texte, clang comme compilo, et j'ai plus jamais saturé la ram en compilant avec mes 4 threads. Le jour et la nuit, pour un environnement de dev.
Juste de temps en temps un coup de ramage parce que, décidément, ce disque dur est vraiment mesquinement lent… (du coup utiliser noatime et empecher vim de faire un fichier de backup en cas de problème a un peu aidé, mais c'est quand même pas la panacée)
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
y'a des ssd à moins de 150€ maintenant.
Sinon, en ligne de commande, je n'ai jamais eu de soucis avec gcc. Sauf avec cimg.h qui voulait ~1Go de ram ou presque.
"La première sécurité est la liberté"
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . Évalué à 1.
Il consomme beaucoup plus de ram que clang. Tu devrais tester, c'est assez bluffant la différence.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par Tibo cocoecolo (site web personnel) . Évalué à 5.
Comme « 200 € c’est quasi rien », tu peux m’en offrir un ? Merci d’avance.
Et même si on a les moyens de s’en acheter un, est-ce toujours nécessaire de toujours consommer alors qu’on a du matériel qui fonctionne ? Il faudrait penser à arrêter la surconsommation.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par dave_null (site web personnel) . Évalué à 1.
Dans ce cas, tu n'es pas obligé non plus de consommer les derniers logiciels à la mode. Les anciens fonctionnent très bien sur du matériel adapté de l'époque.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . Évalué à 1.
Le problème est que les évolutions coûtent parfois une quantité déraisonnable de ressources, et certains, dont je fais partie, considèrent que ça ne devrait pas être le cas.
Mais effectivement, j'ai fini par sélectionner plus rigoureusement mes logiciels pour ne pas avoir de fonctionnalité qui ne me sert à rien et ainsi alléger l'ensemble.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par Antoine . Évalué à -1.
Ben, entre consommer un SSD et consommer un HDD, je ne suis pas sûr que le choix d'acheter un HDD soit plus écologique. Donc, si tu achètes une machine aujourd'hui, autant choisir le SSD (qui, en plus, devrait consommer un peu moins d'énergie et avoir moins de risques de panne).
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par Tibo cocoecolo (site web personnel) . Évalué à 2.
As-tu bien fait attention à la citation que tu as mise ? Je la remets :
J’ai réagi sur le fait que l’on suggérait à freem de changer de matériel plutôt que de choisir raisonnablement ses programmes pour avoir une machine réactive. Si son disque dur lâche, effectivement, pour le remplacer, il pourra être intéressant de choisir un SSD plutôt qu’un disque dur.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par ckyl . Évalué à 2.
Tu m'étonnes,
relatimeest par défaut depuis le 2.6.30…[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par Mme Michu-cide . Évalué à 1.
T'en vois beaucoup toi des applications qui activent de la transparence sur leurs widgets ?
Ne t'en fais, c'est le troll de base du linuxien gravitant autour de son nombril^W^Wsa console.
La 3D ça ne sert que pour les jeux, n'est-ce pas? L'infographie n'est qu'un champ d'application dérisoire en informatique, on le sait… C'est d'ailleurs pour TuxRacer et Compiz qu'Nvidia fournit des pilotes sous Linux.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Kdenlive s'appuie sur les frameworks mlt et ffmpeg avec une interface en Qt (bon OK, à travers kdelib).
Openshot s'appuie sur les frameworks mlt et ffmpeg avec… très bientôt une interface en Qt.
Bref, si vous voulez un OpenShot mais la version qui sortira dans 5 ans, choisissez le Kdenlive d'aujourd'hui. ;)
Alors certes on ne juge ni sur le toolkit graphique, ni les framework, mais ça commence à faire un peu beaucoup. Aujourd'hui ce qui distingue OpenShot de Kdenlive, ce n'est pas le choix d'un design original ni une conception différente du montage vidéo, c'est seulement qu'OpenShot en est encore à balbutier !
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par jihele . Évalué à 6.
En effet. Je ne sais pas où ça en est maintenant, mais il y a un an, je développais (pour bricoler) une petit application python /GTK (cf. journal) et je suis passé de pygtk à PyGObject.
Ça ne s'est pas fait sans mal parce que pygtk a été considéré comme déprécié alors que la doc de PyGObject n'était pas du tout au point. Et lorsque j'ai évoqué le sujet sur la
trollinmailing-list, on m'a répondu qu'il fallait que je l'écrive si elle était incomplète…Ceci dit, c'est clair que l'introspection est une excellente idée et un effort utile pour l'avenir.
Un autre bon point pour Qt, c'est le portage Windows. Côté Gtk, la dernière fois que j'ai regardé, il y a un an, c'était abandonné.
Je suis utilisateur de Xfce dont plutôt Gtk, mais entre les difficultés que j'ai éprouvées, mes lectures ici et autres conversations, si je devais partir de zéro demain, je pourrais m'orienter vers Qt. Tout ça m'inquiète d'ailleurs un peu pour l'avenir de Xfce.
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par fredix . Évalué à 5.
C'est pas grave il y a Razor-qt
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par freem . Évalué à 4.
PygObject? Je suppose que cet objet est rose et à la queue en tire-bouchon… ah, j'ai trouvé, c'est une tirelire!
/me ->[]
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par stopspam . Évalué à 7.
Correction : gtk encourage les devs linux/python/gtk à utiliser PyGObject. Ils pissent juste sur ceux qui veulent vraiment faire une appli multiplateforme en éclipsant les 90% d'utilisateur windows.
Tellement bien qu'au final ça ne fonctionne que sous linux.
Et heureusement qu'il est encore là !
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par Moonz . Évalué à 1.
Pourtant https://live.gnome.org/PyGObject fournit des binaires pour Windows…
[^] # Re: Openshot se tire une balle dans le pied ... Ils font fausse route ;-)
Posté par gnumdk (site web personnel) . Évalué à 6.
Mwai, enfin, il y'a une différence entre fournir un binaire et un logiciel qui fonctionne…
Je me garderai bien de dire que KDE est disponible pour Windows… Y'a des binaires, certes…
# :/
Posté par ParaDoxe . Évalué à 5.
Hem, on peut aussi utiliser GTK+ quand on code avec Emacs. Faut pas déconner non plus.
[^] # Re: :/
Posté par Atem18 (site web personnel) . Évalué à -4.
Ils font surement référence à Qt Creator. Je doute qu'une personne saine d'esprit utilise encore ces reliquats du passé que sont Emacs et Vim. ;)
[^] # Re: :/
Posté par ChickenKiller . Évalué à 4.
Et pourquoi donc ?
(Utilisateur de vim avec qt qui ne comprend pas vraiment en quoi il peut être considéré comme taré)
[^] # Re: :/
Posté par freem . Évalué à 3.
Je me demande toujours comment des gens efficaces peuvent faire pour utiliser un IDE qui perds autant d'espace…
Je sais pas pour emacs, et j'ai utilisé des IDE pour le moindre programme que j'ai fait jusqu'a l'an dernier, quand j'ai commencé à utiliser vim. Je suis loin de le maîtriser et je lui trouve énormément de défauts, mais je n'ai pas encore vu d'IDE me permettant de coder aussi efficacement, c'est à dire sans me forcer à utiliser la souris dès que je veux utiliser une commande, qui ne gâche pas la précieuse place de l'écran de mon ordinateur portable (j'ai 4H de train par jour, alors ça m'arrive souvent de programmer dans le train, et non, j'ai pas accès à des 17" dans le train)
Bref, je ne qualifierais pas les utilisateurs d'IDE de particulièrement sains d'esprit non plus. En tout cas, pas plus que ceux qui préfèrent des éditeurs de textes puissants.
[^] # Re: :/
Posté par karteum59 . Évalué à 0. Dernière modification le 26 avril 2013 à 14:22.
D'un autre côté, il se trouve beaucoup de monde pour soutenir qu'il faut encore se limiter à 80 colonnes en 2013…
[^] # Re: :/
Posté par freem . Évalué à 5.
Bah c'est sûr, avec des outils qui bouffent la moitié de l'écran, c'est plus confortable :D
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: :/
Posté par groumly . Évalué à 2.
Marrant, ton article dit le contraire, avec des lignes de 95 caracteres, la vitesse de lecture etait bien meilleure.
Ensuite, pour du code, eviter de wrapper les lignes ca fait du bien aussi, probablement plus que de mettre une limite de nazi a 80 "parce qu'on faisait comme ca dans les annees 80 quand les ecrans faisait 80x20 pour des raisons techniques, et on evitait de scroller parce que ca prenait 2 secondes pour rafficher l'ecran".
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 27 avril 2013 à 13:12.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: :/
Posté par Michaël (site web personnel) . Évalué à 5.
Limiter la longueur des lignes est effectivement indispensable pour faciliter la lecture et 80 caractères sont effectivement une limite à ne pas dépasser, je commence déjà à avoir des difficultés avec cette largeur! Soit dit en passant, augmenter la taille de l'intervalle de ligne facilite également la lecture sur les supports de mauvaise définition (comme un écran…)
Je crois que pour les journaux, le but est plutôt d'obtenir une grille de composition assez fine pour placer le maximum d'articles sur une page ou de permettre la lecture de l'articles lorsque le journal est replié dans le sens de la largeur (souvent en 3 ou en 4, il y a parfois du monde dans le métro!).
[^] # Re: :/
Posté par karteum59 . Évalué à 3.
Je pense surtout que c'est à l'utilisateur de choisir quelle doit être la largeur de sa fenêtre, et non un dogme "80 colonnes". Les bons éditeurs de texte comme Kate savent très bien faire du word wrap correct i.e. en affichant le reste de ligne (repoussé à la ligne suivante) avec la bonne indentation.
[^] # Re: :/
Posté par Antoine . Évalué à 2.
C'est à peu près du même tonneau que de dire que chaque utilisateur peut indenter comme il veut, au lieu de se fixer des règles de présentation.
Pour les 80 colonnes, il n'y a pas que l'édition de texte, il y a aussi la visualisation. Notamment, si tu fais des revues de code avec un outil comme Rietveld ou Gerrit, tu as deux panneaux de code côte à côte, et du coup c'est 160 colonnes qu'il faut faire tenir sur l'écran, pas 80. Là, tu n'as pas vraiment envie de tomber sur le code du gars qui écrit du code sur 130 colonnes « parce que la limitation à 80 colonnes c'est has-been », sauf si tu as un écran 32 pouces (et, même, la lisibilité sera pourrie).
Bref, jeter à la fenêtre la limitation à 80 colonnes, c'est un argument de confort personnel qui se fiche du travail en équipe.
[^] # Re: :/
Posté par freem . Évalué à 1.
Que veux-tu, certains aiment ne lire qu'un seul fichier à la fois. Je me demande comment ils font pour fusionner des dépôts rapidement par contre. Avec 2 écrans, un par fichier? Mouarf
[^] # Re: :/
Posté par Michaël (site web personnel) . Évalué à 1.
Ta position est complètement dogmatique elle aussi: jusqu'ici tes arguments sont… on est en 2013!
C'est peut-être du word-wrap à peu près correct pour du texte, mais pour du code source, se fier au mode word-wrap d'un éditeur c'est la garantie 1. de lire du code imbitable là où du code imbitable a été écrit et 2. de commiter involontairement des modifications d'espacement.
[^] # Re: :/
Posté par karteum59 . Évalué à 2. Dernière modification le 06 mai 2013 à 13:59.
Je pense en effet que les 80 colonnes viennent des limitations des anciens tty, et n'ont plus lieu d'être aujourd'hui comme limite fixe et intangible. Je comprends tout à fait que dans de nombreux cas il soit souhaitable de limiter la largeur de la fenêtre (je le fais souvent, comme tout le monde), mais je pense précisément que c'est à l'utilisateur (via un éditeur de texte "intelligent") de faire le word-wrap / reshaping qui-va-bien.
Tu n'as pas dû utiliser Kate depuis longtemps avec du code + word-wrap…
[^] # Re: :/
Posté par gnumdk (site web personnel) . Évalué à 1.
Et bien sur tu as choisi la capture d'écran de manière totalement neutre ?
Si j'ouvre 5 vue différentes dans vim, le résultat est le même…
[^] # Re: :/
Posté par freem . Évalué à 1.
J'ai pris la 1ère venue.
Non, tu auras 5 affichages de code source. Si tu affiches 5 codes sources en même temps dans QtCreator, je n'ose imaginer le résultat…
[^] # Re: :/
Posté par Guillaume Denry (site web personnel) . Évalué à 4. Dernière modification le 26 avril 2013 à 16:29.
Ce que tu as posté, c'est la vue "debug" de QtCreator.
Je ne vois absolument rien de choquant à ce que les outils de debugging soient présents à ce moment là.
La vue "classique", c'est lorsque tu cliques sur "Edit" en haut à gauche.
Exemple.
De manière général, étant habitué à emacs, je trouve tout de même QtCreator vraiment efficace et très simple à prendre en main.
[^] # Re: :/
Posté par freem . Évalué à -5.
Vrai que c'est mieux. Si quelqu'un peut trouver un screenchot où la barre de gauche avec les grosses icônes est enlevée, ainsi que la barre de statut en haut du source, la barre en bas, je pourrais me laisser un peu plus convaincre qu'on y perds pas tant de place.
Disons que je lui préfère de très loin Code::Blocks.
Après, les IHM c'est une pure question de goût: j'aime pas celle de QtCreator, mais ça me fera jamais dire que ses utilisateurs sont cinglés. Pas sans provocation de leur part en tout cas :)
[^] # Re: :/
Posté par Guillaume Denry (site web personnel) . Évalué à 7.
Purée o_O
QtCreator est juste mille fois mieux foutu, ergonomiquement parlant et mille fois plus puissant.
Ca passe des menus contextuels à la paramétrabilité du soft, à l'intégration à gcc, à valgrind, à tous les systèmes de gestion de version connus, tout est pensé aux petits oignons.
Ce soft a été une vraie bouffée d'air dans l'univers stagnant des IDE à l'époque, et il ne cesse de progresser dans la bonne direction.
Quand je vois les screenshots : http://www.codeblocks.org/screenshots
Pfiuuu. Et tu te plains d'une barre de statut en haut du code source :)
[^] # Re: :/
Posté par freem . Évalué à -4.
Bah, disons que quand je m'en sers, tu peux enlever toutes les barres d'outil, fenêtres et barres de statut, je ne garde que l'affichage des fichiers source et la barre de menu.
Ensuite, au moment ou j'ai besoin des messages (par exemple) je les invoque avec un appui sur F2.
Ca dépends des goûts.
Le seul truc que je ne retrouve pas dans ta liste, c'est la gestion des (D)VCS.
Pour valgrind, j'ai pas testé le plug-in de C::B, je suis "un peu" paumé avec cet outil. L'utiliser est sur ma todo list, mais… d'abord apprendre à gérer gdb correctement, on verra ensuite.
Niveau paramétrabilité, c'est simple, dans C::B aucun élément d'UI n'est fixe (ah, si, barre de menu et de statut, pardon), et leur (dé/re)placement est simplissime. Chose que je considère vitale et que je n'ai pas retrouvée dans QtCreator.
Après, honnêtement, depuis que j'ai découvert les tiling window manager et CMake, j'ai progressivement arrêté de l'utiliser, au profit de vim en éditeur de texte et de la compilation à coup de commandes. Reste le débugging ou j'ai pas encore trouvé l'outil qui corresponde complètement à mes besoins, mais cgdb me plaît pas mal. Ddd est un autre candidat à fort potentiel, ou peut-être voir pour intégrer gdb dans vim.
Ah, et, bien sûr, je n'utilise pas la version stable de C::B mais les nightly. Je préfère préciser.
[^] # Re: :/
Posté par ckyl . Évalué à 7.
Chacun ses priorités !
[^] # Re: :/
Posté par freem . Évalué à -1.
Le pire, c'est que même avec toute la mauvaise foi du monde je pourrai pas moinsser ça… vu que ça reviens a dire que le fait que j'aime pas qtcreator est une question de goût, donc d'une certaine façon de priorités.
[^] # Re: :/
Posté par ParaDoxe . Évalué à -8.
Ça, ça mérite un -10 directe.
# Finalement...
Posté par yeahman . Évalué à -4.
Hé bien, on a beau dire, y'a de bonnes idées dans les commentaires que j'ai lu dans ce journal !
Et même niveau troll ça reste à peu près intéressant !
La classe !
# Dans le même genre
Posté par gnumdk (site web personnel) . Évalué à 3.
Y'en a qui portent leur appli Gtk+ vers Qt juste pour le fun:
http://blog.lxde.org/?p=982
[^] # Re: Dans le même genre
Posté par saltimbanque (site web personnel) . Évalué à 1.
oh oui c'est une drôle d'idée, qt4 + gvfs
c'est freedesktop son truc!
[^] # Re: Dans le même genre
Posté par zebra3 . Évalué à 1.
En quoi ? Au moins gvfs fonctionne avec fuse et c'est rudement pratique.
J'attends toujours un kio au niveau de gvfs : ne pas pouvoir lire de vidéo sur le réseau en 2013, comment dire…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Windows
Posté par Yukito (site web personnel) . Évalué à 5.
Dans la liste, la raison vraiment importante est probablement le meilleur support des différentes plateformes. Openshot vient en effet de réussir à réunir 40.000 dollars sur kickstarter pour le portage sous windows et mac os : http://www.kickstarter.com/projects/421164014/openshot-video-editor-for-windows-mac-and-linux
En tout cas, ils doivent en avoir vraiment marre de gtk pour prendre une telle décision, parce que migrer de gtk à Qt un logiciel autant avancé, c'est un travail énorme. Il y a forcément des parties du logiciel qu'il faudra réécrire quasiment de zéro.
[^] # Re: Windows
Posté par freem . Évalué à 1.
Peut-être que ça leur permettra de mieux séparer les différentes couches du code, du coup, et que la prochaine fois que ça leur prend ça sera moins compliqué.
Imagines, ils pourraient faire une version en ncurses, avec transformation du flux vidéo grâce à caca.
Bon, c'est vrai que du traitement de vidéo en ncurses, ça pue un peu…
[^] # Re: Windows
Posté par morphalus . Évalué à 5.
Surtout avec la lib caca.
[^] # Re: Windows
Posté par zebra3 . Évalué à -1.
C'est un peu dommage : ils auraient pu en profiter pour améliorer GTK, ça aurait été profitable pour tout le monde.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# le fond du problème
Posté par saltimbanque (site web personnel) . Évalué à 1.
Subsurface aussi… il semble mettre en avant
* cross-platform
* incompatiblité gtk2 / gtk3
http://www.muktware.com/5445/linus-torvalds-subsurface-planning-switch-qt
[^] # Re: le fond du problème
Posté par Yukito (site web personnel) . Évalué à 3.
A propos de l'incompatibilité gtk2/gtk3, le développeur de pcmanfm indique même que dans son cas il était plus facile de migrer de gtk2 à Qt que de gtk2 à gtk3 : "Ironically, fixing all of the broken compatibility is even harder than porting to Qt in some cases (PCManFM IMO is one of them)." (http://blog.lxde.org/?p=990 )
# Le positionnement d'OpenShot et PiTiVi
Posté par Jean-François A. . Évalué à 10.
Pour OpenShot qui est encore codé principalement par un mec en solo (jusqu'à preuve du contraire — et je parle de code, pas de traductions/marketing/etc) mais qui doit se dépêcher de porter à Win + Mac parce qu'il a promis de le faire dans sa levée de fonds Kickstarter, Qt est probablement un excellent choix pour ne pas se prendre trop la tête — du moins, s'il partait de zéro. GTK+ est maintenu de façon assez limitrophe ces derniers temps, alors en-dehors de Linux c'est pas top. Bref la décision de Jonathan est logique sur ce point.
Plusieurs d'entre vous avez remarqué que son argument «PyGTK n'a pas bougé depuis 2011» ne tient pas la route, mais ça c'est lui qui ne fait pas ses recherches comme il faut (ça me rappelle quand il a décidé de passer de GNonLin à MLT, puis récemment de MLT à son propre moteur d'édition not-invented-here, alors que GES avait été créé carrément pour des gars comme lui). Peu importe, de toutes façons l'argument «Qt est mieux supporté sur les autres plateformes» est défendable, du moins si on en croit ce qu'on me raconte depuis des années. En revanche, GTK ne serait probablement pas la mort non plus, et si Jonathan voulait être bon citoyen il pourrait bien envoyer quelques patches par-ci par-là pour corriger les bugs qu'ils rencontrerait, au lieu de réécrire toute son interface graphique «from scratch» (lequel des deux est plus chronophage?). Enfin. Whatever.
Ce que je trouve intéressant de la situation où on se trouve maintenant, c'est que OpenShot change alors de positionnement et de public cible. Il devient «juste un autre logiciel de montage avec une interface Qt multiplateforme» (pour caricaturiser de façon grotesque), alors qu'il était jusqu'à lors implicitement «un logiciel de montage vidéo simple avec une interface GTK» (parce que sinon… quel était le but de son existence face à Kdenlive avec son interface maximaliste en Qt et Pitivi avec son interface épurée en GTK?).
Ce qui mène au constat amusant que Pitivi est le dernier logiciel de montage vidéo restant avec une interface GTK (en ce moment, la version en développement roule avec GTK3, Clutter, et s'appuie sur GStreamer 1.x). S'il y a encore des gens (dingue, mais ça existe) pour qui la question du toolkit et de l'intégration visuelle/comportementale d'un logiciel dans un environnement comme GNOME (ou XFCE, Unity, etc.) est importante, eh bien Pitivi sera toujours là, accepte des patches et lettres d'amour (et participe au Summer of Code, s'il y a des intéressés de dernière minute).
D'une certaine façon, il rend service à Pitivi, qui n'a alors plus forcément à remplir l'impossible mission de conquérir d'autres plateformes que Linux (j'ai un peu l'impression que c'est se tirer dans le pied que de s'éparpiller sur d'autres plateformes quand on a déjà du mal avec une seule, mais c'est débattable).
Soit dit en passant, à titre informatif, le passage de Pitivi de GTK2 à GTK3 était presque un jeu d'enfant. Ce qui complique les choses, c'est le passage simultané à GStreamer 1.x et un paquet d'autres trucs (gobject introspection oblige).
[^] # Re: Le positionnement d'OpenShot et PiTiVi
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
J'ai essayé les trois récemment pour faire mes bandes annonces:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Le positionnement d'OpenShot et PiTiVi
Posté par gnumdk (site web personnel) . Évalué à 2.
Pareil, Pitivi, à part de jolis segfault, j'ai jamais réussi à monter quoi que ce soit avec…
Et je trouve l'interface de OpenShot vraiment sympa… Et puis Kdenlive sous Windows, ça tourne, mais je tenterai pas un montage complet avec…
[^] # Re: Le positionnement d'OpenShot et PiTiVi
Posté par Yukito (site web personnel) . Évalué à 1.
Sur ce point, personnellement, j'ai l'impression inverse. C'est presque toujours une bonne idée d'être multi-plateforme. Cela permet d'augmenter la base d'utilisateurs, et donc le nombre de retours sur les bugs, le nombre de traducteurs, etc.
J'aimerais que les proportions soient inversées, mais par exemple sur les logiciels que je développe (en particulier Kitsune, sur lequel j'ai plus de recul que Flukz), la proportion d'utilisateurs est typiquement 70% windows, 20% linux, et 10% mac.
[^] # Re: Le positionnement d'OpenShot et PiTiVi
Posté par Adrien . Évalué à 4.
Depuis quand l'utilisation d'un toolkit graphique est une fonctionnalité ?? Kdenlive ou skype fonctionne sous Gnome, gimp ou synaptic sous Kde et tout le monde est content (ou presque). Il faut arrêter le délire de séparation : le monde ne s'arrête pas aux frontières GTK ou Qt.
Le seul truc que je vois intéressant dans le toolkit c'est s'il y a une intégration plus poussé dans tel ou tel bureau, comme par exemple digikam ou amarok sous KDE, mais là on n'est au delà de Qt.
[^] # Re: Le positionnement d'OpenShot et PiTiVi
Posté par antistress (site web personnel) . Évalué à 9.
J'ai toujours trouvé que OpenShot ne faisait pas très GNOME malgré son toolkit GTK, à l'inverse de PiTiVi (effort pour une timeline native, respect des HIG…)
Au final, et compte tenu du côté caméléon de Qt, je me dis qu'un soft en Qt respectant la HIG de GNOME (c'est un peu théorique certes) me "choquerait" pitet moins qu'un soft en GTK au design propre, mais c'est pitet une idée…
[^] # Re: Le positionnement d'OpenShot et PiTiVi
Posté par Mme Michu-cide . Évalué à 0.
Malheureusement oui, et c'est un défaut, je l'admet. En fait, je crois que c'est justement la faute à GTK et à l'époque où je trainais ma bille sur KDE ou Fluxbox et qu'on se prenait dans la gueule le théme "pas de thème" de GTK dans la tronche si on n'avait pas le bon gtkrc, du coup, j'ai toujours voulu avoir un logiciel à l'interface homogène avec le reste du bureau.
Cela dit, ça n'empêchait pas l'utilisation mais c'était moins plaisant et quand on a les 3/4 d'autres applications consistentes avec le thème, on se dit que c'est de la faute de ce logiciel rebel.
[^] # Re: Le positionnement d'OpenShot et PiTiVi
Posté par claudex . Évalué à 5.
C'est toujours le cas.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le positionnement d'OpenShot et PiTiVi
Posté par navaati . Évalué à 2.
Hum, sur gtk2 possible mais sur gtk3 le thème par défaut est adwaita, pas le "pas de thème" tout carré
[^] # Re: Le positionnement d'OpenShot et PiTiVi
Posté par xcomcmdr . Évalué à 3. Dernière modification le 27 avril 2013 à 15:15.
Ordre d'importance par ordre descendant (pour moi) :
* logiciel qui juste marche
* logiciel joli
* logiciel bien intégré
Quant à l'homogénéité de l'apparence, les application KDE s'adaptent au thème GTK, et j'ai des icônes équivalents pour les applications KDE (Faenza pour mon Xfce, KFaenza pour KDE).
Et je préfère le sélecteur de fichiers de KDE (plus utilisable que celui de GTK3). :p
Du coup, en matière d'édition vidéo, kdenlive est celui qui m'a séduit (tout comme K3B pour la gravure à la place de xfburn ou brasero).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Pour ceux qui disent que GTK+ n'évolue plus...
Posté par liberforce (site web personnel) . Évalué à 6.
Faut pas dire ça la semaine du GTK+ hackfest:
http://blogs.gnome.org/ebassi/2013/04/20/gtk-hackfest-2013day-1-and-2/
http://blogs.gnome.org/mclasen/2013/04/23/gtk-hackfest-days-3-and-4/
http://blogs.gnome.org/mclasen/2013/04/25/gtk-hackfest-wrapup-and-end/
De plus, effectivement, GTK 4 devrait intégrer Clutter. Ça évolue, c'est juste que ça prend du temps. Mais effectivement, le problème du manque de support Win32 et Mac OS est un vrai problème, car les projets multi-plateformes pensent de plus en plus à migrer à Qt. Il me semblait que Wireshark (par exemple) en avait un peu marre aussi…
[^] # Re: Pour ceux qui disent que GTK+ n'évolue plus...
Posté par rewind (Mastodon) . Évalué à 6.
Quand je lis ces posts, je n'appelle pas vraiment ça de l'évolution mais de la maintenance…
[^] # Re: Pour ceux qui disent que GTK+ n'évolue plus...
Posté par liberforce (site web personnel) . Évalué à -2.
C'est sûr que le portage vers Wayland ou l'adaptation aux écrans haute résolution, c'est de la maintenance… C'te blague.
[^] # Re: Pour ceux qui disent que GTK+ n'évolue plus...
Posté par cedric . Évalué à 10.
Oui. Portage vers Wayland, c'est juste ajoute un nouveau backend (creation de fenetre et recuperation des events) et regarder les problemes d'integration (vu qu'une partie de la gestion de fenetre est faite par l'application). Il n'y a pas de changement du modele de rendu, pas d'amelioration interne du toolkit. Et c'est necessaire pour la survie du toolkit sous Linux. Donc c'est de la maintenance. Pour le support des ecrans haute resolution, a part faire des graphismes plus fin, je vois meme pas ce que ca va changer dans le code !
[^] # Re: Pour ceux qui disent que GTK+ n'évolue plus...
Posté par AmirAmazigh . Évalué à -2.
tl,dr: marketing beat matters even in bits market
Les gens pensent que Qt est un passage vers le mieux hors c'est quand même écrit en C++, et ottez cette incompréhension s'il en est, mais il faut que l'app soit en C++ aussi, nan? Et il me semble que les erreurs de C++ sont pas plus compréhensible que celle du C… la maintenance du code C++ n'est pas grandement améliorer, le pont C/C++ c'est pas du gateau etc…
Sinon la différence importante entre le monde Qt et le monde GNOME c'est la fragmentation de la maintenance (bazar vs cathédrale ?) et du marketing du code. Je m'explique, dans GNOME pour un même projet logiciel on est obligé de "naviguer" entre les libs et les API, c'est frustrant. C'est 99% psychologique car l'API est différentes en fonction du domaine et les conventions de nommage GNOME (ou serait-se glib ?) sont respectés mais psycologiquement on se dit "c'est un autre soft" du coup ça freine la compréhension. Au contraire Qt met tout sous le même chapeau. Typiquement vous voulez faire un widget custom vous passez par un QGraphicsScene vous vous sentez chez vous, la documentation se trouve avec le reste de la documentation Qt et tout va bien dans le meilleur des mondes. Dans ce qui est presentit pour être future pile applicative GNOME, il faudra passer de GTK+4 à ClutterScene pour accéder au même fonctionnalité que la QGraphicsScene… de même pour Pango+Harfbuzz vs QText.
Ce n'est pas que un défaut, d'un point de vue comprehension du soft et des problèmes résolues avoir des noms différents ça aide énormément à comprendre qu'il s'agit de problème différent mais 99% des gens s’intéressent peu à comprendre le comment et pourquoi et veulent juste consommer l'API… malgré tout je suis pour un GNOME-kit avec une seule un seule nommage et une API unifié ainsi que garder le nommage creatif (Harfbuzz, Clutter, Pango… qui sont des muses à mon sens) pour les versions de dev majeurs genre GNOME Text X.Y Pango…
La fragmentation est aussi une force, quand on approche Qt, avec ses XYZ widgets différents, ses TUVW methodes et arguments on a l'impression que c'est insurmontable. Alors que coté GNOME, la présentation est clair de ce point de vue, chaque projet/soft a sa documentation qui explique le cas d'utilisation correctement et qui laisse la porte ouverte vers des utilisations avancées
en nommant le nom des soft dont on utilise les structures pour lesquels une façade existe. Actuellement, je veux faire des anim et une interface funky => Clutter, je veux faire une app => GTK, je veux faire des operations text complexe Pango/Harfbuzz et on peut aussi tout mélanger.
Le coté bazar (et GNU) de GNOME, lui a toujours couté, malgré tout c'est pas les grand nom du logiciel international derrière le projet qui manquent. Aussi en tant qu'Européen on a un biais pour Qt, c'est clair. Tout ça pour dire que je continuerai d'utiliser GNOME (et GTK)!
# Toolkit ou moules-kit
Posté par antistress (site web personnel) . Évalué à 3.
Si GTK est un toolkit, le troll est-il un moules-kit ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.