hum...Comme d'hab' , un trés bon travail de t'a part .Je suis toujours aussi impressionner par ta qualité à programmer des choses aussi complexe .

Bon continuation , bonne chance pour la suite et que dieu te bénisses !

Wuaaa o_O, tu avais dit qu'on allait être surpris, mais là j'en tombe .

c'est encore plus beau que shaman o_O.

Si je prend setup sur une gentoo(sinon n'importe quoi d'autre qui me donne de quoi faire tourner une console, comme dans le tuto) a la place de portage pour l'installation, il n'y aurai pas de problème ?

si non, je me porte volontaire pour devenir mainteneur, maintenant que je vois ce que ça peut donner, et que je risque de l'utiliser.

Bonjour,

Je suis content que ça te plaise. Il y a encore d'autres fonctionnalités de prévue, mais que je n'ai pas eu le temps de coder en 15 jours (elles nécessitent quelques jours de réflexion pour être bien faites, donc j'ai attendu). Par exemple, un mode simplifié faisant que Pkgui se présente un peu comme gnome-app-install (le machin plus simple que Synaptic, utilisé par Ubuntu avant de passer au Software Center).

Maintenant, je me concentre dans le débogage, qui va changer pas mal de choses (je n'aime pas la manière dont les progressions sont gérées).

Par mainteneur, tu veux dire que tu vas maintenir cette application, corriger des bugs, etc ? . Ou alors c'est plus dans le sens «packageur» ?

Bonjour,

Le site web est à jour, et j'ai quelques bonnes nouvelles :

• Il y a de belles icônes pour les sections, ici
• Ceci vous permet de tester le commit HEAD de Pkgui, et ainsi de profiter du filtre par section
• Pas besoin de Qt 4.7, QIcon::fromTheme est disponible sous Qt 4.6.
• J'ai résolu de petits bugs empêchant de compiler Pkgui.

Vous pouvez donc maintenant tester sans probèmes .

bah, c'est bien le but du packageur de toute façon.

construire, maintenir et corriger les paquets ?

par contre je pourrais pas le faire tout de suite, il faudra attendre mon pc, pour pouvoir mettre un système avec setup.

Ok, donc packageur, pas mainteneur (mainteneur = gère une application, pas un paquet) .

En attendant, et pour éviter que tu «oublies», tu peux construire une LFS, en allant jusqu'à Xorg et Qt. Ca te prendra du temps, ça n'apportera rien directement à Logram, mais tu as absolument besoin de très bien connaître le système pour l'empaqueter (savoir de quoi dépend quoi, ce qu'un paquet installe, des techniques d'empaquetage).

Je t'invite également à lire Ce que Debian dit sur les paquets, ainsi que ses Meilleures pratiques d'empaquetage, qui te permettront de voir un peu ce que j'attend (ces documents sont lourds et moches, mais se lisent et se comprennent en moins d'une journée, alors qu'ils te serviront toute ta vie ).

Si t'as des questions, ouvre un topic sur le forum (pas un MP). Ainsi, ces infos seront publiques pour les futurs empaqueteurs, et je (ou quelqu'un d'autre) pourrai en faire une belle page de wiki.

et ce quelqu'un d'autre peut etre moi, d'ailleurs

merci pour les liens.

pour la LFS, j'ai un petit disque, donc faudrait que je passe par virtualbox, sachant que j'aurai pas le réseau (tant que je n'ai pas corrige un probleme), faudrait que je passe par une clé usb. donc je préfere tout de meme attendre mon nouveau pc (qui a un Phenom II x4, comparé a l'athlon x2 1.7Ghz là). D'autant plus que j'ai déjà installé une gentoo, et j'avais fait a peu pres la moitié du LFS (pour teste setup).

Faut juste que tu saches compiler un programme, trouver des infos sur lui (savoir que les programmes GNU sont sur ftp.gnu.org/pub/), te servir de Sourceforge, savoir ce que veulent dire les sections du Man pour découper les paquets en paquet et paquet-doc, etc.

Donc il faut juste que tu t'entraîne à faire des paquets, compiler des programmes. Tu as de la chance, tu n'auras pas à empaqueter des horreurs comme GCC et Qt (une demie journée pour chaque).

Tu as des paquets d'exemple ici (juste les métadonnées ). Le sous-dossier packages-old contient des paquets qui ne sont pas aux normes, ceux qui sont actuellement dans les dépôts. Les autres dossiers sont une jolie organisation des paquets, qui sont eux-mêmes tout propres. Tu peux donc voir la complexité de gcc (toolchain/gcc) et de Qt (packages-old/gui/qt, lui est aux normes).

Par contre, ces paquets n'ont pas d'icône. Je ferai bientôt une page de wiki complète de référence sur les metadata.xml, quand j'aurai une DTD pour ces fichiers (une DTD permet d'avoir un complètement auto dans KDevelop, vous ais-je déjà dit que cet IDE roxxe ? ).

Pour les autres

Je vous signale que j'ai aujourd'hui bien travaillé, avec 12 commits, 31 files changed, 2654 insertions(+), et 91 deletions(-).

Alors oui, des insertions ne sont pas de moi. Environ 1500 lignes sont de cpp-markdown, une bibliothèque de parsing Markdown en C++, maintenant utilisée par Pkgui pour formater les descriptions et licences des paquets . Cela ajoute Boost-headers et Boost-regex comme dépendances à Pkgui.

J'ai également peaufiné quelques endroits de Pkgui :

• Progressions mieux affichées. On peut maintenant utiliser un dépôt remote sans avoir des fenêtres de progression à chaque fois qu'on clique sur un paquet (ce qui télécharge les métadonnées).
• Affichage de la vitesse de DL dans les progressions
• Affichage de l'icône du paquet en cours d'installation quand celui-ci pose une question.
• Petit ajout : une case à cocher «Installer les suggestions des paquets ci-dessus» en dessous de l'étape 1 de l'assistant d'installation
• Plein de corrections de bugs dans le Solveur, qui maintenant ne saute plus de résultats (ça m'a occupé facilement 3 heures ).
• Côté Website, base de donnée à jour (donc dépôt à jour, donc LPM en version Git marche avec archive.logram-project.org), et affichage de sublimes icônes dans l'affichage des sections. C'est beau et c'est pro. Cette page devient en un coup l'une des plus belles du site (comme l'espace Mes News ou l'affichage d'un sujet de forum), alors qu'elle était l'une des plus moches (comme la liste des paquets d'une section :/ ).

J'aime les journées où j'avance .

un autre detail serait d'améliorer les pages avec la liste, comme http://logram-project.org/packages-3-1-2-1.html , en mettant par exemple la courte description sur le coté, eventuellement l'icone du programme, et en séparant mieux les paquets.

eventuellement, on peut aussi mettre de l'ajax pour charger automatiquement la longue description d'un paquet lors d'un clic, ou l'afficher dans une popup javascript (et donc pas une vrai popup) qui ne change pas de page, sous condition que javascript soit activé bien sur, sinon il reste normal.

je préfere dans tous les cas cette page à celle de launchpad .

pour les paquets, j'en ai deja fait pour archlinux, meme si c'est extremement simple.

Je suis en train de réfléchir à cette page, et maintenant qu'elle est paginée, je peux prendre plus de place pour chaque paquet.

Le principe est de les regrouper par nom, puis de lister les versions avec des infos (section + icône de la section, description courte, architectures, etc).

Je ne peux pas mettre l'icône du paquet car tous les paquets n'en ont pas (ce qui créerait des trous). De plus, les icônes sont inclues dans le paquets et les en sortir sous forme de fichier .png sur le serveur prendrait trop de place (et de temps). Il y a aussi le problème de la mise à genoux du serveur par le client web, et du temps de chargement des pages. Afficher 40 paquets, c'est afficher 40 icônes de sections (bon, ce sont toujours les mêmes qui reviennent, donc ça ne fait pas 40 requêtes HTTP), mais également 40 icônes de paquets. Ce sont de petits fichiers, autrement dit ça ralentit plus le browser que des gros (où il a le temps de DL pour faire autre chose).

Va sur planetkde.org, tu verras ce que c'est qu'une page pleine d'images. Même en 30Mbps, il me faut presque 20 secondes pour la charger, simplement le temps de rendre les images (et j'utilise Chromium).

Pour les paquets Archlinux, c'est une bonne base. Maintenant, avec Archlinux, tu ne dois pas les découper ni les nommer avec attention. Tu as juste à trouver les dépendances (ce que Logram fait automatiquement avec les shlibdeps ).

Il manque la recherche dans une section aussi ;).

edit: voire meme la recherche dans le menu a gauche

Salut, Pas mal du tout ce front end, mais en effet il manque une interface plus mme michu friendly. J'ai cependant une suggestion, il existe une super bibliothèque dénommé PackageKit que vous connaissez sans doutes tous, qui fonctionne sur un système de backend. Comme Steckdenis nous a fait une belle bibliothèque lpm, il est très facile d'écrire un nouveau backend PackageKit lpm.(j'ai déjà eu l'occasion de mater le code des backend)

Ce que cela nous apporterait? tout un tat trucs super tel que la compatibilité avec KPackageKit, ça permettrait à l'utilisateur habitué d'une application de l'utiliser, de ne pas le "restreindre" à celle de steck.

Voilà voilà @+ tout le monde.

PS: non ce n'est pas de la pub pour PackageKit ni pour un site sfhost

Alors dans l'ordre .

Il existe maintenant un filtrage par section, ainsi que par dépot/distro.

Une interface Michu Friendly est en cours, je suis actuellement en train de découper pkgui en libpackageui et pkgui. Ainsi, je pourrai en quelques lignes seulement coder un truc ressemblant au Software Center Ubuntu, et à GDebi. 1000 lignes maxi pour chaque, et encore .

PackageKit, hors de question. C'est le plus petit dénominateur commun, donc on perd en fonctionnalité, surtout que Setup en a beaucoup :

• Perte des communications
• Perte des DL en parallèle
• Perte des progressions en général
• Perte des métadonnées
• Perte de la liste des fichiers

et encore plein de petits détails.

Le tout s'accompagnant d'une lenteur, et l'interface KPackageKit est réputée comme étant nulle, au point que des devs KDE la refont (Shaman 2 ainsi qu'une autre dont on a parlé sur le Planet KDE, qui se base sur QApt, et qui est pas mal).

Logram, en ayant sa propre interface, tire tout ce qu'il peut de Setup, en étant extrêment rapide (environ 2x plus rapide que Synaptic, l'interface graphique de gestion des paquets la plus rapide du moment ).

Ok pour PackageKit, je n'aime pas non plus KPackageKit mais peut être que certains sado masos oui...

Enfin bref... je pense qu'il serait vraiment très appréciable que pkgui devienne un peu plus "cloud", attendez tapez pas je vais tout vous expliquer! Mon idée ça serait que tu (ou quelqu'un d'autre qui veuille bien s'en occuper bien sûr ) fasse une sorte d'API en ligne, c'est à dire une page à laquelle on envoie des arguments dans son URL par exemple: http://www.logram-project.org/lpm-api/infos.php?package=libQt4-dev et qui nous renvois un fichier XML, contenant des petites infos en plus sur les paquets.

Mais... quoi donc! Tout peut être stoqué dans le xml du paquet, non?

Hé bien non on pourrait stoquer des notes que donnent les utilisateurs sur un paquet, et même leur commentaires, voilà ce que ça donnerait par exemple:

<globalNote>5<globalNote>
<message user="kido" note=10 title="euh bah je sais pas quoi mettre en titre de mon message :/" text="Qt forever mes amis!"></message>
<message user="linkdd" note=0 title="il a tord!" text="nan l'écoutez pas Qt c'est lourd vive GTK!!!"></message>

ça pourrait être sympa je pense, après libre à toi de te créer un beau paneau d'administration te permetant de facilement bannir un user qui pourrie tout(ou faire un système de validation des messages sans pour autant tomber dans la censure...)

pkgui télécharge le xml, il le parse(QtXML powa), et nous affiche joliment les commentaires .

Voilà c'est une idée @+

Déjà pensé .

C'est fout comme je trouve des idées en 30 minutes, et qu'en 1 an et demi, plein de monde finit par me la redonner [/grosse tête (qui va se faire frapper par Keisuke)]

Bon, je révèle mon plan diabolique, conçu depuis plus d'un an :

• Un bête paramètre, ajouté aux urls du site web : ?r . Ce paramètre, dans la fonction general/functions.py:tpl, va changer la template "template.html" en "template_r.html" (r de Remote )
• Cette template, au lieu de sortir un lourd HTML et de prendre plein de temps, va formatter un beau XML léger, contenant les données brutes fournies par la BDD
• Côté client, libwebsiteintegration se chargera du reste. Cette bibliothèque enverra des requêtes GET et POST, comme un navigateur fait (d'où les urls à-la-site-du-zero, très simples à QString::arg-er). En réponse, cette lib recevra le XML
• Elle prendra ces infos, passera le tout dans un peu de QtXml, et renverra à l'appli ce qu'elle veut.

Ce qui est prévu comme fonctionnalités :

• Affichage des news du site directement dans la page d'accueil du Centre de Logiciels (le truc que je vais commencer demain ). Ainsi, s'il y a des paquets cassés, les utilisateurs le verront tout de suite. Messages également accessibles depuis un menu de Pkgui (interface avancée)
• Notes et commentaire des paquets, même si je n'aime pas d'exposer de données trop libres aux utilisateurs (si un con écrit un message idiot, des millieurs d'utilisateurs le verront, donc je préfère n'API-ser que ce qui passe par une validation, c'est à dire les news)
• Intégration dans KDE au moyen d'une kio-slave de l'upload vers le site web. J'ai encore des doutes là-dessus, car ownCloud avance bien, et est intégré à KDE, donc un petit ownCloud marchera peut-être mieux (mais c'est du PHP)
• Intégration à Blogilo, client de blog KDE, pour écrire des journaux depuis un client dur.

Et d'autres idées, au fur et à mesure qu'elles me viennent et que les gens me les répètent (aie non non pas taper . Je blague bien entendu ).

Remarquez que le fait que la description des paquets est éditable sur le wiki est déjà un premier pas, comme quoi j'annonce des choses qui en cachent d'autres .

Bonjour,

Du nouveau ! Le découpage de Pkgui en deux partie me permet de plus rapidement implémenter de nouvelles fonctionnalités.

Aujourd'hui, je me suis concentré à rendre la liste des sections plus Michu-friendly.

Avant :

On peut observer que l'interface semble compacte et pas très attirante. La liste des sections les découpe par distro et dépôt.

Après :

La liste des sections est bien plus visible, la liste des actions ne prend plus trop de place. On peut maintenant filtrer indépendamment par section ou par distro/dépôt. Il est ainsi possible d'afficher tous les paquets dans devel, ou tous les paquets de experimental, ou tous les paquets de la section devel dans experimental .

La fusion des sections en provenance de différent dépôts se fait grâce à un système de poids. Par exemple, le serveur officiel de Logram définit la section "base", avec une icône, des descriptions et titres dans plein de langues, etc.

Le dépôt "mondépot" fournit également des paquets dans base, donc il contient une section base, mais sans description ou icône (le dev a autre-chose à faire). Son poids est inférieur, donc libpackageui ira prendre les infos du serveur officiel.

Par contre, le serveur officiel pourra contenir une section «Compatibilité avec Windows», contenant Wine par exemple. Si on active le dépôt de winehd, il contiendra plus d'infos (icône à jour, paquets récents). Ils ajusteront par exemple la description en «Compatibilité avec Windows (dépôt instable activé)», et mettront à leur liste un poids plus élevé. Ainsi, dès que le dépôt Wine externe est activé, la liste des sections est à jour.

Un autre changement est le support des sous-sections. Par exemple, on pourra maintenant placer des paquets dans base/core, etc. Pour le site web et LPM, rien ne change (à part qu'il peut y avoir des slashs dans les noms de sections). C'est libpackageui qui se charge de reconstruire l'arbre. Sur mon screenshot, il y a une section devtools/web, tout simplement .

Cet important travail a été fait pour permettre au Centre Logiciel d'être plus beau et plus efficace, maintenant que les composants sont partagés .

Salut !!

Concernant ton dernier post je vais être rabat-joie, mais je préférais la version précédente... Les onglets c'est classe certes, mais la redondance de titre "Section" c'est bof (mais peut-être temporaire me diras-tu).

Autre remarque, tes screen ont l'air d'être en 800x600, ce pourquoi l'interface donne une impression de lourdeur... J'ai deux suggestions à te faire pour que ça passe mieux dans cette résolution : pourquoi ne pas mettre "Actions à effectuer" dans son propre grand panel, activable via un onglet vertical gauche (comme Kdevelop en est pourvu par exemple [si j'ai bonne mémoire]). Et puis afficher un petit message d'info temporaire en bas de page (style chromium puisque tu l'as tu dois voir) pour avertir l'utilisateur que ledit paquet a été ajouté à la wish list.

Question digne de Mme Michu : à quoi correspond le ~1 dans la colonne "version" ? Je sais que le gestionnaire de paquet de mandriva fait de même et ça m'agace au plus au point. J'imagine que c'est la révision du paquet, mais c'est une information que je ne trouve lourde dans la situation présente. Pareil, la description du paquet, on l'attend dans l'encadré de pied de fenetre, (qui devrait avoir pour titre "Détails" plutôt que le nom du paquet, car redondance avec le titre en bleu qui suit).

Enfin tu gères comme tu veux l'affaire, c'est ton projet. Je conçois bien que c'est une version en plein développement, et justement je me permet de te remonter mes premières impressions.

(qui va se faire frapper par Keisuke)

Justement, et pas que, alors reste sobre si tu le sais d'avance :-°

[edit] et en mode moins frustré de la vie : je trouve chouette que ça avance si bien =) je vais essayer de trouver plus de temps pour regarder ça en détail de mes propres yeux

Bonjour,

En effet, la redondance de «Section» n'est pas une bonne chose. Malheureusement, ça vient avec le contrôle (mais le Centre Logiciel sera architecturé différemment, donc on n'aura pas la sous-fenêtre avec le premier «Sections» ).

Mes screens sont en 800x600 car je ne dépasse pas cette taille avec mes fenêtres. Pense aux netbooks en 1024x600, Logram doit être parfaitement utilisable dessus.

Le coup de l'onglet sur le côté n'est pas mauvais, mais c'est un contrôle KDE, et pas seulement Qt, alors que Pkgui est uniquement en Qt (pour marcher sous Logram DE et éventuellement GNOME). De plus, ce n'est pas michu-compliant (jamais cacher d'informations, toujours tout présenter). Le petit message comble certe le problème, mais là aussi, dire «J'ai ajouté ton paquet» n'est pas suffisant, il faut la liste.

Puis, pour reprendre ce que le dev de Shaman a dit, «It's extremly well suited» . Je suis ouvert aux propositions, je ne refuse pas la tienne pour le plaisir, mais il y a beaucoup de choses à prendre en compte. Peut-être qu'un mockup ou un .ui me convainquera .

le ~1 est bien la révision, qui fait entièrement partie de la version, donc on ne peut pas le retirer. En effet, et surtout dans une distrib rolling-release, la distribution empaquette bien plus que les devs upstream, donc on n'aura que peu de ~1, mais plutôt des ~6, ~17, etc. C'est important, car truc~17 peut contenir une très importante correction par rapport à truc~16. Le changelog est là pour ça.

Pour la petite fenêtre, le titre en bleu est le titre, comme «Navigateur web Firefox». Ce qu'il y a en-dessous est la description courte, égale au titre pour le moment car je n'ai pas eu le temps de bien les faire (empaqueter 15 paquets/jour, c'est dur). La seule mention du nom et de la version est bien le titre de cette fenêtre. La description courte se trouve également dans la liste des paquets.

Tes impressions sont donc intéressantes, mais je ne peux refaire toute une interface pour toi, car rien ne me dit que tu penses comme la majorité. C'est un retour d'impressions continu qui va me permettre de changer Pkgui en mieux, sans oublier que son but premier est la gestion des paquets pour l'utilisateur moyen (pas le débutant qui utilise le Centre Logiciel, ni l'avancé qui utilisé LPM).

Je suis tout à fait d'accord sur le fait que ma vision n'est possiblement pas représentative d'une majorité. Mon besoin se situe sans doute entre celui de Mme Michu (simplissime avec plein d'icones partout), et le power user qui a besoin de connaitre exhaustivement un paquet avant de l'installer.

J'ai compris le message, je vais te faire un .ui de ma conception des choses ;)

Et si cela convient à d'autres, j'aurai plus d'arguments pour parler au décisionaire :p

@god : les unhandled exception veulent ma tete