Larry Cow a écrit 5011 commentaires

Nanan, je dis pas. Mais la particularité de D contre G, c'est que D gagne contre toute attente. Donc mauvais exemple, si je puis me permettre ;)

(note: D et G représentent David et Goliath... toute autre interprétation serait à la responsabilité du lecteur)

C'est plus compliqué que ça. Il n'y a jamais vraiment eu de lien entre WM et GS. Fut un temps, certains des développeurs ont du envisager d'utiliser l'un avec l'autre, d'où le ~/GNUstep si curieux de WindowMaker. Mais les formats utilisés par WM dans ce fameux répertoire et ceux utilisés par GS n'ont que peu à voir.

Quant à l'idée d'avoir un window-manager propre à GS, elle est plus ancienne qu'étoilé, est passée par différents stades (reprises d'un *box, écriture from scratch, etc), mais en tous cas il a toujours été question d'un WM en ObjC et intégré aux technos GS (et pas seulement avec une trombine similaire, contrairement à WM).

Le panneau de contrôle de WM n'a jamais contrôlé autre chose que WM, d'ailleurs, et n'a pas eu vocation à mieux. Ceci dit, si le look WMaker te plaît tant que ça, tu peux toujours essayer le "vrai" GNUstep, c'est plutôt sympa aussi :)

Attention de ne pas mélanger : GNUstep (et du même coup étoilé, qui se base dessus) n'ont rien d'autre à voir WMaker que le look (et encore, pas tellement pour étoilé). La confusion vient de l'inspiration commune à ces deux projets (NeXTstep) et surtout du fait que pendant longtemps, GNUstep s'utilisait de concert avec WM, n'ayant pas lui-même de fonctionnalités de gestion de fenêtres.

Mais autant GNUstep s'inspire de NeXTstep (puis d'Openstep, puis de Cocoa) sur le fond (langage utilisé, structure du code, interfaces, etc.), autant WM n'en reste qu'à la partie "graphique" pour le mimétisme.

Ce qui nous fait deux.

c'est un peu David contre Goliath, et David se battant avec une épée de moins bonne qualité que Goliath.

Revois tes classiques : David a laminé Goliath _sans_ épée du tout (mais avec une fronde et des appuis hauts placés, certes).

(l'auteur se rattrape en disant que Dirac prendra la relève, possible pour la HD, j'ai plus de doute sur un iPhone...)

En même temps, la HD sur un iPhone...

La confusion vient de certaines "licences" non-libres qui spécifient "free (as in beer) for non-commercial use". Je pense notamment aux versions gratuites d'antivirus. Ici, c'est à comprendre comme "hors du cercle du famille", en gros.

Par contre, les licences libres dans l'ensemble ne spécifient rien qui concerne le "commerce" au sens strict. Les offres de licences non-libres des partisans de la double-licence sont assez facilement intitulées "entreprise" ou "commerciale". Mais il n'empêche que rien, dans les licences libres qui leur sont adjointes, n'interdit de les utiliser dans un cadre professionnel. Simplement, effectivement, si on vend un produit basé dessus, on respecte la règle et on fournit les sources avec.

* également dans le même post : il encence les système de paquets, mais il critique l'enfer des dépendances... encore une contradiction,

Peut-être parce que les systèmes de paquets sont une réponse à ce fameux 'enfer des dépendances' (aka "si je veux installer A, il faut que je cherche les librairies dont A dépend, etc."). Avec un (vrai) système de gestion de paquets, tout ceci est automatique.

Bon ben apparemment, si. Damned :)

Il s'intègre très bien dans le process, dès lors que tu acceptes des outils externes et non-standards comme qmake (lequel te génère un joli Makefile tout bien comme il faut qui prendra en compte les appels au MOC, ou bien un joli projet XCode si tu es sur Mac, etc.)

Sinon effectivement, si tu tiens absolument à construire ton projet avec les scripts maison que tu peaufine amoureusement depuis Linux 2.0.36, l'utilisation du MOC va te demander un surcroît de travail.

C'est pas pour tout de suite, en tous cas.

Le MOC, ça reste de la bidouille, ce n'est pas standard C++.

Si on va par là, un IDE non plus ça n'est pas "standard C++". Les "compilateurs d'UI" (UIC sous Qt, d'autres noms ailleurs) qui transforment un fichier de description d'interface en code non plus. Les IDL-compilers de Corba (pourtant très utilisé dans le monde Gnome, fut un temps) non plus. Et ainsi de suite.

Un puriste du C++ pourra effectivement trouver à y redire. Un pragmatique, à plus forte raison s'il a été amené à manipuler des langages plus souples que l'ami ++, risque fort d'y prendre goût ;)

Je crois que ce qu'ils veulent dire, c'est que Qt utilise un outil externe à C++ pour gérer ses signaux/slots (le fameux MOC) alors que Boost et Gtk se servent exclusivement des macros/templates du C++.

Ceci étant dit, il ne faut pas oublier que :
- Qt s'est mis à utiliser le MOC parce qu'à l'époque, C++ seul (ses compilateurs, du moins) n'était pas au point. Conclusion : ils ont largement eu le temps de peaufiner leur implémentation "externe", ce qui peut influer sur sa qualité par rapport aux solutions "natives" (mais aussi plus jeunes) de la "concurrence".
- Comme remarqué plus haut, les solutions natives ne sont pas forcément des modèles d'élégance, si on fait abstraction de leur indépendance à un outil externe. La STL est peut-être un superbe exemple d'utilisation des templates, mais ça a tendance à favoriser un code extrêmement peu intuitif (et des messages d'erreurs encore pires) pour un non-templateux. Le code équivalent en Qt+MOC peut paraître beaucoup plus lisible, notamment pour un non-Cpluspluseux ;)

- Attends Richard, le coup - hic! - de l'imprimante du 3è, c'était pas mal. Ok. Mais ch'te parie que t'es même pas cap d'écrire un éditeur de texte ...
- Boah attends, trop facile, un étideur. éteudir. éditeur de sexte. Struc. Un OS, kwa. Ch'te dis.
- Wai mais attends, j'pas fini. T'même pas cap de faire un édi... truc là, en LIPS! Lisp!

Pour moi ça c'est le gage d'un bon toolkit. Un toolkit qui me laisse construire une interface graphique en un rien de temps et qui fonctionne sous Linux/Windows/ voire Mac (jamais testé).

Ben justement. Le Mac. Parlons-en. Comme je l'ai dit plus haut, on a théoriquement depuis peu une version "native" de Gtk+ sur MacOSX. Mais il y a encore un mois, si tu voulais faire tourner une application Gtk sur Mac, tu étais contraint (sauf à utiliser du "très instable", et à ma connaissance seul Avidemux s'y était risqué, et seulement récemment) de faire tourner ton application sous X.

Et là, on touchait du doigt ce qu'on te fait remarquer ci-dessus : une application Gtk ne fait strictement _aucun_ effort pour s'adapter à son environnement. D'ailleurs, sur Mac, elle est exactement identique à sa version Linux, jusqu'au comportement du focus (qui du coup jure terriblement avec le reste des applications Mac). Sous Windows, encore, les applis proposent généralement de s'installer avec Gtk-WIMP (le thème "Windows" de Gtk) qui limite bien la casse (sauf sur le dialogue d'ouverture). Mais sur Mac, nada. C'est pratique en ce sens que ça te permet de faire tourner ton application avec un minimum d'efforts (pas besoin d'installer MinGW ou autre, sur Mac), mais par contre ça reste une bidouille pour dépanner : ton appli n'aura jamais l'air "vraie".

L'intégration Qt n'est certainement pas parfaite non plus sur Mac, mais la différence est beaucoup plus subtile.

Exemple, Gtk ne possède pas de d'api video/son. Pour moi ce n'est pas un problème. Si besoin, j'utilise Gstreamer qui a une api Glib like... et les exemples sont légions (Clutter, GtkWebkit ...)

Et bien entendu, toutes ces librairies tierces sont supportées de manières égales sur toutes les plateformes majeures actuelles? Rappel d'un détail de la news : Qt tourne sur WindowsCE et est en cours de portage vers Symbian.

Et même si je suis en train de ranger mon plus gros reproche à l'écosystème Gtk (l'obligation d'utiliser un serveur X sous MacOSX), force est de reconnaître que pour faire une application graphique un peu riche qui tourne sur Mac/Linux/Windows, y'a guère que Java qui arrive à la cheville de Qt. C'est théoriquement possible en Gtk&co, mais il va toujours te manquer la bonne version de telle bibliothèque pour faire tel truc. Avec Qt, tu as tout intégré et ce qui marche sur la 4.X de telle plateforme marchera sur la même 4.X d'une autre plateforme.

Logiquement, chaque toolkit a sa propre manière de faire. Tu devrais donc trouver des options communes aux applications Gtk, aux applications Qt, etc.

Non?

Tu as des exemples de "petits jeux OpenGL", en tête?

Parce que la seule référence que j'ai sous la main, c'est un EEE-Pc 701 (avec une GMA950, donc) et ça ne casse pas des briques non plus. OpenArena fonctionne, mais peu de mods (l'excellent - mais non libre - WesternQuake/SmokingGuns rame sévère). Quoique ce puisse être le fait du petit CPU de l'engin, aussi.

Ok, je visais un peu ce chipset, je vais donc globalement attendre que les chipsets à base de X4500 soient supportés, sauf si quelqu'un d'autre à eu des expériences plus heureuses.

Mais merci quand même :)

Va falloir revoir l'acception du préfixe "ex", je pense.

Perso je rejette toute invitation aux sites 2.0, quitte à passer pour un ringard...

Et c'est pas forcément ce qu'il y a de plus malin. Je pense notamment aux sites à la Facebook, qui ont de plus en plus tendance à servir de "carte d'identité" en ligne. Si tu n'y es présent, tu laisse la porte ouverte à quiconque voudra se faire passer pour toi. Et très franchement - même si je le déplore - le crédit qu'accordent actuellement les gens à des réseaux comme celui-là font qu'une usurpation de ton "identité" via ce biais peut être très lourde de conséquence.

Je suis, au contraire, d'avantage partisan d'une présence "minimaliste". Ne rien leur donner de confidentiel, ni même de privé, mais s'assurer qu'un adversaire ne puisse monter un profil plus crédible que le tien en se servant de ce qu'il sait de toi... un délicat équilibre.

Le mieux étant bien évidemment que les gens se mettent à réfléchir avant de publier des informations, et avant d'en consommer. Mais il ne faut pas rêver :)

Et ça marche?

Alors, pourquoi conserver encore ce moyen de communication aussi peu ergonomique qu'est la mailing list au profit des forums, qui ont également l'avantage d'être évolutifs et de proposer constamment des innovations ?

Et en plus c'est plus joli, un forum. Franchement, qui trouverait que que çà:

http://blog.titax.fr/public/blog/gmail-imap-thunderbird.png

est plus joli que çà:

http://www.forum-auto.com/tuning/section19/debut.htm

ou çà:

http://sasukeandkakashi.forumactif.com/index.forum

Sérieusement?

J'ai testé sur un des premiers Mac Intel (Radeon X1600), et fglrx a au moins un énorme avantage : il s'installe relativement simplement (quoique c'est tout de même pas immédiat, mais au moins ça semble prévu sur les distribs). Alors qu'une version de radeonhd qui gère bien la carte, même avec 2fps de moins que le driver propri, ça demande du git/svn et du gcc à outrance. Quand ça marche. Et pourtant c'est une carte vieille de plusieurs années...

Enfin ce que j'en dis ;)

la voiture de monsieur garée devant la maison de la meilleure amie au lieu d'être à son boulot...

Autant la protection de la vie privée est importante, autant elle a des ambitions autres que de couvrir les petites infidélités de tout un chacun. Enfin il me semble ;)