Alexis Ménard a écrit 18 commentaires

Bah si le logo pouvait etre change et a la place mettre celui de Qt ca aiderai....

moc ne transforme pas tes fichiers sources...

Bref c'est ce que tous le monde dit, steckdenis tu es pleins de bonne volonté mais finissons l'environnement de bureau logram et après on verra pour un gestionnaire de paquetage, une distrib, un kernel, un langage, un compilateur (parce que gcc pue), une nouvelle archi processeur.

Fais nous un truc polish, récolte des gens motive, bâti une vrai communauté de contributeurs et la suite ira toute seule. Comme KDE, comme Gnome comme n'importe quel projet opensource.


Bah oui quoi faut pas le décourager non plus. Si le truc me plait alors j'irai peut être coder dessus (enfin sans les tab a huit espaces sinon je vais être oblige de paramétré mon Qt Creator exprès pour Logram, ou alors on fait un IDE Logram, non je me disperse....).

Hurd?

Non je pense plutôt que c'est le fait que c'est trop en un coup.

Je me contenterai de faire d'abord un environnement de bureau, le faire devenir populaire, le faire le plus complet possible. Alors après peut être des distribs vont le packager et peut être le proposer en environnement d'installation. D'avoir des traductions, etc....

Et alors une fois que le truc tourne, je vais créer ma distrib maintenir les nombreux paquets, voir même recréer un gestionnaire de paquets.

Bref en gros j'attendrai que ça prenne un peu avant d'attaquer sur tous les fronts. Je pense pas que tu as autant de contributeurs que KDE/Gnome ou compagnie donc je mettrai plutôt tes ressources (en nombre limités) sur son projet de base Logram, l'environnement de bureau.

A partir sur tous les fronts, tu fais pas les choses a fond et bien surtout avec un nombre réduit de contributeurs. Il est facile de tomber dans le trop gros que tu peux plus maintenir.

C'est aussi mes 2 centimes. Mais ca reste une bonne initiative son Logram, l'environnement de bureau.

Je viens de checkouter le code comme je pense qu'on te l'as deja dit, si tout les commentaires sont en Francais ça n'ira pas.

Tu perds trop de contributeurs comme çà. Et tu perds les contributeurs hardcore allemand hélas :(.

Ta base de code n'est pas encore énorme il est temps de le changer.

Le port de k3b sous KDE4 est dans le repo kde depuis deja quelques temps. Il marche deja plutot pas mal.

Non non j'aime comment est fait le binding Qt, Qyoto, qui se base sur les outils de binding de KDE. Ce que j'aime pas, c'est l'attitude de Nokia qui ne facilite pas vraiment la tâche des binders en proposant une API uniquement en C++.

Mais tout Qt est fait en C++, je pense pas que tu te rends compte de la masse de travail que c'est de faciliter la taches de binders en ayant une autre API, et la maintenance.

Qt est un produit en C++. Nokia développe son produit qui est Qt. PyQt et co sont d'autres produits. C'est pas le rôle de Nokia de faire ça, de faciliter le binding puisque a la base le produit Qt est fait en C++. Les gens se sont lances dans des bindings, très bien mais on peut pas demander a Nokia de supporter un truc qu'il ont pas décide, supporte, voulu.

Et puis honnêtement pourquoi se faire chier a faire des APIs pas géniale pour matcher avec des langages comme C et faciliter le binding. On en veut pas, si c'est pour se retrouver avec des APIs a la GTK ma_fct_qui_s_appelle_super. Non merci!!!! Et puis chaque langage est spécifique ça deviendrai l'usine a gaz.

qui conseille dans la doc des solutions proprio comme s'il existait que des CLI proprios sous un OS proprio
Ils te conseillent pas de l'utiliser bien évidemment.

"Qt's ActiveX and COM support allows Qt for Windows developers to:"

Je pense que la phrase est claire que ca tue le cross platform de ton appli. Ils supportent pas les autres plate-formes (même si y'a Mono sous linux dans l'absolu), c'est juste pas teste. Il a jamais été marque qu'il faut l'utiliser, c'est un hack pour certaines applis Windows qui veulent du .Net/COM et co.

Mais c'est pareil dans tous langages, si on s'appui par exemple sur des libs spécifiques à une plateforme, c'est pas portable. On trouve une palanquée de libs sous Linux qui ne sont pas portées sous Windows par exemple.

Tu t'égares la. Un langage ne s'appuie pas sur des librairies , ERREUR. Un langage peut parfois fournir une librairie (exemple la std que tu dois implémenter sur ta plate-forme si tu veux qu'elle soit C++ compliant). Un framework utilise des librairies.
.Net n'est pas un langage mais un framework qui s'appuie entre autre sur le C# et des librairies (non portables pour certaines).
Qt est un framework aussi s'appuyant sur le langage C++ utilisant des libs mais dont Nokia s'assure qu'elles sont cross platform.

Un langage tu peux écrire la grammaire sans même parler de OS, librairies ou architecture.
On peut écrire la grammaire de Java, C++, C, C#.

Mais hélas pour le C# la frontière devient mince avec le langage proprement parle et un framework. C# inclue désormais tout un tas de concept qui ne collent plus avec l'idée originale et qui en vient a utiliser des libraires. Ex : Linq, syntaxiquement très étrange dans un langage et absolument pas implementable facilement sur nunux.

Donc oui dans l'absolu ActiveQt pourrai dire, ah mais sous Nunux tu as Mono ca marche. C'est tout simplement pas supporte et teste, pas dans les priorité de Nokia (ce que je comprends) et de plus tu n'as aucun contrôle puisque c'est un autre framework.

Supposons que sur mon appli Qt avec ActiveQt sous Windows, je fais du C# .Net avec fct A du framework 3.5. Niquel ca marche. Ah c'est Qt cross platform il disent mono sous linux parfait je recompile sous Nunux et la ça se branche sur Mono mais la fct A est pas implémenté, Craboum. Problème. Je comprends parfaitement que ça soit pas mis en avant car pas supporte et de plus c'est un hack, c'est une feature qui est que pour Windows dans des cas très précis (interfacage) et pour des raisons historique (des clients ont du demander) et cela est absolument pas garanti cross plate-forme. En fouillant un peu tu trouvera des features non cross platform dans Qt, mais le manuel dit : "Utilise les a tes risques et peril".

He les gens je voudrais rappeler que toute les applis ont pas un but cross platform. Certaines se foutent de Linux, Mac OS ou même vice-versa. Ces applications utilisent Qt juste parce que l'API est bien et les fonctionnalités présentes.

Si y'a moyen de faire de l'ActiveQt c'est pour certaines applis sous Windows et SEULEMENT sous Windows qui veulent bricoler du .Net. C'est purement pour faire parfois parler des applis .Net avec des applis Qt.

Ah oui et je rappelle que ActiveQt ou ce que c'etait avant existe depuis 2002 bien avant Mono (avec COM, MFC et co). Donc aucun rapport avec Mono.

Utiliser ActiveQt c'est comme avoir un XPixmap dans son code tu tue le cross-platform de ton applis. Après a coup de ifdef tu peux t'en sortir. Tu te plains de la doc qui prône le fait que ça soit crado mais bon c'est pour ça que tu as Qt, pour pas utiliser .Net et son implémentation incomplète sur Linux avec Mono.

Qt a ses avantages et ses défauts (binaire pas facilement deployable sur certaines archi par exemple).

Honnêtement je pense pas que c'est dans le scope de Qt de s'occuper de ce genre de bindings. Laissons la communauté le faire si ils ont besoin et le veulent. Je trouve que c'est juste inutile mais c'est mon avis.

En QT? En QuickTime?

Maintenant que c'est gratuit, je pense que les SSII ou co vont y penser sérieusement. Il faut juste que les devs réveillent un peu les chefs de projets au moment des choix de techno pour choisir Qt.

Parce que tu es bien le seul gars a perdre ta souris pendant des heures et avoir besoin d'une applet pour la retrouver.

Il faut lire l'annonce, ils vont pas acheter une entreprise pour la lâcher dans 6 mois. Il explique en détail qu'ils vont recruter des développeurs, améliorer la contribution et que le développement principal sera toujours mené par Qt Software. Cela veut donc dire qu'ils ne vont pas abandonner Qt. Au contraire ils en font leur toolkit en interne.

"dans le cas où Trolltech cesserais le développement de Qt Free Edition"

KDE a toujours une version GPL -> pas besoin de faire appliquer l'accord.

Si tu veux que ton appli link statiquement avec Qt tu payes la licence commerciale. Certaines entreprises payent aussi parce que elle pensent que un truc gratuit ca existe pas. De plus la LGPL t'oblige a fournir une facon de remplacer Qt, certaines applis proprio modifient Qt.

Ouais j'y suis depuis deja presque 1 mois et c'est bien sympa

Pas la moindre, mais il integre parfois des trucs qui sont loin du stade de release :), une demande aux devs permet de perdre moins de temps a integrer/packager des trucs qui sont susceptible de planter/changer car tres instable.

Par exemple ils prennent des applets dans playground qui sont pas pour nous dev KDE en etat d'etre release.

Mais comme tu dis ils ont le droit :) on est libre apres tout, je le notifiais tout simplement.

Je suis pas encore au fait de l'humour sur linuxFr mais j'ai un bon prof en la personne de Gof qui tente en vain de dissimuler le fait qu'il passe des heures ici.

Tu peux me faire confiance le theme restera pas comme ca. Je pense qu'avec un theme sobre ou sans skin tu dois avoir la meme chose qu'avant mais c'est a tester. Je suis d'accord qu'il faut un truc moins laid et surtout plus sobre.

Bien joue pour Inskape, j'ai jamais eu le temps de m'y mettre.

Ah oui sinon KDE recrute des artistes, l'appel est lance, parce l'oxygen team a du mal a suivre. Par exemple KOffice est en beta et il manque des icones.

Je crois qu'il convient de remettre les choses dans leur contexte.

Alors commencons par le debut, depuis KDE4 Kscd ne marche pas et une equipe d'etudiants en informatique de Toulouse a eu comme projet de porter Kscd sour KDE4 et en plus d'utiliser Phonon et Solid pour le faire marcher. Le support des themes a ete ajoute ce qui permet de mettre des themes en SVG (fonctionnalite auparavant absente).

Ce que tu vois la c'est le trunk, c'est pas release officiellement c'est mandriva qui prend des trucs sans vraiment demander avant, surtout dans cooker tu devrais pas t'attendre a avoir des trucs forcement fonctionnel et joli.

De plus le projet (bonne initiative soit dit en passant) s'est termine en juin donc recement et il a ete demande aux artistes de faire des themes. Les etudiants ne sont pas graphiste et n'ont jamais la pretention de l'etre. Ils ont fait ces themes a la va-vite pour juste montrer le theming et le fait qu'il fonctionne.

Je trouve que le projet est une reussite et que normalement (sauf probleme) Kscd fonctionne. Je trouve dommage que l'on crache facilement sur le travail des autres sans prendre des renseignements. Donc ton point de vue serait plus constructif ici -> kde-artists@kde.org en leur rappelant que Kscd fonctionne et que les gens attendent des themes.

Merci Gof pour m'avoir fait part de ce journal (heureusement que tu passes des heures sur linuxfr :p)

++

Bien sur la video est prévue pour les présentations...Nous verrons si nous mettrons les présentations en ligne. Les videos sont prévues ca c'est sur!!!