Olivier Serve a écrit 854 commentaires

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.

Du coup il faudrait ensuite une plateforme d'échange de pages (J'échange 2 pages 3 contre une 10 et une 27).

http://lemonldap-ng.org/documentation

Je ne comprend pas pourquoi se limiter a OpenGL <=2 alors que OpenGL 4 est supporté depuis bien longtemps par tout le monde

Genre Mesa (donc pilotes intel, AMD & nVidia libres) qui ne gère pas encore OpenGL 3.2…

Pascal ?

D'ailleurs, on devrait coller des caméras dans les maisons de ceux qui sont d'accord avec cet argument, dans toutes les pièces. Toutes ? Toutes ! Et avec diffusion publique sur Internet 24h/24, 7j/7. Et interdiction de les obstruer.

Après tout, ils n'ont rien à cacher.

Je trouve ce comportement absolument égoïste. Si un membre de ta famille refusait de te recevoir tant que tu ne portes pas un kilt, tu crois que tu t'y plierai ?

Un kilt n'impose pas l'acceptation d'une licence d'utilisation.

Et y a rien de magique, suffit juste d'un serveur et d'un script.

Ensuite, peut etre que personne dans la communauté arch n'a de temps pour faire de la QA automatique, ce qui est triste.

Puisque c'est si facile, je pense qu'ils seront enchantés de ta participation.

Il faut comprendre que nVidia est un acteur passif et qui ne fournit des efforts qu'après que le reste de la communauté ait stabilisé les choses (et encore on attend toujours KMS…).

Ça vient de qui déjà le GLX_EXT_texture_from_pixmap qui a remplacé les hacks assez sales nécessaires à Xgl ?

Pour KMS, il serait peut-être utilisable si certains dévs noyau n'en bloquent pas l'utilisation aux pilotes propriétaires.

Si, même qu'ils ont une infrastructure gigantesque avec toutes les configs possibles et sont payés des sommes mirifiques. C'est une honte, vraiment !

On n'a pas dit que c'était impossible.

Seulement les solutions autres que moc passent par un objet « signal ». De ce fait, les signaux ont une existence au niveau de l'ABI. Changer les signaux implique donc de casser la compatibilité binaire. Or, c'est inacceptable pour Qt. Ce n'est pas pour rien que toute la bibliothèque utilise le principe du d-pointer.

Une application compilée avec Qt4.0 fonctionne telle quelle avec Qt 4.8 là où une recompilation est nécessaire entre boost 1.41 et 1.42, 1.43 / 1.44 et 1.44 / 1.45 par exemple.
À choisir, je préfère largement la politique de Qt qui évite d'avoir 4 versions différentes de la même bibliothèque parce que chaque application utilise une version différente.

Oui, c'est très clair : Boost ne sait pas faire tout ce que permet moc.

Tu peux lire la doc pour plus de détails, mais j'ai donné l'exemple de boost pour montrer qu'il était parfaitement possible de gérer les signals/slots sans se taper un précompilateur.

Oui, c'est possible. Mais avec des restrictions par rapport à moc qui font que ce n'est pas utilisable (compatibilité toussa).

Idem pour l'introspection, il existe des solutions à base de macros (que même Qt utilise d'ailleurs).

Oui, il existe des solutions. Mais qui ne remplacent pas complètement ce que fait moc.

Oui, oui, Boost sait faire.

Sauf que Qt a des exigences supplémentaires comme pouvoir ajouter des signaux à une classe existante sans casser la compatibilité binaire. Et ça, c'est impossible avec boost.

WebKit a du succès parce qu'il répond à un besoin : avoir un moteur HTML efficace et facilement intégrable (niveau doc, technique, juridique et coût). Et il est le seul.

Si la Fondation Mozilla s'était sorti les doigts et avait vraiment promu Gecko dans une optique d'intégration, on n'en serait pas là.

À partir de là, soit Mozilla continue sur sa lancée, et ça ne fera que renforcer WebKit, soit un effort est porté sur l'intégration de Gecko et il est peut-être possible de remonter.

C'est peut-être regrettable, mais je ne vois pas comment on pourrait reprocher le choix de WebKit comme moteur aujourd'hui.

Ça risque de mettre encore plus un sacré coup à Gecko qui perds déjà pas mal de parts de marché face à WebKit…

Certes mais à qui la faute ?
C'est dommage, mais c'est la conséquence directe d'un choix stratégique de la Fondation Mozilla. Elle n'a pas su anticiper la banalisation de l'emploi (et donc le besoin) d'un moteur HTML. En refusant d'investir dans « l'intégrabilité » de Gecko, elle a voulu garder son bébé pour elle-même. Du coup les gens vont voir ailleurs, comment le leur reprocher ?

Clic-droit sur la barre de titre > Agencements.

Je m'en sers beaucoup pour séparer mes projets en cours au boulot. J'ai une activité générale (mail notamment) plus une par projet. Ça permet de passer rapidement d'un contexte à l'autre tout en conservant deux bureaux virtuels par activité.

J'étais réticent au début (aussi parce que ce n'était pas très stable) mais j'aurais maintenant du mal à m'en passer.

Prochaine évolution que j'attends avec impatience : gestion des panels par activité. Afin d'éviter d'avoir des raccourcis inutiles dans une activité.

Ou, encore mieux, pouvoir tagger les applications par une ou des activités et que le gestionnaire de tâches à icônes s'adapte automatiquement (et réciproquement : si je place une application dans le gestionnaire, l'appli est taggée avec l'activité en cours).

C'est aussi l'avis des développeurs Qt. Et c'est pour ça que les API actuelles existent toujours dans Qt5. QML vient comme une possibilité supplémentaire, pas comme une obligation.

Le bureau KDE (plasma) migre vers QML car cela résoud certaines limitations de la techno actuelle. Mais il s'agit là uniquement du bureau. Les applications KDE peuvent parfaitement rester en QWidgets / QGraphicsView.

Ta mémoire te joue des tours :-)

La nature déclarative de QML le rend facile à accélérer par un backend OpenGL contrairement aux QWidgets (qui incluent l'algo de rendu dans leur code). Mais QML peut parfairement fonctionner sans OpenGL. Depuis l'apparition de QtQuick (Qt4.7) c'est le moteur de rendu raster qui est utilisé par défaut.

Il était (je n'ai pas vérifié) par contre prévu de passer sur le backend OpenGL par défaut dans Qt5. Mais KDE n'en est pas encore là.

Peut être, mais c'est la troisième fois que Qt refonds son API graphique en 10 ans. Ça peut paraître long, mais pour de grosses applications qui durent, ça prends un temps et un budget de développement qu'il est très difficile de justifier.

Il faut relativiser un peu quand même.

Qt4 était voulu comme une révolution nécessaire afin de pouvoir mieux évoluer en douceur par la suite. Donc ça a beaucoup cassé, certes. Cependant, la doc de migration était là et des classes de transition qt3support disponibles.
De plus, l'API de QGraphicsView était calquée sur celle de QCanvas pour faciliter la migration. Enfin, celle des QWidgets (quand même plus utilisée que QCanvas) a assez peu bougé.

Les API QWidget et QGraphicsView sont toujours présentes dans Qt5. Il n'est donc pas nécessaire de tout réécrire en QML.
QML/QtQuick2 vient en plus et non en remplacement (même si la migration est encouragée).

La vraie refonte dans la pile graphique de Qt5 vient de QPA mais c'est un changement invisible.

On a eu le débat ici lors de la sortie de Tk qui a beaucoup vieilli, mais qui reste compatible et maintenu au travers des âges.

Et que plus personne n'a envie d'utiliser pour de nouveaux développements, donc condamné.

Non, non, tu n'es pas le seul :-)

On avait un processus qui était simple a départ et qui de verrue en verrue était devenu une sorte de Shoggoth immonde qu'on n'avait pas envie de toucher.
Et un jour, après avoir lu un tutoriel OpenGL (qui est, à la base, une machine à états) j'ai eu une révélation : en fait, on pouvait parfaitement recoder notre monstre en machine à états toute simple.
Ça a été un peu de boulot pour éviter les régressions, mais au final le résultat est maintenant beaucoup plus petit. On sait clairement ce que fait chaque étape et quel est l'état du "dossier" en cours. Et ajouter des étapes intermédiaires n'est plus un calvaire.

Ce n'est pas une solution magique, dans le sens où rien n'empêche d'avoir un état qui fait n'importe quoi. Mais c'est une aide pour organiser et maintenir les choses sous contrôle.

Est-ce que ces évolutions sont justifiées? Entre QCanvas, QGraphicView et QML, je ne saurais dire quel est/était le meilleur…

Il y a une logique derrière cette évolution. Évolution des possibilités techniques et des besoins.

QCanvas, c'était Qt3.
QGraphicsView est arrivé avec Qt4.2 comme une amélioration de QCanvas (et avec une API similaire). QGV profitait des évolutions du moteur d'affichage ainsi que d'optimisations sur la conso mémoire et la vitesse d'affichage.
QML est un changement d'orientation.

Il faut voir en parallèle l'évolution de la construction d'interfaces :
- en dur dans le code au début ;
- puis avec des fichiers de description "statiques" (.ui, XML mon amour) ;
- enfin, gestion des états/transitions des interfaces.

Au final si je dois faire un rendu, je prendrais plutôt opengl qui bien que plus primitif a l'avantage de rester rétrocompatible sur plusieurs décennies.

Comme ça, direct en OpenGL, sans rien au-dessus ? Avec chaque appli qui recode son truc dans son coin ? Et si OpenGL n'est pas disponible ?

Sachant qu'en plus, tout n'est pas réécrit, seulement la couche d'interface.

Les DataEngines et Services qui contiennent la logique des composants (et sont partagés entre eux) ne changent pas.

Ça tourne en rond parce que tu te focalises sur des bugs corrigés depuis 6 mois.