Vous connaissez sans doute Qt ? Mais si... cette bibliothèque libre en C++ qui permet de faire des applications graphiques, utilisé par KDE. Vous aurez remarqué que les interfaces "classique" sont encore faites avec des widgets rectangulaires sans aucune imagination. Ce sont des interface des années 90-00.
Avec la future version de Qt (4.7), vient un nouveau langage permettant de faire des interface graphiques digne des années 10: QML
L'idée c'est de pouvoir faire des interfaces graphiques animées et de manière déclarative très facilement. Suffisamment facilement que pour que un designer, qui n'a aucune idée de la programmation puisse réaliser de super interface qui en mettent plein la vue.
On peux voir quelques vidéos d'interface en QML sur youtube (beurk youtube!)
http://www.youtube.com/watch?v=xoo_Ows1ExU http://www.youtube.com/watch?v=WQkXdzMyGns
(ou recherchez Qt QML sur youtube)
QML veux dire originalement Qt Markup Language. Car au début c'était du XML. Mais XML c'était le buzz des années 00, et maintenant c'est dépassé. Les développeurs ont vu que XML c'est moche et pas pratique, alors ils ont inventé une super syntaxe innovatrice.
En gros, la syntaxe ressemble à du CSS, avec du Javascript dedans.
Le principe consiste a déclarer des éléments et à leur donner des propriétés. Il est aussi possible de déclarer des états, et des transitions entre ces différents états. Ce qui rends les interfaces dynamique. Il est possible de rajouter la logique grâce a du javascript. Et quand on arrive aux limite de ce que le
javascript peut faire, le reste de la logique peut être écrite en C++.
Exemple basique : http://doc.qt.nokia.com/4.7-snapshot/qml-tutorial3.html
Doc: http://doc.qt.nokia.com/4.7-snapshot/declarativeui.html
Le tout est pour le moment vraiment orienté pour l'embarqué (Nokia oblige). Et est conçu pour être super rapide.
Dans le milieux professionnel, les interfaces graphiques sont souvent désignées par des designers, sans compétences en programmation. Ils utilisent des technologie comme Flash pour faire des mockups qui sont alors fourni au programmeur qui doit refaire tout le travail pour implémenter le tout. Et souvent ce que le designer a produit n'est pas réellement possible en pratique ou est trop lent. Avec QML, le designer travail directement sur le résultat final de l'interface et voit directement ce qui est possible ou pas.
Qt QUICK (pour Qt User Interface Creation Kit) et le nom de code de l'intégration dans l'IDE Qt_Creator, qui, fourni un éditeur pour créé des interface à partir de la version 2.0.
Le tout est pour le moment disponible en version Beta:
http://qt.nokia.com/developer/qt-qtcreator-prerelease
http://labs.trolltech.com/blogs/2010/05/06/qt-470-beta1/
Vous pouvez donc essayer, et reporter des bugs. Ou tout simplement troller dans les commentaires.
[1] http://blog.qt.nokia.com/2010/03/25/developers-are-from-mars(...)
Journal QML: le futur des interfaces graphiques
13
mai
2010
# Une vraie question
Posté par Kerro . Évalué à 8.
Ce n'est pas pour troller mais... quelle est la différence entre l'exemple basique indiqué, et du "vrai" code ? Il y a autant de choses à apprendre, il y a autant de lignes à écrire.
Au final, celui capable de pondre le même exemple est capable de coder. Et je ne pense pas qu'il puisse en être autrement, sinon on aurait déjà trouvé :-)
[^] # Re: Une vraie question
Posté par Gof (site web personnel) . Évalué à 8.
On décrit juste ce que l'on veux.
C'est un peu comme du HTML, ce n'est pas de la programmation.
De plus, l'objectif est de pouvoir éditer ces documents avec un outils graphique (voir le screenshot de http://labs.trolltech.com/blogs/2010/05/06/qt-creator-and-be(...) )
[^] # Re: Une vraie question
Posté par Corentin Chary (site web personnel) . Évalué à 10.
[^] # Re: Une vraie question
Posté par sanao . Évalué à 3.
Pour avoir bidouiller un peu le truc, je trouve que le code généré par Quick est plutôt propre. Et puis par expérience, le Designer de Qt (celui qui fait des interfaces des années 90-00) génère du beau code (comprendre du code lisible par un Homo Sapiens). Que ce soit du C++ ou du XML.
Personnellement, je ne pense pas utiliser QML prochainement, mais je trouve que la façon "flashesque" de faire des interfaces qui en jêtent sans pourrir le code C++ derrière, ça peut être un plus dans certains cas d'utilisation. Et quand on regarde l'interface des smartphones aujourd'hui, je vois tout de suite au moins un de ces cas.
[^] # Re: Une vraie question
Posté par Kerro . Évalué à 3.
Une API correctement faite permet d'écrire exactement la même chose que l'exemple donné. Donc sans s'occuper d'algo, ni de mémoire, ni de pointeurs, etc. C'est probablement moins lisible pour des choses complexes, encore que.
En fait, là où je me pose vraiment la question, c'est qu'avec un "vrai" programme, on n'est pas limité. Alors qu'avec ce genre de langage, il n'est pas possible de sortir des limites pré-imposées. Si je souhaite faire quelque chose non prévue au départ... ben je ne peux pas. Alors qu'avec un programme, libre à moi d'apprendre à aller un peu plus loin.
Ceci dit, ça a l'air rudement pratique !
[^] # Re: Une vraie question
Posté par Gof (site web personnel) . Évalué à 8.
Et c'est là la force par rapport des technologies comme Flash, où dès que l'on atteint les limites de ce que l'actionscript peut faire, on est bloqué.
[^] # Re: Une vraie question
Posté par Antoine . Évalué à -5.
Pourquoi ne pas tout faire en Python plutôt ?
[^] # Re: Une vraie question
Posté par yellowiscool . Évalué à 10.
Puis le C++, c'est vraiment beaucoup mieux que le python.
Envoyé depuis mon lapin.
[^] # Re: Une vraie question
Posté par Albert_ . Évalué à 3.
Ouhaou le troll mais en fait non c'est trop gros ca peut pas passer.
[^] # Re: Une vraie question
Posté par yellowiscool . Évalué à 5.
Voici donc pourquoi je trouve le C++ beaucoup mieux que le python:
* Le python n'est pas un langage compilé, j'aime bien les langages compilés. Ça permet de faire des mini-pauses pendant la compilation, et on a pas d'erreurs bêtes qui arrivent au milieu du programme (par exemple, une concaténation entre un string et un nombre).
* Le python ne permet pas de gérer manuellement la mémoire. Le ramasse miettes, je n'accroche pas du tout. Surtout qu'avec une bonne architecture du programme, on ne rencontre pas beaucoup de problèmes de gestion mémoire en C++.
* Pas de typage explicite des variables. C'est super pénible de ne pas savoir quelle est le type de la variable que l'on a à gérer.
* Le self comme argument dans les méthodes de classes, c'est vraiment très très moche comme hack, et les messages d'erreurs sont faussés (quand il manque des arguments, le nombre d'arguments comprend le self, alors que l'on ne doit pas le préciser avec la syntaxe classique).
* On ne peut pas modifier un caractère d'une chaîne de caractère, obligé de faire une copie.
* Les exceptions pour les jeux de caractères, ça me gonfle.
* L'impression générale d'être limité à une utilisation en haut niveau.
* Puis l'indentation obligatoire, c'est super pénible. Surtout quand on reprends le code d'une autre personne, ou que l'on a juste commenté une condition.
Par contre, j'aime bien la facilité de la création de modules, les arguments nommés, toutes les librairies inclues de base (piles fournies©), et le cotés dynamique assez sympathique.
Envoyé depuis mon lapin.
[^] # Re: Une vraie question
Posté par Gof (site web personnel) . Évalué à 5.
Tu confonds compilation et typage statique. L'un n'implique pas l'autre.
[^] # Re: Une vraie question
Posté par yellowiscool . Évalué à 2.
Ce que j'aime bien dans les langages compilés sinon, c'est l'optimisation automatique du code (en python, on perd la documentation quand on veut optimiser). Gcc va vraiment plus optimiser, et même en fonction de l'architecture de la machine.
Avec un langage interprété, effectuer les mêmes optimisations serait possible, mais ce serait aussi bien trop lent à exécuter.
Envoyé depuis mon lapin.
[^] # Re: Une vraie question
Posté par Guillaum (site web personnel) . Évalué à 7.
pythoneux qui ne supporte pas que l'on dise du mal du meilleur langage du
monde (Lisez tout de même la suite avant de moincer, j'ai essayé de mettre des
arguments)
* Le python n'est pas un langage compilé, j'aime bien les langages
compilés. Ça permet de faire des mini-pauses pendant la compilation, et on a
pas d'erreurs bêtes qui arrivent au milieu du programme (par exemple, une
concaténation entre un string et un nombre).
Pour les minis pauses, je suis tellement d'accord. Sauf qu'ici au boulot c'est
des pauses de 30 minutes chaque fois que l'on change un commentaire dans le
fichier .h qui contient le template de base du système...
Sinon, pour le coté erreurs en pleins milieu, les autres l'on déjà dis, tu
confond la compilation et le tapage statique. Java est aussi un langage
interprété et pourtant tu as des erreurs au milieu du programme.
Mais en pratique en C++ tu as aussi des erreurs en milieu du programme que la
*compilation* ne réglera jamais. Par contre l'interpréteur peut être plus
malin que ton CPU en te renvoyant une erreur plus précise (genre unbound acces
en lieu et place de segfault). Mais j'avoue qu'avec une utilisation correcte
de la STL, tu n'as plus de segfault (enfin presque). Mais cette utilisation
correcte de la STL revient à rendre C++ aussi lent (enfin presque) que
Python...
* Le python ne permet pas de gérer manuellement la mémoire. Le ramasse
miettes, je n'accroche pas du tout. Surtout qu'avec une bonne architecture
du programme, on ne rencontre pas beaucoup de problèmes de gestion mémoire
en C++.
Chacun ses goûts. Je suis en grande partie d'accord avec toi quand je fais de
la programmation qui se doit d'être *vraiment* (cf plus loin) le plus rapide
possible.
Mais dans 99.9% des cas (chiffre au pif), quel est le besoin de gérer
l'allocation mémoire ? Tout le monde ici programme des fusées (Et encore, je
ne métrais pas de C++ dans les fusées), Tout le monde ici fait de la synthèse
d'image temps réel ? (Et encore, on peut en faire en python). Bon, donc sauf
si j'ai raté la dernière révolution, la plupart des code développés n'ont PAS
besoin de performances dingues, et n'ont PAS besoin de gestion fine de la
mémoire. Dans le cas particulier de l'article que l'on commente, l'on parle de
conception d'interfaces graphiques. Ici, 99.9% (chiffre au pif, certainement
surévalué) du temps CPU se passe dans le code du toolkit graphique et celui-ci
doit certainement faire une bonne partie des allocations mémoires (voirs peut
être 99.9% de celles-ci). Je connais mal Qt mais du peu que j'en ai fais en
C++, je ne me rappel pas avoir passé la moitié de la journée à faire des
malloc.
Et puis, tu dis aimer gérer toi même la mémoire, mais combien de personnes
utilisent une malloc alternative, combien de personnes surchargent le
paramètre alloc des templates de la STL ? Combien de personnes surchargent
l'opérateur new de la STL ? Si tu ne fais pas cela, alors tu ne peux pas
prétendre aimer gérer la mémoire.
De son coté, le GC de python, son job est de faire un malloc (si nécessaire)
quand tu crée un objet et nettoyer la mémoire (si il juge cela pertinent)
quand tu n'as plus besoin de cet objet. Alors oui, l'on ne maîtrise rien, mais
maitrise-t-on moins qu'avant ? Que faut-t-il craindre du GC de python ? Il
fait un travail fastidieux à notre place, en faisant moins d'erreur et
potentiellement plus rapide (du fait du pool de mémoire qui est réutilisé). Il
faut juste savoir l'utiliser correctement (ne rien faire) et si l'on veut une
utilisation avancé, il est aussi possible de l'utiliser de façon avancé (en
désactivant le GC de recherche de références cyclique et en ne laissant que le
compteur de référence qui ne consomme virtuellement rien)
* Pas de typage explicite des variables. C'est super pénible de ne pas savoir
quelle est le type de la variable que l'on a à gérer.
Goût et couleurs... Personnellement je ne m'intéresse pas à la variable ni à
son type, mais à ses capacités. Note que rien ne t'empêches en python de faire
du typage static.
Tu peux par exemple "décorer" tes arguments de fonctions:
def tortue(a:int, b:float)->float
Ensuite libre à qui veut de faire ce qu'il veut avec cela (je m'en sert pour
documenter les valeurs). Mais avec cela, tu n'as aucun problème pour faire de
la vérification de type au run-time, ou, un peu plus dur, écrire un
vérificateur de type statique. J'avoue, dans certains cas cela sera un peu
sioux ;)
Mais le problème ici, c'est que l'on s'en fout car l'on vois les types
de façon différente, plus comme une interface implicite :
Prenons un exemple. Tu est le gérant d'un bar. Un blanc entre dans le bar, tu
as prévu d'ouvrir le bar aux blancs, donc tu lui verses sa bière.
Un black (Il faut dire black pour être non raciste aujourd'hui) entre dans le
bar. Tu avais prévu que les blancs, mince. Comme t'es pas raciste, tu changes
ta porte d'entrée pour laisser passer les "buveurs", et tu demandes à tes
clients de se faire référencer comme buveur. Tu peux donc tout Homme se
présentant comme un buveur.
Un alien entre dans ton bar, et te demande à boire. Il n'a pas l'interface
buveur (son vaisseau vient de s'écraser devant ton bar, personne sur terre ne
connais l'existence de cette race d'arien, donc personne n'a pensé à le
rajouter dans le fichier des espèces qui boivent... Mais il a soif et te
montre de façon insistance avec sa tentacule la bouteille de bière. Pas
d'interface buveur, il ne bois pas. C'est ainsi que commencera la première
guerre universel (A lire, universal war one, très bonne BD sur ce sujet, enfin
presque).
Alors oui, on pourrait dire que c'est préférable de l'empêcher de boire si
l'on ne sait pas si il peut boire (imagine, il se trompe et cela le tue...).
C'est deux façon de voir les choses et je préfère rendre responsable les
développeurs que de rendre responsable le code. Le résultat étant le même à la
fin, soit c'est bon et cela passe, soit cela te pète à la gueule (au runtime
ou à la vérification statique). D'un coté tu t'es embêté à écrire du code
complexe, de l'autre t'as mis en place une procédure pour que cela pète au
runtime chez toi et pas chez le client (des tests par exemple). Comprendra qui
veut (Personnellement je préfère ne pas m'embêter en codant et écrire des
tests, parce que les tests, j'aurais honte de fournir du code au client qui
n'est pas testé... Donc entre écrire des tests et m'embêter en codant, ou juste
écrire des tests (et en plus sans m'embêter à les écrire...), le choix est
vite fait)
Le problème ici c'est que python ne manque pas d'une fonctionnalité de typage,
c'est juste une façon différente de voir les choses.
* Le self comme argument dans les méthodes de classes, c'est vraiment très
très moche comme hack, et les messages d'erreurs sont faussés (quand il
manque des arguments, le nombre d'arguments comprend le self, alors que l'on
ne doit pas le préciser avec la syntaxe classique).
Problème de goût et erreur de compréhension. Personnellement je trouve que le
this implicite en C++ c'est très moche comme hack (mon dieu, il vient d'où ?).
Après pour l'histoire du self, il n'y a pas de message d'erreur faussés, juste
une habitude que tu as pris d'ignorer dans le compte des arguments l'instance
concerné
toto.doit(5)
pour moi c'est une fonction (C.doit) qui prend deux arguments, toto et 5. C
sera dynamiquement déduit du type de toto (en l'occurrence, toto.doit(5) est
juste un raccourci syntaxique pour:
toto.__class__.doit(toto, 5)
avec toto.__class__ = C
Et là ou le système de type est intéressant, c'est que la classe C est finalement
juste un gros namespace de fonction travaillant sur des objets equivalents,
mais rien ne t'empeches de faire:
titi = B() # b n'a RIEN a voir avec C dans l'arbre d'héritage
C.doit(titi, 5)
En C++, on appelle cela les templates... En python on appelle cela le
dynamisme, mais en pratique les deux langages font la même chose...
Personnellement, je n'ai jamais compris pourquoi les autres langage ne
faisaient pas comme cela (pour le self/this). Et même avant que je connaisse
python, je ne comprenais pas. Quand j'ai découvert python, j'ai bondi de joie
au plafond en hurlant "Mon dieu, enfin des gens logiques qui pensent comme
moi"... Donc loin d'un hack immonde, c'est encore une fois un problème de
façon de voir les choses (même si le hack immonde, il faut être fou pour ne
pas se rendre compte qu'il est dans le langage C++ ;)
D'ailleurs, on va pousser un peu. Supposons une classe A et une
classe fille B ayant tout les deux une méthode "blork", Dans B.blork tu veux
appeler le A.blork sur l'instance courante...
En java tu utiliseras "inherited", bon, ok, java n'as pas d'héritage multiple
(en bien ou en mal), donc cela fonctionne très bien (je trouve cela juste
dommage d'introduire un nouveau mot clé dans le langage pour cela...)
En C++, tu utilises l'opérateur de portée de classe:
void B::blork()
{
A::blork();
}
Donc ici de façon implicite, A::blork est appelée avec le contexte. Mais si tu
utilises A::blork() en dehors de la classe B, et bien cela risque de ne pas
fonctionner non ?
En python tu verras simplement A.blork(self) que tu sois DANS l'instance le
code de la classe B ou en dehors (sauf que en dehors tu n'écrira pas de
variable nommée self ;)
Autre exemple. Tu écris une fonction qui travaille sur un objet de classe A,
et qui fait un truc
def mafonction(something):
assert(is_instance(something, A))
#dosomething with something
Note qu'ici je vérifie le type, pour le sport.
Puis après, tu obtient le pouvoir d'intégrer ta fonction au sein de la classe
A. Et bien tu n'as rien à changé, le prototype reste le même (faut renommer
self en something partout pour que cela soit joli, mais sinon c'est la même
chose).
Je ne parle pas de simplicité pour le refactoring ou autre hein (en C++ c'est
presque aussi simple en C++), je parle de cohérence. En C++ ce n'est pas du
tout la même chose, en python c'est toujours une fonction, il n'y à rien de
changé. En c++ il y a des namespaces, des classe, des fonctions, des méthodes
statiques, des méthodes d'instance. En python l'on fait la même chose
simplement avec des namespaces et des méthodes.
* On ne peut pas modifier un caractère d'une chaîne de caractère, obligé de
* faire une copie.
C'est un choix qui semble logique de mon coté. Une chaîne de caractère tient
sa valeur de son contenu, tu changes le contenu, tu changes la chaîne. Mais
sincèrement, on s'en cogne pas un peu ? Je crois que je n'ai jamais changé
un caractère dans une chaîne... A la limite plusieurs, mais cela change
complètement l'algo derrière, et j'avoue être plutôt heureux que python me
l'interdise ;)
Et si vraiment tu n'est pas content, libre à toi d'écrire un type
mutablestring basé sur les listes voir même sur les chaînes. Cela prend 5
minutes. Mais je n'en vois pas l'intérêt.
Les exceptions pour les jeux de caractères, ça me gonfle.
Précise ta remarque ? Les exceptions que j'ai eu en python étaient toutes liés
à une erreur de ma part. Une fois que tu as compris qu'il faut toujours
travailler en unicode (ou str dans python3), sauf pour les entrées sorties ou
tu converties en str (ou bytes dans python3) ou les traitements qui n'ont pas
de valeur de chaîne de caractère, il n'y a plus de problème.
On parlait tout a l'heure de vérification à la compilation, du fait que le
typage apportait un lot de sécurité, bla bla bla... Et bien ici python
t'apporte le fait que si tu fais des bêtises avec ta chaîne de caractère, il
te hurle dessus pour éviter que tu ne vois pas que la sortie est remplie de
petits '?', certes très jolis. Python est ici plus sécurisé que le C++, sans
être embêtant...
De toute façon ici l'on ne peut pas comparer avec C++, la lib standard C++ ne
gère pas l'un code, donc de toute façon tu n'aurais jamais eu ses erreurs en
C++, mais ce n'est pas forcement pour une bonne raison. C++ 0x apportera un
vrai support des chaînes de caractère, donc rassurez vous, cet argument en
faveur de python ne sera plus dans quelques années, à en juger par
l'implémentation du C99 sur les grands compilateurs du marché, au moins 10 ans ;)
L'impression générale d'être limité à une utilisation en haut niveau.
Précise ? Oui tu ne feras jamais un OS en python (et encore, cela pourrait
être marrant), mais quelles sont tes contraintes bas niveau ?
Personnellement je fais de l'OpenGL/Cuda/OpenCL tous les jours avec, et je
trouve que c'est suffisamment bas niveau...
Maintenant oui, j'accepte cet assertion, cependant revenons au débat sur Qt,
personnellement je m'en fout de toucher mes registres à la main, de faire du
(S/M)IMD, de gérer ma gestion de lignes de cache du CPU, de savoir comment mes
pages mémoires sont swapées. ON fait de la GUI là... On est en 2010, combien
de personnes, à part les gens qui font du système ou de l'image ont besoin
d'autant de bas niveau ?
Alors oui, quand j'ai besoin de bas niveau (mon dieu, il y a quoi dans mon
cache L2 !!!) Je fais du C (et du C++ quand vraiment je fais un gros truc et
que j'ai besoin d'une syntaxe objet plus légère que celles possibles en C),
mais quand je fais une gui, avec C++ j'ai "l'impression générale d'être limité
à une utilisation de bas niveau".
Puis l'indentation obligatoire, c'est super pénible. Surtout quand on
* reprends le code d'une autre personne, ou que l'on a juste commenté une
* condition.
C'est personnel. Moi je ne supporte plus les accolades et points virgules et
bien que j'ai plus d'années d'expériences en C/C++ que python, n'oublies
encore pleins de ;, mais je n'oublies jamais d'intenter mon code...
Quand j'enseigne la programmation à la fac ou en école d'ingé Je passe les 3/4
de mes séances C/C++/Pascal à rajouter des {};begin/end... J'ai la chance
d'avoir quelques groupes d'enseignement en Python, et bien je n'ai jamais* eu
de problème avec l'indentation et la syntaxe du langage.
* Une fois un élève qui à changé la configuration de son éditeur de texte pour
l'indentation et qui est passé soudain de 4 espaces à un tab... Un beau
bordel, j'avoue. Mais une fois ce détail connu pour une utilisateur averti,
il suffit d'un peu de rigueur (et d'un éditeur bien configuré) et ce problème
devient un souvenir.
Pour les commentaires de conditions, j'avoue, c'est peu pratique (enfin en C
tu est aussi forcé de supprimé les accolades ouvrantes et fermantes, sauf si
tu acceptes la déclaration d'un nouveau bloc, ce qui, j'avoue, à peu
d'implications, sauf si il reste encore le else après et là t'es eu...
Personnellement, j'ai une macro $EDITOR pour chercher le if le plus proche, et
cycler entre:
if condition:
#TODO if condition:
if True:
#TODO if condition:
if False:
Et elle est adaptée d'une macro pour le C que j'avais avant qui faisait la
même chose, car je n'ai pas trouvé mieux (je suis preneur).
Ce que j'aime bien dans les langages compilés sinon, c'est l'optimisation
automatique du code (en python, on perd la documentation quand on veut
optimiser). Gcc va vraiment plus optimiser, et même en fonction de
l'architecture de la machine.
Avec un langage interprété, effectuer les mêmes optimisations serait possible,
mais ce serait aussi bien trop lent à exécuter.
La suppression de documentation n'optimise pas plus, elle réduit seulement la
taille du fichier. Tu as deux flag en python, -O et -OO pour optimiser. -O ne
fait pas grand chose (principalement, il supprime les assert et la variable
__debug__) et -OO supprime la documentation. Si tu veux optimiser, python
n'est vraiment pas la bonne solution.
Et là je vais revenir sur le débat de la mémoire. ON s'en COGNE des
optimisations. On fait de la GUI ici hein, de la GUI ! Le truc pour lequel le
toolkit bouffe 99.9% de ton temps CPU pour dessiner des fenêtres à l'écran. Le
truc ou l'élément limitant en terme de performances et de réactivité c'est
l'utilisateur, la carte graphique, le serveur d'affichage et le toolkit.
Et puis pour la plupart on fait de la GUI qui affiche les
résultats qui sortent d'une BDD, le truc qui va prendre un temps de fou pour
revenir, parce que une BDD c'est des milliers de cycle CPU pour ramener une
petite donnée, c'est comme cela. Et on fait de la gui qui va lire et charger
des fichiers Image, qui va prendre quelques milliers de cycle CPU pour
décompresser le jpeg. Tout cela est déjà écrit et est lent, et sera toujours
plus lent que 10 appels de fonction dans python pour connecter ton évènement
clique de bouton sur la fonction de décompression de JPEG.
Alors oui, python prendra quelques cycles CPU de plus que C++ dans la boucle
principale, cycles qui sont négligeables à cote de ceux nécessaire au toolkit
pour afficher ta fenêtre. Alors OUI, je ne ferais jamais un toolkit en python,
ou une librairie de décompression JPEG, (et encore... faut voir ;)), mais
quand l'on parle d'utilisation de librairies qui existent déjà.
Et puis l'on parle d'optimisation et de C++, j'en rigole tous les jours. Du
fait des mécanismes d'héritage virtuel, les appels de fonction en C++ sont
lents et ne peuvent être inlinés (on parlait d'optimisation par le compilateur
?).
Alors OUI, python n'est pas parfait, Oui il a des défauts, le plus gros étant
qu'il ne code pas à ma place, ainsi je suis obligé d'aller au boulot et de
coder (parce que sinon je coderais à la maison pour le plaisir, ou je ferais
de l'escalade, ou je jouerais à Ryzom). Je vous demande juste une chose, ne
pas critiquer python sur des goûts personnels (l'indentation, le self, ...) ou
sur des fausses idées (python est lent. Oui, mais lent à quel point ?), mais
faites le sur des vrais points techniques, je peux en citer pleins :
- Python sucks en multithreadé à cause du GIL (cela se discute, mais globalement c'est vrai
pour les calculs cpu-bound)
- Déployer une application écrite en python c'est plus chiant qu'un bon gros
binaire Qt linké en statique. Sous windows un bon gros binaire Qt linké en
statique marche tout seul, alors que la même application en pytoolkit doit
contenir plusieurs fichiers, et il faut installer python, pytoolkit, toolkit
et dépendances du toolkit + pydependances du toolkit (ceux qui font du pygtk
doivent sourire en ce moment...). Bon, ca j'avoue que c'est super lourd...
- Python n'est pas un langage normé ISO (bon, celle-la me fait toujours rire,
mais peu avoir de la valeur), ceci impliquant aussi le prochain point,
- Python à au moins 6 implémentations différentes (Cython, UnladenSwallow,
Jython, IronPython, Pypi, Stackless), ayant toutes des différences de
comportement et de librairies, donc python n'est pas portable entre ses
différentes implémentations (bon, le C/C++ c'est pareil, hormis le C(++)
ansi sans utiliser la STL, c'est pas portable d'un compilo à un autre. C'est
encore plus vrai pour les libraries qui ne fonctionnent pas de la même
manière d'un système à un autre (Apple, quand tu packages !!!) et c'est la
plaie des systèmes de build (Mais ou est donc pkg-config sous Windows ?)
- Python sucks pour d'interfacer avec du C++ (alors qu'avec du C c'est très
simple) et cela parce que C++ sucks sur le name mangling et autres bêtises.
(Les symboles exportées par le compilateur peuvent être différents d'un
compilateur à l'autre. J'avoue que je ne sais pas exactement qu'elle est le
statut des normes à ce sujet)
Bon, je vais me coucher, vous pouvez moinser... A non, faut que je relise
l'orthographe avant... (et merde...)
[^] # TL;DR
Posté par Octabrain . Évalué à 0.
[^] # Re: TL;DR
Posté par Frank-N-Furter . Évalué à 1.
Depending on the time of day, the French go either way.
[^] # Re: TL;DR
Posté par Octabrain . Évalué à 2.
[^] # Re: TL;DR
Posté par Frank-N-Furter . Évalué à 2.
Depending on the time of day, the French go either way.
[^] # Re: TL;DR
Posté par Octabrain . Évalué à -2.
[^] # Re: TL;DR
Posté par Frank-N-Furter . Évalué à 4.
Moi, c’est plutôt les commentaires bien argumentés, mais n’allants pas dans mon sens que je préfère voir moinsés, je n’aime pas avoir a me remettre en question, mais heureusement c’est plutôt rare ici.
Depending on the time of day, the French go either way.
[^] # Re: TL;DR
Posté par Octabrain . Évalué à 2.
Tu oublies que je ne suis pas tout le monde :)
Moi, c’est plutôt les commentaires bien argumentés, mais n’allants pas dans mon sens que je préfère voir moinsés, je n’aime pas avoir a me remettre en question, mais heureusement c’est plutôt rare ici.
Oui, mais il n'empêche que devoir scroller si longtemps est pénible. Un message trop long convainc tout aussi mal qu'une argumentation nulle.
On va me parler de la toolbar, mais quand je lis, je ne suis pas forcément identifié au site, je n'ai pas les mains sur le clavier, et la toolbar ne permet de naviguer qu'entre les nouveaux commentaires.
[^] # Re: TL;DR
Posté par Frank-N-Furter . Évalué à 2.
En fait, je n’étais même pas au courant. J’ai été absent longtemps, et je ne connais pas toutes les nouvelles têtes /o\
Oui, mais il n'empêche que devoir scroller si longtemps est pénible.
Je n’ai pas de problèmes de scroll, je barre d’espaceise.
Depending on the time of day, the French go either way.
[^] # Re: TL;DR
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
[^] # Re: TL;DR
Posté par auve . Évalué à 2.
[^] # Re: TL;DR
Posté par Frank-N-Furter . Évalué à 2.
Depending on the time of day, the French go either way.
[^] # Re: TL;DR
Posté par Octabrain . Évalué à 0.
[^] # Re: TL;DR
Posté par yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
[^] # Re: TL;DR
Posté par Frank-N-Furter . Évalué à 2.
Depending on the time of day, the French go either way.
[^] # Re: TL;DR
Posté par Guillaum (site web personnel) . Évalué à 3.
[^] # Re: Une vraie question
Posté par yellowiscool . Évalué à 2.
Sinon, je trouve ton commentaire très intéressant, bien que l'on ne soit pas d'accord sur tout.
Alors, dans l'ordre:
30 minutes pour compiler un projet en C++, c'est un extreme. Je vois mal un tel projet en python (ou alors, faut aimer les lancements qui durent plusieurs minutes).
Si l'on utilise «correctement» la STL, en utilisant at au lieu de operator[] sur un vecteur par exemple, je ne pense pas que le C++ devienne presque aussi lent que le Python.
Si je me suis déjà amusé cette année (études) à remplacer les algorithmes de gestion mémoire par les miens, (et que j'ai constaté que malloc faisait beaucoup mieux son travail que mes algorithmes), je ne pense pas qu'il y ait besoin de programmer une fusée pour avoir besoin de gérer la mémoire. Je reste contre l'idée d'abandonner la gestion de la mémoire. Il suffit d'avoir une architecture organisée, et de réfléchir un peu à ce sujet, c'est tout.
J'avais lu un article d'un développeur sur ruby on rails, qui avait optimisé une partie du framework en s'occupant de la mémoire. Avec le ramasse miettes, ils ne s'étaient jamais occupés de la mémoire. En analysant les copies d'objets, il avait remarqué qu'un objet pouvait être copié plusieurs dizaines de fois par page. En changeant certaines petites portions du code, il a supprimé les copies, et il a amélioré les performances.
Et pourtant, ruby on rails, c'est pour des interface. Il y a une grosse base de données derrières, la latence du réseau, et tout le reste.
Sinon, je ne connaissais pas la décoration des arguments de fonction, je vais m'y mettre :-)
Pour l'exemple du bar, et le self, c'est des principes différents. Avant de commencer mes études, j'étais plus dans l'optique du python (je faisais du ruby), car c'est plus pratique. Mais maintenant, je vois que le C++ permet beaucoup plus facilement de travailler en entreprise.
Pour modifier une chaîne de caractère, ça m'est déjà arrivé, je ne sais plus pourquoi, donc on va dire que c'est rare.
Pour les exceptions des jeux de caractères, typiquement, j'attends une chaîne en utf8, de base en python3. Sauf que l'utilisateur me passe de l'iso-42, car il comprends rien. Se taper une exception pour ça me gonfle. Alors, à la place, j'utilise la librairie de base codecs, mais ça remplace les caractères non valides. Ça serait plus simple de stocker des caractères non valides. Si l'utilisateur passe de l'iso-42, il s'attend à avoir en retour de l'iso-42, pas un truc qui lui a bouffé tout ses accents.
L'impression que j'ai d'être limité à une utilisation en haut niveau, c'est psychologique. Sans aller jusqu'à programmer la carte graphique, j'aimerais bidouiller mes chaînes de caractères à coup d'opérateurs de bytes, pourvoir décharger les modules, ne pas penser que mes trois lignes de code sont 1000 fois plus lente que l'équivalent en 5 lignes de code en C++.
Si les mecs en école d'ingé. oublient des {}, je vois pas pourquoi ils n'oublieraient pas des espaces. Puis le ; oublié, en général, le compilateur l'informe assez clairement (à part celui après une struct ou une class, qui génère un lot d'erreurs qui n'ont rien à voir impressionnant).
En plus, ça permet de ré-indenter facilement, avec un outil tel que GNU indent.
Envoyé depuis mon lapin.
[^] # Re: Une vraie question
Posté par Gof (site web personnel) . Évalué à 2.
Le projet sur lequel je bosse prends bien plus de 30 minutes.
Heureusement, au bureau, on a une ferme de compilation, donc c'est beaucoup plus rapide.
Et on ne recompile pas l'entièreté du projet à chaque changement.
Sinon, si on n'aime pas les erreurs incomprhensible de GCC, il faut essayer clang:
http://fseek.me/2010/03/how-to-convince-any-c-developer-to-d(...)
http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-re(...)
[^] # Re: Une vraie question
Posté par Octabrain . Évalué à 1.
"warning: control reaches end of non-void function" -> "Also caused by the missing semicolon", pas trop non. Ça inspire confiance...
[^] # Re: Une vraie question
Posté par Guillaum (site web personnel) . Évalué à 0.
Agree pour boost python, c'est un peu fastidieux, mais cela fait le boulot (Mais je suis tellement fan de la simplicité de cytpes...)
Pour les 30 minutes de compilation, je suis d'accord c'est un cas extrême. Mais même 1 minute, quand t'es en pleine phase d'essais/erreurs, c'est trop. Après cela ne veut pas forcement dire que ton programme python prendra des heures à se lancer. L'import d'un module python qui sera utilisé N fois ne se fait qu'une fois. L'instanciation d'un template qui sera utilisé par N différents types par M différents fichiers .cpp se fait un nombre compris entre N et N*M fois.
Pour les [] versus .at() versus C/python, oui, j'avoue, en effet, at sera toujours plus rapide en C++ qu'en python, rien à dire la dessus. Ce que je voulais soulever c'est qu'a force d'ajouter des couches en C++ pour faire comme en Python (ou ruby, ou autre chose), cela à un cout de performance. Si l'on est près à payer ce cout de performance (qui n'est pas négligeable, je récite mon exemple sur les fonctions virtuelles qui pouvent détruire les performances d'un programme), pourquoi ne pas utiliser python (ou ruby, ou...).
Mon problème n'est pas forcement le C++, mais plutôt le mauvais usage de celui-ci. Il est vrai qu'il y a des cas particuliers qui nécessitent l'utilisation du C++ et je ne suis pas en guerre contre les gens qui ont fait ce choix de façon raisonnée, j'essaye plutôt d'ouvrir les yeux à ceux qui le font sans réfléchir, ou avec de faux arguments. C'est comme le débat Maya/Blender (ou Windows/Linux). Je n'ai rien contre celui qui utilise Maya parce que celui-ci est plus pratique pour certains cas de figure. J'ai quelque chose contre celui qui crache sur Blender en disant que Maya est mieux parce que c'est professionnel et puis de tout manière je m'en cogne, je le pirate.
Pour ton assertion "C++ plus facile pour travailler en entreprise". Je dirais que oui, sur un CV cela le fait mieux (par contre python ou ruby ça peut faire de toi l'élément qui se démarque dans la masse de +/- bon développeurs C++). Pour l'efficacité du travail, cela dépend à mon sens de savoir si tu bosses avec des gens compétents et avec de la rigueur ou pas ? Et je suis d'accord que quitte à faire des conneries, autant le faire avec un système à typage statique qui sera moins permissif. Maintenant, quand je bosse tout seul, je prend mes responsabilités et j'espère ne pas être mauvais. Et quand je m'entoure, j'essaye de m'entourer de gens compétents qui ne se laisseront pas avoir par le risque du typage dynamique et qui sauront profiter de ses avantages.
Pour ton problème d'encodage.
- Soit tu veux travailler sur des caractères et dans ce cas là il te faut faire une conversion et tu dois connaître le format d'entrée et de sortie (en l'imposant ou en demandant à l'utilisateur de le spécifier, si celui-ci ne suit pas cette règle, tu ne peux rien pour lui) et dans ce cas là rien ne t'empêches de convertir son iso-42 en unicode puis en iso-42 (en supposant qu'il existe une fonction de conversion ;)
- Soit tu n'as pas besoin de travailler sur les caractères, et tu peux travailler sur un bytes (le type python3 ~ char[]) et ainsi il n'y aura pas de caractère qui disparaît en sortie.
L'impression que j'ai d'être limité à une utilisation en haut niveau, c'est psychologique. Sans aller jusqu'à programmer la carte graphique, j'aimerais bidouiller mes chaînes de caractères à coup d'opérateurs de bytes, pourvoir décharger les modules, ne pas penser que mes trois lignes de code sont 1000 fois plus lente que l'équivalent en 5 lignes de code en C++.
- Tu peux bidouiller tes chaînes à coup d'opérateurs de bit, après il faut voir si cela à un sens (sur une chaîne char[], certainement, et encore je ne vois pas grand chose à faire de plus que le changement de case avec ^ (1 << 5))
- Tu peux décharger des modules, après faut voir si cela à un sens
- Tu peux faire de la programmation de carte graphique en Python ;)
- Tu peux aussi te demander en C++ si les 30 lignes que tu as écris seront aussi rapide que du Python (Je pense par exemple au hashmap qui n'existent pas dans la STL). Je joue souvent un jeu marrant avec mes collègues, élèves ou autre qui me disent que python est lent, je leur demande de me fournir un bout de code C++ qui est selon eux rapide et un bout de code python qui est selon eux lent. Très souvent je peux récrire leur bout de python pour qu'il soit plus rapide que leur bout de C++ (bon, je peux aussi récrire le bout de C++ pour qu'il soit plus rapide que le bout de Python ;)
Si les mecs en école d'ingé. oublient des {}, je vois pas pourquoi ils n'oublieraient pas des espaces.
Je me demande aussi, mais figure toi que j'ai aussi ce problème. Je ne fais presque jamais d'erreur de syntaxe en Python, je passe mon temps à en faire en C++... Mais je suis certainement biaisé en C++ du fait de mon expérience python. (Enfin j'ai fais plus de C++ dans ma vie que de python...)
En plus, ça permet de ré-indenter facilement, avec un outil tel que GNU indent.
Ça c'est (à mon avis) un faux argument. Pourquoi ré-indenter ? Cela signifie que ton indentation n'a qu'une valeur cosmétique, donc cela ne sert a rien d'indenter. Si cela ne sert a rien, pourquoi le faire non ? Donc cela sert à quelque chose. Donc il faut indenter, et tous indenter de la même manière au sein d'un projet, donc l'indentation a un sens ? Tient, ce sens est vraiment proche des blocs que je délimite par des {} et ;. C'est meme tellement proche que je me demande pourquoi je duplique l'information... En fait l'indentation significative : "ça permet de remettre facilement les {}; avec un outil tel que GNU jemetlesaccollades"
[^] # Re: Une vraie question
Posté par Gof (site web personnel) . Évalué à 2.
[^] # Re: Une vraie question
Posté par yellowiscool . Évalué à 3.
operator[] lui, il ne vérifie rien, comme en C. Dans le meilleur des cas, tu as un signal pour une erreur de segmentation. Dans le pire des cas, t'en a pas, et ça fait foirer complètement ton programme.
operator[] est beaucoup plus performant, mais plus dangereux. Mais c'est sympa les erreurs de segmentation :-)
Envoyé depuis mon lapin.
[^] # Re: Une vraie question
Posté par Gof (site web personnel) . Évalué à 4.
QML utilise ECMAScript, qui est déjà intégré avec Qt depuis longtemps. Donc on a déjà un langage de script.
Et comme c'est prévu pour l'embarqué, les limites des langages de script sont les performances, l'utilisation de la batterie, ...
Donc associer avec un langage compilé comme le C++ c'est du bonheur.
Mais si tu veux quand même faire du Python, pas de problème, il existe des bindings Python.
[^] # Un début de réponse
Posté par Erus_Iluvatar . Évalué à 1.
En lisant un peu vite, j'ai lu EMACScript :Ð
[^] # Re: Un début de réponse
Posté par Maclag . Évalué à 2.
# Une impression de déjà vu
Posté par alice . Évalué à 7.
[^] # Re: Une impression de déjà vu
Posté par thedidouille . Évalué à 4.
Puis il y a déjà un IDE qui à l'air de bien fonctionner, avec des vidéos sur Youtube. Donc c'est plusse top.
# Edje
Posté par hsyl20 (site web personnel) . Évalué à 8.
http://trac.enlightenment.org/e/wiki/Edje
[^] # Re: Edje
Posté par Albert_ . Évalué à 7.
[^] # Re: Edje
Posté par Fanf (site web personnel) . Évalué à 3.
Alors peut être que l'erreur de la team E17 est de ne pas avoir voulu estampillé 4^1.0 une version qui n'était pas complète, ou tout au moins pas utilisable simplement par des utilisateurs non avertis, mais c'est un autre débat.
Bon, ceci étant dit, je suis plutôt content que KDE reprennent les idées de E17 - après tout, si j'utilise ce dernier, c'est bien parce que j'aime bien leur approche.
[^] # Re: Edje
Posté par imr . Évalué à 7.
C'est soit que tu ignores, soit que tu écarte le fait qu'on avait essayé une version compilable en 2000 ou 2001 (il y avait eu un article spécial dans linux mag genre le windows manager du futur arrive), que ça faisait alors déjà plusieurs années qu'on attendait la relève de e16, que rasterman n'avait pas été vraiment discret sur les promesses faites à propos de son bébé, que le développement s'est ensuite stoppé après que rasterman soit parti, puis qu'il soit revenu ensuite. Bref, entre dallas et enlightenment forever. etc
Donc super que ça marche, mais tu n'empêcheras jamais que pas mal de gens ont vécu ça, s'en souvienne et du coup n'arrive pas à percevoir e17 autrement que comme un vaporware.
C'est comme ça que les réputations se font indépendamment des qualités ou de l'état réels du projet. C'est malheureux mais il ne faut pas aller contre, parce que c'est inutile, il faut simplement lister les qualités et l'état du projet avec acharnement en attendant patiemment que ça finisse par rentrer dans la tête de ceux qui écoutent. Parfois en vain.
[^] # Re: Edje
Posté par NickNolte . Évalué à 2.
Tu l'utiliserais depuis 2004 mais il n'est toujours pas disponible officiellement, c'est qu'il y a un soucis, non?
Qu'est-ce qu'ils les empêchent de remplacer une bonne fois pour tout le vieillissant e16?
[^] # Re: Edje
Posté par Batchyx . Évalué à 0.
[^] # Re: Edje
Posté par B16F4RV4RD1N . Évalué à 7.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Edje
Posté par Raoul Hecky (site web personnel) . Évalué à 1.
http://trac.enlightenment.org/e/browser/trunk/editje
Pour info QML s'appelait QEdje a ses debut...
[^] # Re: Edje
Posté par gemegik . Évalué à 2.
Je ne pense pas. QEdje est un interpréteur Edje pour Qt, et n'a aucun lien de parenté avec QML (à part le concept, partagé aussi avec Clutter du côté Gtk).
http://code.openbossa.org/projects/qedje
[^] # Re: Edje
Posté par Gof (site web personnel) . Évalué à 2.
Le but de QEdje était d'essayé d'intégrer Edje dans Qt. Mais c'est difficile car Edje utilise son propre canevas.
QML est dès le départ prévu pour fonctionner avec Qt, et les éléments sont des QObject et ça utilise le méchanisme des propriété de Qt.
Et Qt peut utiliser l'accélération OpenGL/OpenVG/... alors que le canevas de Edje est purement software il me semble.
[^] # Re: Edje
Posté par cedric . Évalué à 4.
Edje est concu pour etre sandboxable et propose une vrai separation de la logique applicative du design de l'interface. L'objectif etant de n'avoir qu'a change le theme quand tu changes de terminal (telephone, netbook, tablet, ...).
QML au contraire, permet de quasiment coder toute ton application dedans. Ca lui permet de faire beaucoup plus de chose avec un seul langage, mais cela a un prix. Prix en terme de modularite, de fonctionnalite et de performance.
Sinon pour ce qui est de Edje, et de l'acceleration hardware. Edje utilise le canvas propose par Evas qui va utiliser divers backend parmis le moteur purement soft, directfb, sdl, opengl et opengl-es. Il est vrai que le backend soft est tres performant, et tiens souvent la drage haute au backend gl.
Pour diverse raison, entre autre que le backend soft est plus intelligent en consommant moins de bande passante. OpenGL n'est pas adapte a faire des interfaces 2D, car il force a redessiner tout l'ecran et donc necessite un fillrate plus eleve. Apres lorsqu'on a besoin du CPU principal pour autre chose que l'affichage, ce qui est souvent le cas dans l'embarque, on va bien entendu utiliser les moteurs accelerer par des puces dedies. Donc OpenGL n'est pas la panace absolu qui rendra vos interfaces belles et fluides. Juste une solution qui marche pour ameliorer des fois les choses.
[^] # Re: Edje
Posté par Gof (site web personnel) . Évalué à 2.
> de realiser QEdje qui ont participe a la creation de QML.
QEdje était réalisé par OpenBossa, au brésil.
QML est principalement développé par des anciens dev de Qtopia, en Australie.
Mais c'est vrai que on peu voir sur le blog du dev de QEdje que il fais des truc en QML maintenant [http://blog.morpheuz.cc/]
# sapueplus?
Posté par Frank-N-Furter . Évalué à -8.
Depending on the time of day, the French go either way.
[^] # Re: sapueplus?
Posté par Corentin Chary (site web personnel) . Évalué à 8.
D'ailleurs si ceux que ça intéresse une file de priorité en Qt, allez le dire sur http://qt.gitorious.org/qt/qt/merge_requests/2368 :)
[^] # On n'est plus en 1995
Posté par gemegik . Évalué à 5.
openSuse est libre aussi [yast a été libéré, voir http://fr.opensuse.org/YaST] et, pour l'avoir testée la semaine dernière, gère pas mal
Cela fait longtemps que Mandriva évolue indépendamment de RH (je dirai depuis les versions 7.x ou 8.x, autant dire le millénaire dernier). Si tu veux une RH maquillée, regarde du côté de CentOS.
On est en 2010 monsieur, il faudrait se mettre à jour un peu :)
[^] # Re: sapueplus?
Posté par Maclag . Évalué à 6.
[^] # Re: sapueplus?
Posté par feth . Évalué à 4.
[^] # Re: sapueplus?
Posté par Frank-N-Furter . Évalué à 6.
Depending on the time of day, the French go either way.
[^] # Re: sapueplus?
Posté par Thomas Douillard . Évalué à 3.
Messieurs/dames les moinsseurs, je ne vous salue point.
[^] # Re: sapueplus?
Posté par Frank-N-Furter . Évalué à 2.
PS:Et tu te fais vieux :)
Depending on the time of day, the French go either way.
# Salut, j'ai vraiment bien aimé cette démonstration
Posté par dave . Évalué à 0.
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: Salut, j'ai vraiment bien aimé cette démonstration
Posté par GnunuX (site web personnel) . Évalué à 10.
On peut faire tourner une horloge (voire 1 et 1/2) sur un ARM 200mhz !
[^] # Re: Salut, j'ai vraiment bien aimé cette démonstration
Posté par yellowiscool . Évalué à 6.
Envoyé depuis mon lapin.
[^] # Re: Salut, j'ai vraiment bien aimé cette démonstration
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Salut, j'ai vraiment bien aimé cette démonstration
Posté par gnumdk (site web personnel) . Évalué à 4.
[^] # Re: Salut, j'ai vraiment bien aimé cette démonstration
Posté par Antoine . Évalué à 4.
(j'imagine qu'avec une accélération matérielle on pourrait l'afficher en entier)
[^] # Re: Salut, j'ai vraiment bien aimé cette démonstration
Posté par Christophe Merlet (site web personnel) . Évalué à 8.
Quand je pense qu'a mon époque un processeur 4bits suffisait pour afficher l'heure !!
[^] # Re: Salut, j'ai vraiment bien aimé cette démonstration
Posté par thedidouille . Évalué à 2.
[^] # Re: Salut, j'ai vraiment bien aimé cette démonstration
Posté par yellowiscool . Évalué à 2.
Envoyé depuis mon lapin.
[^] # Re: Salut, j'ai vraiment bien aimé cette démonstration
Posté par Christophe Merlet (site web personnel) . Évalué à 5.
'fin, heureusement que les processeurs 64bits sont arrivés, on peut enfin faire des calculs de plus de 4 milliards....
Rassure moi, tu n'es pas informaticien ?
# XML
Posté par NickNolte . Évalué à 2.
QML veux dire originalement Qt Markup Language. Car au début c'était du XML. Mais XML c'était le buzz des années 00, et maintenant c'est dépassé. Les développeurs ont vu que XML c'est moche et pas pratique, alors ils ont inventé une super syntaxe innovatrice.Ils ont peut-être compris que le XML n'a jamais été conçu à cette fin?
À lire à ce sujet un excellent billet - encore - de JP Troll dans le LinuxMagazine de ce mois ci!
# Zut ! Ils ont eu la même idée que moi
Posté par Ontologia (site web personnel) . Évalué à 4.
Quand on regarde bien, une interface utilisateur nécessite un automate à état pour fonctionner, je dirai même un automate à état hiérarchique (ie. des états peuvent contenir des machines à états), c'est le système le plus naturel, plutôt que gérer des callback.
Couplé aux système slots, c'est génial !
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Programmation d'interfaces graphiques déclaratives ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 1.
Le jour où tu veux ajouter un nouveau mode de fonctionnement de ton application qui présente un contenu complètement différent, ça évolue bien QML ? Il suffit de faire une fabrique et d'instancier le nouveau contenu au lieu de l'ancien ? Exemple : je fais un browser de fichiers musicaux, ma première version permet de naviguer dans mes fichiers MP3 et d'afficher les tags ; puis un jour je décide de gérer aussi les OGG (tout en affichant les tags spécifiques) et je veux également proposer une interface de modification des tags et un lecteur audio. Ca se fait bien ? (je parle pas d'ajouter un bouton dans la barre d'outils, hein, je parle d'instancier un "widget" mp3 ou ogg ou je sais pas quoi avec une logique potentiellement tout à fait différente).
Je suis relativement sceptique sur les interfaces déclaratives (sauf pour des applications relativement simples). Ok on peut scripter l'interface en ECMAScript et faire le reste en C++. Mais un code dont l'intelligence est éclatée dans différents languages et différentes logiques est difficile à maintenir. Donc pour moi l'idée "on fait du ECMAScript et si ça on atteint les limites on code ça en C++" c'est une mauvaise idée. A la limite si on décide "telle intelligence en ECMA, et telle autre en C++" ça a une logique...
[^] # Re: Programmation d'interfaces graphiques déclaratives ?
Posté par Gof (site web personnel) . Évalué à 3.
Qt est aussi pas mal utilisé dans l'industrie du cinéma.
http://qt.nokia.com/qt-in-use/qt-in-visual-effects
Le future Maya 2011 est fait avec Qt.
Maintenant, ils ont peut-être tous tord, et tous choisis une technologie inadaptée.
QML est basé sur QGraphicsView, donc pas de changement.
En théorie, la séparation devrais se faire entre QML pour l'interface graphique, et C++ pour la logique. (Mais biensur on est libre de faire un peu de logique en javascript dans QML quand c'est adapté.)
Sinon pour ton problème de mp3 et ogg : oui, il est facile d'instancier des composant différent.
[^] # Re: Programmation d'interfaces graphiques déclaratives ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: Programmation d'interfaces graphiques déclaratives ?
Posté par Gof (site web personnel) . Évalué à 2.
Qt Creator est un IDE (qui intègre Qt Designer).
Et je n'ai que brièvement essayer le nouveau designer de QML, donc je ne sais pas répondre à ta question.
[^] # Re: Programmation d'interfaces graphiques déclaratives ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 1.
# vendredi
Posté par Octabrain . Évalué à 2.
Après avoir vu les vidéos d'exemple, et tout le monde se réjouir, je ne peux qu'être perplexe : sur DLFP, on voit souvent les gens se révolter quand chaque programme utilise son propre skin, plutôt que laisser le système (+ la config de l'utilisateur) tracer l'interface. Or c'est précisément ce que montre les vidéos de QML : aucune démo ne se ressemble.
Bientôt, ça ressemblera à ça : http://sam.zoy.org/writings/dvd/players/
[^] # Re: vendredi
Posté par Gof (site web personnel) . Évalué à 3.
Mais c'est plus ciblé pour l'embarqué, dans lequel on a juste un interface plein écran. Et chaque appli a son propre style.
Mais je regrete également l'absence de style dans QML, alors que les widgets "normaux" de Qt sont si facile à intégrer dans les différents OS/bureaux.
Ce sera peut-être pour une prochaine version.
[^] # Re: vendredi
Posté par Octabrain . Évalué à 2.
[^] # Re: vendredi
Posté par Gof (site web personnel) . Évalué à 3.
La différence entre les deux est que "Embedded Linux" utilise le frame buffer, et un système de gestion des fenêtres spécifique.
Mais beaucoup de platformes dite embaquées (comme Maemo, Meego, openmoko, ...) utilisent quand même X11 (pour la compatibilité avec Gtk), donc c'est le port X11 de Qt qui est utilisé.
Il y avais aussi Qtopia, renommé plus tard Qt Extended, qui était une solution applicative complète pour smartphone (chinois). Mais Nokia n'a pas continué le développement de cette platforme après le rachat de Trolltech. Une partie du code est néenmoins réutilisé dans le projet Qt Mobility.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.