TImaniac a écrit 6420 commentaires

À partir du moment ou des bouts (surtout essentiels) ne le sont pas, les bouts de codes ne vont pas servir à grand chose.
Bah ca permet à une implémentation libre de réutiliser les briques libres...

C'est d'ailleurs pour ça que les développeurs demandes les spécifications aux fabriquants de matériels plutôt que des pilotes.
Oué bah en l'occurence c'est très bien documenté et spécifié.

mouai... donc la balise video et audio dans Firefox 3.1 (qui sort à la fin de l'année), dans Opera (et dans webkit, je sais plus), c'est du vent ?
Oui.
Ce qui fait la force de flash, c'est qu'il marche partout, et partout pareil : le développeur sait qu'en diffusant une vidéo pour flash elle sera compatible là où fonctionne le player flash, parcque le player impose le(s) formats.
HTML5, qui n'est pas encore sorti, n'a pas réussi à imposer de format faute de consensus (tout le monde voulant y mettre son format). Au final on va avoir une jolie balise avec un contenu toujours aussi risqué niveau compatibilité navigateur.
Il aurait fallu imposer des standards, comme H264, mais imposer quelque chose, avec des profiles, etc.
Pour moi la balise HTML5 ne sera quasiment pas utilisée à moins qu'émerge un consensus sur un format donné, et la bataille sera rude, et je suis prêt à parier que c'est pas un codec libre qui sera le gagnant.
Donc oui, pour moi cette balise video du HTML5, c'est du vent total.

Oui, à propos de standards ouverts, on peut noter l'apparition de la balise dans HTML5.
Oué balise trop ouverte pour des formats fermés... même combat, avec pire, aucune consigne sur les formats à implémenter, donc aucune garantie de compatibilité d'un navigateur à l'autre...

Le format Flash est disponible sur le site d'Adobe, oui.
Je te parle pas des specs, ca j'ai bien noté, je te parle de code, d'implémentation donc. Là on a le droit à une partie sous licence libre.

i vous voulez faire de l'interface riche sur internet, rien ne vaut les standards, donc vive DHTML, AJAX, CSS et SVG
Oué bah en attendant pour faire du multimédia on a toujours rien : HTML5 qui va résoudre en partie le problème n'est toujours pas sorti, et niveau standards et codecs libres & performants, on repassera.
Donc en attendant d'avoir une alternative de la communauté du libre qui soit sérieuse, y'a pas trop le choix que de faire avec ce genre de techno.

Pas mal, pas mal, sauf que... Macromedia/Adobe l'a déja fait avant!
Ah bon Adobe fourni des bouts de Flash sous licence libre ?

Et les outils MS (IronPython et bibliothèques de widgets) sous MS-PL :
http://en.wikipedia.org/wiki/Microsoft_Public_License#Micros(...)

- spécification "ouvertes" du format XAML ? quelle licence ?
J'ai foutu un lien dans le journal.

- outils de dév sous licence libre ? laquelle ?
Eclipse Public License Version 1.0

C'est parcque je n'ai pas mis la définition des méthodes. Voici le code complet qui tourne dans Visual Studio 2008 :

using System;
using System.IO;

public static class LinuxFrTrollExtensions
{
public static void times(this int nb, Action action)
{
for (int i = 0; i < nb; i++)
action();
}

public static string pluralize(this string text)
{
return "people";//devrait parcourir un dictionnaire ici
}

public static TimeSpan hour(this int h)
{
return TimeSpan.FromHours(h);
}

public static TimeSpan minutes(this int m)
{
return TimeSpan.FromMinutes(m);
}

}

class Program
{
static void print(object o)
{
Console.WriteLine(o);
}

static void Main(string[] args)
{
2.times(() => print("toto"));
print("person".pluralize());
print(DateTime.Now + 1.hour() + 5.minutes());
Console.ReadLine();
}
}

Bon, soit. Mais dans ce cas, on ne peut pas dire que .NET soit portable, puisqu'il repose sur l'architecture x86 32 bits.
Ce qui repose sur du x86 32 bits c'est uniquement le bootstrap qui est là par soucis de compatibilité avec des vieux Windows. C'est là par soucis de pratique, ca n'enlèce strictement rien à la portabilité du code .NET en soit, et tous les runtime CLR savent lire ce bytecode et l'exécuter de manière portable.
C'est comme les fichiers script Python ou autre : les fichiers textes font chier parcqu'ils ne déclarent pas leur contenu (et ni leur encodage). On a trouvé une astuce en ajoutant une ligne ou 2 en début de fichier pour pallier cet inconvénient, c'est un hack, c'est pas joli joli, mais ca permet d'ouvrir le fichier avec n'importe quel éditeur texte, puisque ca reste un fichier texte. Mais ca n'empêche pas le shell qui sait lire les 2 lignes d'entête d'exécuter le script convenablement, lui qui sait les interpréter.
Pareil pour les fichiers OOo, ils auraient pu faire leur propre entête tout en conservant la compression zip, mais par pragmatisme et soucis "pratique" ils ont voulus laisser la possibilité de réutiliser les softs de décompression zip existant.
Mais franchement, se servir de ce genre d'argument pour dire : c'est pas conçu pour être portable, quand dans la pratique c'est tout à fait portable, c'est vraiment pitoyable.

il faut aller chercher plus loin pour voir qu'il s'agit en fait de .NET.
trop dur ! faut lire quelques octets en plus ! Mon dieu !
Et les fichiers OOo qui sont des zip ? Pareil faut aller lire plus loin ! Les scripts python ? des fichiers textes ! t'imagine ? Scandaleux !
T'en à d'autres des arguments pourris comme ca ?

Y'a aucun format d'exécutable natif portable d'un OS à l'autre.

tu troll sur le "conteneur" de l'exécutable qui contient effectivement une signature permettant à Windows de reconnaître un assembly .NET comme un exécutable.
Ca ne rend pas le format du bytecode (le contenu) moins portable, quoique t'en dise.
Un fichier Java a également une signature qui lui es propre et personne n'en fait un pataques.

qui oblige à des kludges pour détecter s'il faut lancer tel programme avec Wine ou avec Mono…
oué bah oué, comme sous Linux si tu veux pouvoir lancer automatiquement n'importe quel fichier : faut détecter son format puis choisir le bon exécutable, rien de neuf.
Windows fait le même boulot pour savoir si c'est un exécutable "natif" ou s'il doit appeler le runtime .NET.

J'avais oublié la première ligne, en C# ca donne :
DateTime.Now + 1.hour() + 5.minutes()
Pas besoin de langage dynamique pour ca !

En C# 3 j'obtiens la même chose avec ca :
2.times(()=>print("toto"));
print("person".pluralize());

Faux, Mono et .net ne partagent aucun code.
si.
Et confirme que la seule collaboration avec les équipes Microsoft porte sur Moonlight,
C'est de ca que je parle.
Et entre autre de IronPython et du DLR, qui sont bien développés par MS sous licence open-source approuvée par la FSF, et la pas Microsoft Reference Licence, mais la Microsoft Public Licence, quoique t'en dise. Et utilisé dans Moonlight, quoique t'en dise.

Oué enfin c'est la première fois que je troll sur ce sujet quoi :)

Oué bon autant pour moi j'avais pas vu le thème QGtkStyle qui vient juste de sortir :)

ah ben faut voir le problème du côté des concurrents...

Apres c'est sur que le titre d'une fenetre faudra peut etre faire des #ifdef mais c'est tout a fait normal.
Mais pas cross plateform pour 2 sous. C'est évidemment de ca que je parlais : je connais aucun toolkit capable de modifier les label écrits par les développeurs pour refleter le style verbal recommandé.

Toutes les boites de dialogues sont natives avec Qt.
Je parle pas d'être natif ou non, ni des boîtes de dialogue ouvrir fichier & co, mais des boîtes de dialogue créé par le développeur.

Non justement !
Et t'as jamais eu l'idée qu'on pouvait utiliser les widgets natifs dans un thème ? C'est exactement ce que fait le thème gtk-wimp sous Windows.

Faire un theme natif, c'est pas du coloriage
Sans dec. J'ai déjà dis le contraire ?

Avant que WinForms/GTK+ arrivent a un niveau equivalent du Qt de 2008 il va falloir attendre encore quelques longues annees.
oui, je suis bien d'accord, qt est sans doute le moins pourri (encore que une appli Qt sous Gnome c'est pourri) "visuellement", mais ca reste que si on veut une application intégré au destktop, c'est pas la bonne solution à l'heure actuelle.

contairement a Qt qui est fait pour des le depart.
Qt s'intègre très mal sous Gnome par exemple qui a une gestion de layout complètement différente.

car la derniere fois que j'ai utilise C#, WinForms utilisait Wine et GTK+ sous Mac utilisait X11 (!)
Oué donc en gros tu critiquais une API pas finie quand moi j'annonce qu'elle est finie. Forcement :)

Et... en quoi ca le regarde ? pourquoi MS devrait faire ca ? Que tu sois responsable de ce que font des fournisseurs, ok, de ce que font tes clients...

Euh, c'est la première fois que j'en parle. Techniquement je trouve la chose bien conçue et bien pensée, après j'utilise pas, je suis pas fan des langages dynamiques.

Tu connais le marché des entreprises ? des universités ? des serveurs ? des netbooks ? de l'embarqué ?

Pour résumer :
- OIN : armes de dissuasion en période de guerre froide.
- accord Novell/MS : accord de cesser le feu entre 2 parties.

merci !

. Mais bon, des applis WPF, j'en vois pas encore beaucoup quoi.
Non mais WCF par contre... Olive, Olive !