Ubuntu-fr

philarmonie

Re : [plus maintenu] Manipulation des USplash

Bon travail, c'est très sympa ce que vous faites.
Je vous fais part de mes observations:

@ philarmonie:
- tu mixes les espaces dans ton code python, ça a provoqué des erreurs chez moi. Passe un coup de pylint dessus pour repérer les erreurs (conseil amical sans jugement aucun).
- Ce serait bien de redimentionner l'image à l'ouverture du programme (la visualisation, pas l'image elle même). Sur un écran 8.9', il faut sans cesse déplacer la fenêtre du programme pour tout voir.
- Si une image n'est pas présente (usplash.png), proposer d'office d'ouvrir une image
- Je n'ai pas de barre de menu en haut, c'est normal? Sur le fichier glade fourni plus haut, elle est présente.

Merci pour toutes ces remarques Atlante.

- pour les espaces de noms, je sais et c'est pour ça que je réorganise tout le code. En fait c'est mon premier programme en python, donc j'ai appris des choses au fur et à mesure que j'écrivais mon code; d'où sa mauvaise conception dès le départ.
- pas de soucis pour ça. Au départ j'avais choisi de faire une taille fixe pour faciliter l'écriture de mon code (comme la fenêtre n'est pas redimensionnable, je n'ai pas à gérer les homothéties à faire sur les images). Dans la prochaine version, il sera possible de choisir sa taille et sa visualisation sera dans les proportions de la résolution du thème en cas de thème unique (sinon elle sera en 4/3). Par contre pour choisir la taille de départ à l'ouverture, sais tu comment connaitre la taille de l'écran avec python pour que je puisses fixer une taille adaptée?
- pour la présence de 'usplash.png', c'est parce qu'à la base je l'ai écrit pour l'intégrer au script de Hizoka et l'image était nécessairement présente à l'ouverture d'un thème existant. Si c'était un nouveau thème, le script d'Hizo se serait occupé de choisir une image et ensuite de créer l'image 'usplash.png' dans le dossier du thème.
- pour la barre de menu c'est normal, le script actuelle ne se sert pas du fichier .glade. Celui-ci contient l'UI pour la prochaine version.

Si tu as d'autres remarques ou suggestions, n'hésites pas.

atlante

Re : [plus maintenu] Manipulation des USplash

J'ai aussi appris python comme ça...
Pour la taille de l'écran, en gtk je ne sais pas, j'utilise QT et screenGeometry mais j'ai trouvé ça: http://www.daa.com.au/pipermail/pygtk/2001-March/000925.html
(http://www.koders.com est aussi une aide précieuse pour trouver des infos ou des exemples de code)

Les boutons radio ne sont peut être pas le choix le plus approprié pour les résolutions. Si je les veux toutes sauf le 800X600 ?
Ajouter un champ pour les résolutions personnalisées serait bien aussi (netbook, openmoko, embarqué,...)

- pour la présence de 'usplash.png', c'est parce qu'à la base je l'ai écrit pour l'intégrer au script de Hizoka et l'image était nécessairement présente à l'ouverture d'un thème existant. Si c'était un nouveau thème, le script d'Hizo se serait occupé de choisir une image et ensuite de créer l'image 'usplash.png' dans le dossier du thème.

Je comprends. Rien n'empêche cependant de vérifier et de "compenser" un manque éventuel. Comme ça, si l'image n'est pas créée par le prédécesseur, ce n'est pas ta partie de code qui est mise en cause. Crois moi, ça aide au débuggage!
Et comme je dis toujours (je sais, je me répète), si chaque partie est autonome, elle peut être testée indépendamment (donc plus facilement) et peut être utilisée comme dépendance d'un autre projet sans réinventer la roue et favoriser le LL.
Pensez surtout à bien commenter vos codes et à y mettre un exemple lorsque ça peut être utile.
De plus, en utilisant des tests sur une variable DEBUG, mettre des print sur la console, ce qui aide à voir où on se trouve et le contenu des variables. Il vaut mieux y penser dès le début. Une fois le programme fonctionnel, on repasse DEBUG à 0, c'est propre et facile à réactiver au besoin.

C'est des idées en vrac, vous prenez ce que vous voulez.

PS: intégrez la licence utilisée pour vos codes dans leur entête.

philarmonie

Re : [plus maintenu] Manipulation des USplash

J'ai aussi appris python comme ça...
Pour la taille de l'écran, en gtk je ne sais pas, j'utilise QT et screenGeometry mais j'ai trouvé ça: http://www.daa.com.au/pipermail/pygtk/2001-March/000925.html
(http://www.koders.com est aussi une aide précieuse pour trouver des infos ou des exemples de code)

Merci, je vais y jeter un coup d'oeil

Les boutons radio ne sont peut être pas le choix le plus approprié pour les résolutions. Si je les veux toutes sauf le 800X600 ?
Ajouter un champ pour les résolutions personnalisées serait bien aussi (netbook, openmoko, embarqué,...)

Le choix des résolutions s'était posé et on avait fini par choisir: une seule ou toutes.
Ce choix était partie du principe que soit on se fait un thème perso et alors la résolution utilisée par nos terminaux suffisait, ou alors on fait une thème pour le distribuer et alors on le fait pour toutes les résolutions possibles.
Pour la liste des résolutions possible, ça ne dépend pas de nous, mais des résolutions supportées par grub. Le thème n'utilise pas la résolution utilisée par ton serveur X mais par celle de tes terminaux qui est définie par grub.

Je comprends. Rien n'empêche cependant de vérifier et de "compenser" un manque éventuel. Comme ça, si l'image n'est pas créée par le prédécesseur, ce n'est pas ta partie de code qui est mise en cause. Crois moi, ça aide au débuggage!
Et comme je dis toujours (je sais, je me répète), si chaque partie est autonome, elle peut être testée indépendamment (donc plus facilement) et peut être utilisée comme dépendance d'un autre projet sans réinventer la roue et favoriser le LL.

Très bon conseil, j'y penserai dans le développement de la prochaine version.
J'ai d'ailleurs commencé à rajouter plusieurs fonctions pour checker la présence d'images nécessaires ('uplash.png', 'bar.png'...) ou l'existence du dossier du thème à l'ouverture.
D'ailleurs maintenant je travaille de façon plus modulaire, j'ai séparée les fonctions de traitement des images, gestions des projets, interface graphique... dans des modules différents.
Ça me permet de mieux m'y retrouver dans l'emplacement des fonctionnalités et si un jour je veux modifier leur implémentation se sera plus simple pour moi (en particulier, l'utilisation de gimp ne me plait pas trop la création des images du thème, ça rend mon script trop dépendant des évolutions de gimp. Je suis sûr qu'avec seulement gtk je dois pouvoir faire la même chose vu que gimp est basé dessus).

De plus, en utilisant des tests sur une variable DEBUG, mettre des print sur la console, ce qui aide à voir où on se trouve et le contenu des variables. Il vaut mieux y penser dès le début. Une fois le programme fonctionnel, on repasse DEBUG à 0, c'est propre et facile à réactiver au besoin.

Je l'avais fait sur ma version du script avant de le diffuser. Il suffisait de rajouter l'options '-v' sur la ligne de commande et la variable VERBOSE était alors initialisée à True.
Mais comme un con j'ai merdé et quand j'ai diffusé mon script j'ai effacé cette fonctionnalité

À ce propos, tu sais si y' a une fonctionnalité intégré à python ou un module qui permet de parser la ligne de commande pour récupérer les arguments? Histoire de simplifier la partie de mon code qui sert à analyser les arguments qu'on lui a passé.

Dernière modification par philarmonie (Le 23/12/2008, à 15:06)

atlante

Re : [plus maintenu] Manipulation des USplash

J'utilise ça:

from optparse import OptionParser
parser = OptionParser(usage="see %prog --help for help", version="0.80406-0")
parser.add_option("-f", "--file", dest="filename", default="/etc/zeliconf/zeliconf2.xml",
                  help="traite le fichier FILE", metavar="FILE")
                  
parser.add_option("-c", "--clef", default=False,
                  dest="clef",
                  help=u"clef recherchée")

parser.add_option("-s", "--section", default=False,
                  dest="section",
                  help=u"section contenant la clef")
(options, args) = parser.parse_args()

# on vérifie que le fichier de configuration transmis existe.
if not os.path.isfile(options.filename):
    print "erreur"
    print "Configuration file error: no such file %s" % (options.filename)
    sys.exit(1)
...

Intérêt: tu te concentre sur tes options, et ça te fait le --help tout seul

Dernière modification par atlante (Le 23/12/2008, à 15:25)

atlante

Re : [plus maintenu] Manipulation des USplash

(en particulier, l'utilisation de gimp ne me plait pas trop la création des images du thème, ça rend mon script trop dépendant des évolutions de gimp. Je suis sûr qu'avec seulement gtk je dois pouvoir faire la même chose vu que gimp est basé dessus).

Sans doute, mais c'est à réfléchir. Gimp offre beaucoup de fonctionalités (mais c'est vrai qu'on peut préférer un autre logiciel graphique)
Ce que je ferais pour ça:
- création d'un lien pour le script de gimp. Le fichier de script est "au chaud" dans /etc/monprog et il est lié vers le dossier ~/.gimp-xxx/plugins
- ajout d'une commande qui va créer le lien. Si gimp est mis à jour, il suffit de taper la commande pour recréer le lien et retrouver le plugin
- si tu diffuse ton prog en deb, il suffit d'ajouter la commande à la fin de l'install du deb

Hizoka

Re : [plus maintenu] Manipulation des USplash

pour l'erreur de deb, je revois ca cette nuit je pense.

merci pour tes conseils.

des que j'aurais du temps, j'essairai de me mettre a python aussi.

---

KDE Neon 64bits
Tous mes softs (MKVExtractorQt, HizoSelect, HizoProgress, Qtesseract, Keneric, Services menus...) sont sur github

philarmonie

Re : [plus maintenu] Manipulation des USplash

Je vais jeter un œil à la classe OptionParser, ça me simplifiera beaucoup de code.
Juste une question: la méthode parse_args(), c'est quoi ce 2-tuple qu'elle renvoie?

Sans doute, mais c'est à réfléchir. Gimp offre beaucoup de fonctionalités (mais c'est vrai qu'on peut préférer un autre logiciel graphique)
Ce que je ferais pour ça:
- création d'un lien pour le script de gimp. Le fichier de script est "au chaud" dans /etc/monprog et il est lié vers le dossier ~/.gimp-xxx/plugins
- ajout d'une commande qui va créer le lien. Si gimp est mis à jour, il suffit de taper la commande pour recréer le lien et retrouver le plugin
- si tu diffuse ton prog en deb, il suffit d'ajouter la commande à la fin de l'install du deb

Je procède autrement. Ta méthode reste trop dépendante des mises à jour de gimp. Si l'installe se fait, par exemple, quand l'utilisateur à la version 2.4, le lien symbolique se trouve dans le ~.gimp-2.4. Mais si ensuite il passe à la version 2.6 de Gimp, Gimp ne recherchera plus les plugs-ins dans ce répertoire, et mon script ne fonctionnera plus.
Ce que je fait, c'est utiliser gimp ainsi:

gimp -i -b '(python-fu "command")'

où command est une commande python, et la commande que je mets et:

execfile(create_theme_images.py)\nusplash_mapping(mes,arguments)

où create_theme_images.py et le fichier qui contient la fonction usplash_mapping qui elle permet de créer toutes les images avec la même palette de 256 couleurs. (Ça se trouve au tout début de mon code, c'est la fonction map_all_images)
Ainsi mon code ne dépend, vis à vis de gimp, que de python-fu qui ne fait rien d'autre que exec("command") (cf. son code dans /usr/lib/gimp-2.0) et de sa bibliothèque de base pour la manipulation des images.
Mais globalement, utiliser Gimp pour ça, je trouve que c'est faire appel à une entreprise de travaux publics pour planter un clou chez moi

des que j'aurais du temps, j'essairai de me mettre a python aussi.

Ça serait bien, ça me soulagerai de certain partie du code et d'autant que ça me gène de faire un logiciel dont tu as la "paternité".
Sur le web, tu trouveras des tutos d'initiation au python qui seront suffisant pour implémenter les fonctions dont on a besoin.
Au pire, tu peux toujours continuer à faire des script en bash et la fonction python os.system('mon_script.sh') se chargera de l'exécuter.

Dernière modification par philarmonie (Le 24/12/2008, à 00:33)

Hizoka

Re : [plus maintenu] Manipulation des USplash

en fait je galere beaucoup au niveau comprehension surtout tout ce qui touche le coté graphique...

mais de toute facon,  niveau temps c'est chaud en ce moment.

Bon bah si je suis le papa tu seras la maman

---

KDE Neon 64bits
Tous mes softs (MKVExtractorQt, HizoSelect, HizoProgress, Qtesseract, Keneric, Services menus...) sont sur github

atlante

Re : [plus maintenu] Manipulation des USplash

@ philarmonie:Ce sont les options et les valeurs transmises au script. Plus d'infos sur http://docs.python.org/library/optparse.html
@ hizoka: je peux te filer un coup de main pour le retranscrire (au moins pour ce que je sais faire) mais je n'ai aucune expérience en gtk. Peut être l'occasion de s'y mettre.
Peut être aussi l'occasion de faire un "vrai projet" a plusieurs. Si vous avez besoin, j'ai des serveurs dispo avec ce qu'il faut dessus.

philarmonie

Re : [plus maintenu] Manipulation des USplash

Atlante, si tu veux donner un coup de main, tu es le bienvenu.
Je veux bien m'occuper de la partie GUI, je commence à bien comprendre le fonctionnement de gtk et avec glade ça réduira le code.
Pour l'instant j'ai fait ça:
http://phil.meyn.free.fr/usplash/utm.tar.gz

J'ai regroupé certaines fonctions dans des modules séparées.
Il me manque encore, les fonctions pour:
- créer un .deb du thème
- ouvrir le navigateur par défaut pour rechercher des thèmes sur le net
- recherche de mise à jour du script

Si tu te sens le courage, d'en développer certaines, je suis preneur.
Pour tes serveurs, ça peut être pratique. Mais on pourrait peut être ouvrir une page sur 'launchpad'. Ça permettrait, entre autre, de discuter du développement là-bas plutôt que sur ce fil afin de ne pas trop le polluer.

@ Hizoka: pour les problèmes de compréhension de la partie graphique, si tu as essayé de comprendre sur mon code, c'est normal. J'ai codé ça tellement mal, que même moi j'ai du mal à comprendre ce que j'ai écrit par moment

atlante

Re : [plus maintenu] Manipulation des USplash

Atlante, si tu veux donner un coup de main, tu es le bienvenu.

Avec plaisir

Je veux bien m'occuper de la partie GUI, je commence à bien comprendre le fonctionnement de gtk et avec glade ça réduira le code.

Avec plaisir aussi, j'arrive pas à accrocher avec glade...

J'ai regroupé certaines fonctions dans des modules séparées.
Il me manque encore, les fonctions pour:
- créer un .deb du thème
- ouvrir le navigateur par défaut pour rechercher des thèmes sur le net
- recherche de mise à jour du script

Créer (et personnaliser) un deb, je sais faire.
Pour le navigateur, il existe un module webbrowser (webbrowser.open("http://mapage.html")
Pour la mise à jour, si un deb est fourni, il suffit d'utiliser un dépôt et ça se résoud tout seul. A ce moment, il faudrait séparer la programmation de l'interface de celle des fonctions python (type Usplash-gui et usplash-data)
Sinon, la méthode utilisée par Hizoka (recherche du numéro de version par http et téléchargement de la nouvelle version) est utilisable assez simplement.

Pour tes serveurs, ça peut être pratique. Mais on pourrait peut être ouvrir une page sur 'launchpad'. Ça permettrait, entre autre, de discuter du développement là-bas plutôt que sur ce fil afin de ne pas trop le polluer.

C'est aussi une solution.

@ Hizoka: pour les problèmes de compréhension de la partie graphique, si tu as essayé de comprendre sur mon code, c'est normal. J'ai codé ça tellement mal, que même moi j'ai du mal à comprendre ce que j'ai écrit par moment

Modeste, en plus . A mon avis (je ne suis pas un expert non plus), c'est assez bien codé et commenté. J'ai réussi à m'y retrouver (alors que je suis plus à l'aise avec QT).
Ce qu'il faudrait commencer à faire, c'est un synoptique de fonctionnement du programme complet. Ca permettrait
de découper les différentes actions effectuée (ce qui donne les fonctions python à développer) et partager le travail.
AMHA, ça ne devrait pas être trop difficile, vu que le code de Hizoka est déjà (bien) programmé en fonctions indépendantes. Il reste juste à le "traduire" et à en "pythonyser" l'esprit de fonctionnement.

Attendons l'avis de Hizoka, c'est quand même un peu son bébé

Hizoka

Re : [plus maintenu] Manipulation des USplash

bah y a pas de probleme moi je vous laisse taffer le python et je donne mon avis sur ce qu'il peut manquer ce qu'il faudrait revoir...

j'avais essayé de me mettre a python ya 2mois et j'avais pas tout suivi...

atlante => j'avais essayé qt...
et puis si tu gere le qt on pourrait en faire une version special en qt

je pense pas que ce soit super pratique de gerer un depot...

enfin donnez moi votre avis !

Bonne fete

PS : Pour ceux qui ont 5-10min, si vous pouviez suivre mon lien : generateur de fenetre Zenity dans ma signature ca serait sympa

Dernière modification par Hizoka (Le 24/12/2008, à 18:05)

---

KDE Neon 64bits
Tous mes softs (MKVExtractorQt, HizoSelect, HizoProgress, Qtesseract, Keneric, Services menus...) sont sur github

atlante

Re : [plus maintenu] Manipulation des USplash

Gérer un dépot est simple, d'autant plus si le projet est sur launchpad, c'est automatique.
Si l'interface est séparée du "moteur" python, rien n'empêche de faire une interface en qt et une en gtk. Mais je n'en vois pas trop l'intérêt, l'un et l'autre fonctionnant sur tous les environnements.

vu comment tu codes en bash, tu passeras facilement à python puisque tu as déjà les bon automatismes. Ca se compliquera pour la communication avec les interfaces graphiques (plus pour une question de trouver des infos pertinentes) mais c'est pas insurmontable. De plus, rien n'empêche d'utiliser zenity avec python.

Si tout le monde est d'accord, on ouvre un projet sur launchapad, mais il faudrait lui trouver un nom!
Usplash-generator? easyusplash? usplash4U? ...
Qui ouvre le projet? Je peux m'en charger.

Et Joyeux Noël !

Hizoka

Re : [plus maintenu] Manipulation des USplash

USplash-manager ca vous convient pas ?

oui pour le peu que j'ai vu python, le langage de base devrait passer c'est vraiment les liens entre le script et l'interface graphique...

m'enfin je m'y remettrais quand j'aurai du temps

Joyeux noel

---

KDE Neon 64bits
Tous mes softs (MKVExtractorQt, HizoSelect, HizoProgress, Qtesseract, Keneric, Services menus...) sont sur github

Hizoka

Re : [plus maintenu] Manipulation des USplash

l'interet d'avoir du qt et gtk c'est qu'en fonction de ta distribution tu choisi celui qui est le plus adapté.

1 - meilleur integration
2 - evite d'installer 3 tonnes de paquets supp car tu n'utilises pas gtk ou inversement

voilou

---

KDE Neon 64bits
Tous mes softs (MKVExtractorQt, HizoSelect, HizoProgress, Qtesseract, Keneric, Services menus...) sont sur github

atlante

Re : [plus maintenu] Manipulation des USplash

USplash-manager ca vous convient pas ?

En effet. Mais quand j'avais fait une recherche d'antériorité dans le cache, j'avais vu que c'était déjà pris, sans me rendre compte qu'il s'agissait de ton deb ...

J'ai ouvert un projet sur launchpad : https://launchpad.net/usplash-manager
J'ai mis une licence en LGPL v3 en attendant, mais je serais plus pour du GPL. Ca fait partie des points à discuter.

Il vous suffit de vous enregistrer
https://launchpad.net/usplash-manager/+login
et de demander de faire partie de la team créée pour l'occasion
https://launchpad.net/~usplash-manager

C'est ma première utilisation de launchpad, ayant plutôt l'habitude de travailler seul. Une expérience supplémentaire.

PS: j'espère que le père noel vous a gâté. Dans mon cas, je m'éclate sur un netbook

philarmonie

Re : [plus maintenu] Manipulation des USplash

C'est bon je me suis inscrit et rajouter à la team
C'est aussi ma première utilisation de launchpad, je vais jeter un coup d'œil sur les fonctionnalités qu'il propose.

Je suis complètement d'accord sur le fait de séparer l'interface graphique du moteur python, c'est ce que j'ai déjà commencé à faire. Outre la possibilité de pouvoir faire plusieurs interfaces graphiques, ça facilitera la maintenance et l'évolution du programme.

Pour ce qui est de faire une interface en qt, pourquoi pas, mais moi je m'occupe seulement de celle en gtk.
De toute façon le programme nécessite la présence de gtk et pygtk par l'utilisation qui est faite de gimp; et ces paquets sont sans  doute installé avec gimp qui en a besoin pour fonctionner.

En ce qui concerne le synopsis, dans un premier temps, je pense que le modèle d'interface en qt faite pas Hizoka défini bien les fonctionnalités que doit offrir le programme. J'en ai déjà codé certaines, on pourra discuter sur launchpad de la répartition des taches pour leur implémentation.

La GUI principale (celle que Hizoka à faite en qt) est faite, il faut maintenant finir le moteur pour que je puisse en appeler les fonctions à partir de l'interface.

Là je vais m'occuper de refaire le code de l'interface de création du thème.

J'espère que votre réveillon s'est bien passé et vous souhaites un joyeux noël à tous!

atlante

Re : [plus maintenu] Manipulation des USplash

J'ai commencé aussi
J'ai créé un synoptique qui peut nous permettre de lancer les bases. Voir http://dldivers.absolacom.com/ où je propose une structuration avec:
usplash-manager-data (moteur (classes et fonctions))
usplash-manager-gui-gtk (interface en gtk)
usplash-manager-gui-qt (interface en qt)

Je me charge de la partie qt. Je vous propose rapidement une interface bidon pour définir les orientations.

J'ai demandé l'ouverture d'une liste de discutions sur launchpad, je vous informerais quand elle sera ouverte.

Edit:
L'interface première version. Rien ne fonctionne, c'est juste pour qu'on en discute: http://dldivers.absolacom.com/usplash-manager.zip

Dernière modification par atlante (Le 26/12/2008, à 16:44)

philarmonie

Re : [plus maintenu] Manipulation des USplash

J'ai pas accès à ton serveur, firefox me dit qu'il est indisponible

Pour la structuration que tu proposes, c'est 3 fichiers ou 3 dossiers?
Parce que dans ce que j'ai commencé à faire j'ai plusieurs fichiers pour le moteur, où je regroupe le traitement des images dans un modules, la gestion des thèmes dans un autre...
Pareil pour la GUI, je fait deux modules: un pour la fenêtre principale et un autre pour celle de personnalisation du thème.
Jette un œil sur cette archive pour voir comment j'ai découpé les différents modules (elle n'est pas à jour mais ça donne une idée): http://phil.meyn.free.fr/usplash/utm.tar.gz

Je préfère faire plusieurs petits fichiers, qu'un gros, je trouve que ça facilite la gestion du code et c'est plus simple ensuite pour s'y retrouver et faire des modifications.

Pour discuter du synoptique et de la répartition des taches, on peut faire ça sur launchpad?

Hizoka

Re : [plus maintenu] Manipulation des USplash

je fais noel ce soir, et je taf demain et dimanche, donc la je suis pas trop le truc mais en debut de semaine je m'inscris

---

KDE Neon 64bits
Tous mes softs (MKVExtractorQt, HizoSelect, HizoProgress, Qtesseract, Keneric, Services menus...) sont sur github

atlante

Re : [plus maintenu] Manipulation des USplash

J'ai pas accès à ton serveur, firefox me dit qu'il est indisponible

Résolu. J'ai déplacé la DMZ, et oublié de recharger les bonnes règles iptables...:/
Réparé

Pour la structuration que tu proposes, c'est 3 fichiers ou 3 dossiers?
Parce que dans ce que j'ai commencé à faire j'ai plusieurs fichiers pour le moteur, où je regroupe le traitement des images dans un modules, la gestion des thèmes dans un autre...
Pareil pour la GUI, je fait deux modules: un pour la fenêtre principale et un autre pour celle de personnalisation du thème.
Jette un œil sur cette archive pour voir comment j'ai découpé les différents modules (elle n'est pas à jour mais ça donne une idée): http://phil.meyn.free.fr/usplash/utm.tar.gz

3 dossiers (qui peuvent contenir des dossiers et fichiers) et qui deviendront à terme des paquets deb individuels.

Je préfère faire plusieurs petits fichiers, qu'un gros, je trouve que ça facilite la gestion du code et c'est plus simple ensuite pour s'y retrouver et faire des modifications.

Moi aussi, dans une certaine mesure. Mais la partie data sera la même utilisée, quelle que soit l'interface (simplification de maintenance). Tout ce qui ne fait pas appel à quelque chose de graphique (relevé du usplash utilisé, liste des projets, ...) sera en data et retournera les valeurs nécessaire.
Vois l'ébauche de data qui est sur http://dldivers.absolacom.com (vraiment une ébauche, juste pour l'exemple)
De toute façon, cette partie là étant commune aux deux interfaces, il faudra qu'on voit comment on la développe.
[ après visu de ton archive]
Exactement comme ça. Tes fichiers *util sont indépendant de l'interface graphique, et peuvent être utilisés quelle que soit l'interface. Ces fichiers peuvent être mis dans le paquet data.
Mais il va falloir qu'on discute de la façon de coder (longueur des indentations (tu utilises un coup 4 espaces, un coup 3), des conventions de nommage des variables, ...). Je dis ça parce que si tout est identique dans les conventions, il est plus facile de générer des tests automatiques pour le débuggage, de scripter des traceurs ou de la récupération d'information (génération de doc automatique,...)

Pour discuter du synoptique et de la répartition des taches, on peut faire ça sur launchpad?

D'après ce que j'ai vu, launchpad permet de créer une liste de discussion, mais ça doit être validé par la launchpad team. J'ai fait la demande, on verra. Au pire, je met rapidement un serveur de liste en place pour en avoir une.
Launchpad permet la répartition des tâches et l'organisation d'un planning, mais je n'ai pas vu de moyen de discuter autour des projets, ou la possibilité de mettre en ligne des fichiers à partager (autrement que dans une branche).
J'avoue qu'il y a certaines choses que je n'ai pas vraiment comprises, donc comme j'ai créé les parties, j'ai peut être des droits que vous n'avez pas, ou fait des réglages arbitraires. N'hésitez pas à me le signaler.

Edit:@hizoka:
fait ton noel et ton taf tranquille. Moi j'ai du temps de libre, j'en profite (ça ne durera peut être pas). Je réfléchis et bosse un peu au truc, mais pas de pression. La famille avant tout.

Dernière modification par atlante (Le 26/12/2008, à 19:49)

philarmonie

Re : [plus maintenu] Manipulation des USplash

C'est bon Atlante, j'ai pu voir ton synopsis qui me semble parfait (tu fais ça avec quel logiciel?) ainsi que ton interface graphique. Son agencement en menu me plait bien, je vais modifier la mienne pour qu'elle lui ressemble.

Après niveau terminologie, je pense qu'il serait mieux d'utiliser "projet" pour parler des projets de thèmes gérés par notre programme (comme c'est déjà le cas) et "thème" plutôt que ".so" pour parler d'un thème compilé. ".so" (librairie dynamique pour un programme en C) est moins parlant pour l'utilisateur que "thème". On peut aussi envisager de choisir "thème usplash" pour être encore plus explicite.

Dans le menu "usplash > choisir", le choix ne doit pas se limiter aux thèmes des projets mais à tous les thèmes installés sur le disque (il y a donc en plus le thème par défaut plus tous ceux rajouter à la main par l'utilisateur). Les 3 entrées pourraient avoir comme label:
- Choisir le thème de Usplash
- Choisir aléatoirement un thème pour Usplash
- Choisir aléatoirement un thème au démarrage

Pour les entrées "Ajouter un .so" et "Télécharger des usplash", je verrai plutôt "Ajouter un thème"et "Télécharger des thèmes".

Au niveau de l'organisation du code, je suis d'accord pour la découpe en 3 répertoires. Je m'occupe de la GUI en gtk, et je veux bien me mettre à écrire la classe 'UsplashProject'.
Pour l'indentation, je les ferai toutes de '3 espaces'. Au niveau des noms de variables, fonctions et classes, je pense qu'il serait bien de choisir des termes anglais (projet libre oblige). Après on peut discuter sur des conventions de nommage.

Enfin pour la licence, je pencherai aussi plus pour une GPL.

@Hizoka: passe un bon réveillon! comme atlante j'ai du temps en ce moment, donc y'a pas de soucis si tu peux pas être trop disponible.

Edit: Atlante, en attendant d'avoir une liste de discussion, tu peux toujours prendre mon adresse msn dans mon profil.

Dernière modification par philarmonie (Le 26/12/2008, à 20:27)

Hizoka

Re : [plus maintenu] Manipulation des USplash

je suis d'accord avec philarmonie sur la terminologie.

En effet, j'aime bien la tete de ton interface atlante.

mais la je suis un pe a la ramasse par rapport a votre taf pige pas tout

---

KDE Neon 64bits
Tous mes softs (MKVExtractorQt, HizoSelect, HizoProgress, Qtesseract, Keneric, Services menus...) sont sur github

atlante

Re : [plus maintenu] Manipulation des USplash

Le diagramme est créé avec le logiciel dia (apt-get install dia). Il permet de faire des choses sympathiques.
J'ai mis à jour l'archive de la maquette de l'interface avec les labels. Dites moi ce que vous en pensez.

jobastr

Re : [plus maintenu] Manipulation des USplash

Bonsoir,
Je ne comprends pas grand chose à vos délibérations, mais je suis admiratif quand au résultat à venir, mais j'ai un petit souci

Je suis sous Linux Mint, j'ai tout d'abord installé le thème usplash d'ubuntu via synaptic, pour voir si je pouvais changer de thème sans problème, j'ai mis ce dernier en place, et ensuite j'ai voulu remettre celui de Linux Mint, et là, à la fermeture j'ai le bon thème, mais au redémarrage, j'ai toujours celui d'ubuntu, j'ai ensuite créé un thème sans problème, je l'ai installé et toujours le même problème.

Si vous pouviez m'aider ce serait sympa, merci

Dernière modification par jobastr (Le 28/12/2008, à 22:39)