tanguy_k a écrit 766 commentaires

Au contraire c'est tres technique.

On tourne en rond la, j'ai jamais dit le contraire

pasBillpasGates = raison technique uniquement

TImaniac = raison technique uniquement

tanguy_k = raison technique ET raison politique

Android a des problèmes de fragmentation de la plateforme

Oui et pour des raisons qui n'ont rien à voir avec la discussion en cours. Android fonctionne sur les memes principes que WP7 : une machine virtuelle. Le NDK n'est pas responsable de ce problème (le NDK est apparu que récemment).

Pour rappel :

• WP7 est distribué depuis novembre 2010 (4 mois) sur tres peu de terminaux (10 appareils) et est anecdotique pour l'instant

• Android est distribué depuis septembre 2008 (2 ans et demi) et accapare 30% du marché (+ de 100 appareils ont été lances)

De plus Microsoft est beaucoup plus restrictif sur les caractéristiques techniques des appareils que Android.

Normal qu'il y est d'avantage de fragmentation non ?

Avec la version 3 d'Android, Google a annoncé qu'il allait restreindre les possibilités de personnalisation de la part des constructeurs, donc tout comme Microsoft le fait. Ce qui paraissait comme une bonne idee au depart n'en ai finalement pas une : les constructeurs ne jouent pas le jeu.

Qui lance un petit troll Boost vs Qt ? :)

le choix de la techno [...] est évidemment politique

C'est l'absence de choix qui est politique selon moi (en plus de technique).

C’était pas clair dans mes précédents messages ?

Mouais, tu y vois seulement des arguments techniques, c'est pas mon cas. Ca doit bien les arranger que l'on soit obligé de faire du .NET pour WP7. J'ai beau faire pas mal de C# sous Visual Studio et apprécier la techno ça m'empêche pas d'être méfiant vis à vis d'eux et de ne pas leur faire confiance. Vu leur palmarès le bénéfice du doute n'est plus franchement possible.

Dalvik a par exemple les mêmes objectifs : s'abstraire du matériel, sécurité... pourtant Google propose aussi de faire du natif. Microsoft pourrait faire de même.

Je pense que c'est aussi une politique d'enfermement voulue: "utilisez notre techno et nos outils plutôt que ceux des autres". Une fois captif vous ne pourrez plus vous passez de nous et à nous la tune.

"le deal l'interdit" ne représente pas la réalité, il faut lire "le deal ne l'a pas autorisé".

Windows Phone 7 est un nouveau OS pour smartphones écrit en .NET : Microsoft a fait table rase du passé. Ils ont délibérément interdit le développement d'applications qui n'utiliseraient pas la plateforme .NET (i.e le code natif C/C++, Python, Java ect...) pour des raisons techniques mais aussi j'imagine politique et ça bien avant le deal avec Nokia.

Bref c'est d'autant plus incompréhensible de la part de Nokia d'avoir signé avec Microsoft : ils jettent toute la R&D précédemment investie et repartent de 0 (encore une fois) avec un OS qui n'a pas encore fait ses preuves.

D’après ce que j'ai compris le but de IcedRobot est de remplacer Dalvik par OpenJDK. Qt Android c'est du C++ avec un petit bout de Java pour le bootstrap pour le reste ca utilise le NDK (langage C), donc rien à voir ou presque :)

Combien de temps vont-ils mettre pour sortir un tel sous Windows Phone 7 ? AHMA 6 mois minimum et en sortant un tel qui ressemblera aux autres WP7 puisqu'ils n'auront pas eu le temps de le "customiser".
Ils n'ont pas encore les competences internes pour faire du dev WP7 et leur culture d'entreprise est a l'oppose. Recruter les bonnes personnes va prendre du temps et la direction devra faire face a de fortes resistances internes et une demotivation du personnel actuel (cf les manifs devant le siege).

6 mois de dev sur MeeGo avec les equipes actuelles auraient surement permis de sortir un produit qui aurait tenu la route.

C'est un peu comme si Apple a la fin des annees 90 avait lache le dev de Mac OS X pour repartir de 0 avec un partenariat avec Microsoft pour integrer Windows sur leur matos.
En 1997 Apple etait au plus mal et c'est a ce moment la qu'ils ont rachete NeXT pour developper Mac OS X.

Nokia a rachete en 2008 Trolltech qui developpait Qt
Qt est la base de MeeGo
MeeGo etait/est la strategie de Nokia pour les smartphones haut de gamme

Wikipedia indique une moyenne de 1.08% pour nov 2010 en se basant sur plusieurs sources. http://en.wikipedia.org/wiki/Usage_share_of_operating_system(...)

Voici les stats Wikimedia. Pourquoi Wikimedia ? enorme traffic + sites generalistes + stats tres détaillées

* Octobre 2010
http://stats.wikimedia.org/archive/squid_reports/2010-10/Squ(...)
Requests 4,471,511,000
Windows 84.42%
Mac 7.43%
Linux 2.04% dont 0.47% Android = 1.57%
iPhone 1.92%
iPad 0.46%
BlackBerry 0.45%
SymbianOS 0.21%

* Avril 2009
http://stats.wikimedia.org/archive/squid_reports/2009-04/Squ(...)
Requests 3,762,863,000
Windows 89.50%
Mac 6.05%
Linux 1.49% dont 0.03% Android = 1.46%
iPhone 0.93%
BlackBerry 0.15%
SymbianOS 0.09%

5% sur w3schools s'explique par le fait que ce site web ne s'adresse pas vraiment a des utilisateurs classiques (qui se documente sur HTML et Javascript ?)

Conclusion : Linux sur le PC desktop, pas de quoi pavoiser :/

> Certains composants de Qt dépendent d'une boucle d'évènement et de variables globales

Effectivement dans certains cas t'es obligé de fournir une fonction init() (et même exec() et close() qui encapsule QApplication::exec()) que l'utilisateur devra appeler avant d'utiliser ta librairie basée sur Qt.
Ceci n'est pas spécifique à Qt, cURL par exemple fonctionne sur des mécanismes similaires (curl_init(), curl_exec(), curl_close())

> asio et thread sont bien mieux fait que QtThread et QtNetwork

Ce que je retiens de Boost c'est son coté API bas niveau comparée à celle de Qt qui est beaucoup plus simple et cohérente.

> si Qt évolue et casse son API

Et si Boost et Xerces cassent leurs API ? cet argument est ridicule. Pour info Qt n'a pas cassé son API source et binaire depuis plus de 5 ans.

> un front-end s'intégrant mieux à Gnome

Et ? QtCore, QtXML ect... sont des librairies comme les autres. Rien n'empêche de faire une GUI GTK+ par dessus. QtCore s'intègre parfaitement avec la boucle d'événement de la GLib. L'inverse existe également : le modèle en GLib et la vue en Qt.

Au passage désormais (depuis 2 ans déjà) l'intérêt de développer une GUI GTK+ par dessus un modèle qui utilise QtCore n'est plus franchement intéressant grâce à l'utilisation de QGtkStyle http://labs.trolltech.com/blogs/2008/09/05/qgtkstyle-now-par(...) qui permet d'avoir une intégration parfaite dans GNOME. QGtkStyle est intégré dans toutes les distribs modernes et fonctionne vraiment très bien.

> je trouve que Qt en fait trop. Non seulement ça fait doublon avec Boost,
> mais c'est également le cas avec la STL

Pour avoir utilisé Boost pendant 3 ans, Qt est bien supérieur en terme de fonctionnalités, de cohérence et de documentation. Pour la STL j'en parle même pas.

> Un truc qui manque à l'écosystème C++, c'est une bonne lib GUI qui se contente d'être une lib GUI

Et en quoi QtGui ne répond pas a cette problématique ?
Pour info ca fait plus de 5 ans que Qt est découpé en modules indépendants simples et cohérents...

> j'aime bien les libs, mais pas les frameworks intrusifs

Comment peut on avoir une vision aussi archaïque !
Vraiment utilise Qt, ou meme C# ou Java et ensuite compare a tes méthodes de développement qui utilisent 15 libs différentes pour afficher hello world.

> la combinaison [C++, STL, Boost, autres libs métier, lib GUI] est ce qu'il y a de plus propre

C'est ce que je pensais (il y a très longtemps) et finalement dans la pratique on se rend compte que c'est compliqué pour rien : ça crée des problèmes sans rien apporter de plus.

Duke Nukem for Ever

J'imagine qu'il y a plein de possibilités d'outrepasser ça, j'ai pas expérimenté. Tout ce qu'il faut retenir c'est que le gouvernement italien censure énormément compare a la France.

Il suffit de faire une recherche sur Internet pour voir que c'est pas glorieux, par ex
http://fr.rsf.org/ukraine-les-journalistes-s-unissent-contre(...)
http://www.tuniscope.com/index.php/article/3263/actualites/i(...)
Il y a meme des manifs en ce moment : http://fr.euronews.net/2010/07/02/italie-manifestation-des-j(...)

Berlu c'est Sarko puissance 100

Ah oui j'oubliais, meme dans les bibliotheques qui proposent un acces Wifi, il faut donner sa piece d'identite pour avoir les identifiants permettant de se connecter au reseau avec son portable.

Je confirme que thepiratebay est inaccessible en Italie. De plus si vous allez dans n'importe quel cybercafe en Italie, on vous demandera systematiquement votre piece d'identite.

Savez vous ou se situe OpenSUSE dans la course a la vitesse de demarrage (et extinction) ?

Il n'est pas necessaire d'avoir un compte gmail. Il suffit d'envoyer un mail a nomduprojet-subscribe@googlegroups.com et peut importe l'adresse mail, la personne est ajoutee a la mailing-list (sous reserve de moderation).

Oupss mon enthousiasme m'a aveugle : deviceinfo.cpp permet de lister les devices audio via MPlayer, donc rien a voir avec le mode slave :/ Je n'ai pas trouve d'autres endroits dans le code de SMPlayer qui fasse reference a setenv()

Oui effectivement MPlayer n'utilise pas gettext. MAIS bcp de patchs ont circule sur la mailing-list de dev. Je viens de regarder a l'instant dans le code source de SMPlayer et dans le fichier deviceinfo.cpp il y a ceci :

QProcess p;
p.setEnvironment( QStringList() << "LC_ALL=C" );

Et voici le svn log qui va avec :
rvm 10/6/2008 10:52:58 AM
Run aplay with LC_ALL=C to be sure it displays the info in English

Auparavant SMPlayer permettait dans son panneau de configuration de changer les strings a traduire provenant de MPlayer or cela a ete supprime.

Je pense que ca vaut le coup d'essayer un setenv() :)

Ca serait pas possible de setter env LANG=C avant de lancer mplayer puis de revenir sur le LANG original ?

Ici un article interessant http://www.0xdeadbeef.com/weblog/2010/01/html5-video-and-h-2(...) de Christopher Blizzard du projet GNOME.

En gros il fait un parallele entre H264 et le format GIF qui etait brevete. Unisys a demande de grosses sommes a certains sites web pour l'utilisation du format GIF.

Bref H264 c'est dangereux !

Plutot que de se baser sur un format de description (XML ou clef/valeur facon .ini file, au final ca change pas grand chose), je me baserais plutot sur un language de script. C'est beaucoup plus puissant, flexible et evolutif.
Dans le cas de Setup, QtScript (donc du Javascript) est tout indiqué a mon avis : faire des boucles, utiliser des conditions, des fonctions et des regexp ca peut etre tres utile.
Reste a definir alors une jolie API qui s'appuie sur QtScript.

D'ailleurs sous Windows les principaux outils pour creer des installers s'appuient sur des languages et y ajoutent une API. Inno Setup : Pascal, NSIS : C

Je ne possede pas l'iPhone mais j'ai l'impression que ses utilisateurs redecouvrent les avantages des applications natives sur ce matos.
Contrairement a Windows, l'iPhone permet de facilement installer une application native et tout s'integre bien.

> même Qt ne s'intègre pas parfaitement sous Windows

Ah ?