Merci pour les encouragements et les retours divers
.
farvardin :
Les couleurs ne sont pas folichonnes, mais heureusement ça reste clair de ce fait.
Les couleurs sont faites pour créer des cartes claires, effectivement. C'est un point important. Après aucune des deux personnes impliquées dans le développement du logiciel ne brille par son sens des couleurs, ça peut jouer aussi
. Les suggestions sont les bienvenues dans tous les domaines, mais pour la question des couleurs ça nécessite plus ou moins de redéfinir les couleurs de tous les pays de l'appli à toutes les époques, donc je pense que l'aide est bienvenue mais il faut comprendre dans quoi on se lance.
ewloni :
Pourquoi Java/Swing ? C'est lourd c'est chiant c'est moche, ça rend votre super logiciel presque bon pour la poubelle (sisi). Pour la portabilité je suppose ?
Oui. Et aussi parce que je connais et que c'est assez classique (donc "tout le monde" connaît ; disons par exemple que c'est aussi l'un des langages connus par l'autre personne qui travaille sur le projet ; et par pas mal de monde, ce qui peut être utile à l'occasion ; mais pour de prochains projets je me tourne vers Common Lisp
).
Concrètement, quels autres choix proposez-vous ? Notamment par rapport à vote remarque sur l'intégration ? AWT ? Notez que je ne pense pas me lancer dans une réécriture de l'interface, mais je suis assez curieux.
ewloni :
Pourquoi vous ne respectez pas les interractions classiques dans votre interface ? Cliquer/glisser, deux boutons pour zoom+/-, etc …
Les remarques sur l'ergonomies sont les bienvenues, comme les autres. Par contre le "classique" est assez flou, les conventions varient quand même pas mal d'un logiciel à l'autre ou d'une plate-forme à l'autre. Si vous avez une liste de suggestions, je suis preneur.
- Cliquer/glisser : pour faire glisser quoi par exemple ?
- Deux boutons pour zoom +/- : vous voulez dire presser les deux boutons puis un mouvement de souris, par exemple vers le haut pour zoomer, vers le bas pour s'éloigner ?
- etc : oui, précisez...
Avez-vous déjà pensé à tenter une collaboration avec un autre logiciel (au pif, Marble) ou un autre fond de carte (au pif, OpenStreetMap) ?
Non, ça n'a pas été envisagé. Si vous voulez préciser votre idée, il se peut que ça devienne intéressant. A quelle niveau pensez-vous qu'une collaboration pourrait être utile ?
- Marble a l'air d'être un projet KDE, alors que celui-ci est fait pour être multiplates-formes...
- Pour le fond de carte OpenStreetMap, je ne vois pas trop parce que le niveau de détail des deux applis n'est pas le même. Et pour ce qui est du contour des continents : ben nous en avons déjà un et ça ne change pas beaucoup
.
ewloni :
Vous devriez peut-être penser à le porter sur les tablettes, ça aurait pas mal de succès je pense (Android au moins, à moins qu'on puisse mettre du GPL et du Java sur l'AppStore Apple).
Hum... c'est un monde que je ne connais pas, donc je n'ai pas trop d'avis sur cette question. Par exemple, pourquoi le "porter" : qu'est-ce qui devrait être changé dans le code ? Est-ce que le code Java pourrait poser problème ou est-ce surtout une question d'interface graphique ? Si vous connaissez bien ce monde et que vous êtes prêt à me donner un coup de main, ça peut m'intéresser. Ou quelqu'un d'autre qui passe et qui veut m'aider
.
Pour l'Apple Store je crois qu'il y a un problème avec les logiciels libres. A moins que ça n'ait changé depuis... Et même dans ce cas, ça risque de rechanger au gré des avis d'Apple :s .
ewloni :
Je ne sais pas d'où vous tirés vos textes, mais ça me dérange pas de participer grâce à ça. Ou même de vous faire don du bouquin.
J'ai aussi des bouquins qui recoupent les périodes déjà traitées si ça vous intéresse.
Les textes sont tirés de divers bouquins, autant que je sache. La bibliographie n'est pas encore disponible parce qu'elle n'est pas à jour je crois, mais c'est une information qui devrait apparaître dans une future version. Pour toutes ces questions, je vous propose de prendre contact directement par courriel avec l'autre personne (Patrice) qui travaille sur le logiciel. Ses coordonnées se trouvent dans le menu Aide -> A propos. C'est lui qui travaille sur les textes et il pourra vous renseigner sur ce sujet. Il pourra vous donner la bibliographie, vous dire si votre livre et/ou votre aide l'intéresse. Envoyez-lui un courriel directement ou donnez-moi votre adresse électronique par messagerie privée si vous voulez que je la lui transmette
.
ewloni :
Autre idée d'évolution : des photos des restes archéologiques, des dessins qui reproduisent une scène typique (je sais en logiciel libre c'est dur).
Hum... L'idée peut être intéressante, mais effectivement la question des droits sur les images (photos ou dessins) se pose. Et comment les trouver ou les créer aussi. Si vous avez des suggestions...
FoolEcho :
Je vais ressayer de répondre rapidement pour les remarques sur le code parce que je pense que ça risque d'intéresser assez peu de gens (par exemple tous ceux qui n'ont pas lu le code ne vont pas trop suivre
). Tes remarques sont les bienvenues, mais je pense qu'il vaudrait mieux continuer cette conversation en privé, soit par courriel, que je trouve le plus pratique (mon adresse se trouve dans le code source), soit ici par messagerie privée si tu préfères.
- La documentation technique est en effet assez succincte. Je suis plutôt partisan d'une doc d'architecture et d'une doc de conception expliquant certains points que d'une doc très complète et pas à jour. Maintenant j'ai bien conscience que la documentation actuelle est un peu légère, ton retour sur les points qui t'ont le plus gêné est le bienvenu pour améliorer les "points-clés" et faciliter l'entrée dans le code.
- Concernant les interfaces Java : je suis plutôt du genre à faire simple (parce que c'est plus simple à écrire et à naviguer dans le code). Donc les mécanismes d'extensions un peu partout pour "au cas où" on voudrait modifier telle ou telle partie, je trouve que ça alourdit pas mal le code. Quand le logiciel a vocation à être étendu sur tel ou tel point, c'est bien. Quand ce n'est pas le cas (et que le logiciel n'est pas gigantesque), je préfère faire simple et si le problème se pose on fait quelque chose d'un peu plus abstrait. Dans certains cas le problème va se poser : une interface web est prévue et une partie des données devrait se retrouver dans une base de données, donc il faudra sans doute jouer un peu à l'abstraction, mais on verra sur le moment. Si tu as des remarques plus précises sur les endroits où tu verrais des interfaces, je veux bien les discuter un par un (en privé, parce que là en plus de ne pas intéresser grand monde ça va carrément prendre beaucoup de place dans le fil de discussion
).
- Concernant la Javadoc : ouais, sauf s'il s'agit d'un projet destiné à être "exporté" (bibliothèque ou pas mal de personnes qui travaillent dessus), je ne joue pas trop à ça. Sauf cas de projet "fini" (c'est à dire jamais, ce n'est jamais fini un logiciel
; à part quand c'est livré à un client). En fait je trouve l'intérêt de la Javadoc assez limité pour l'essentiel du code (tout ce qui n'est pas une bibliothèque ou une classe un peu utilitaire qui sert à rassembler des fonctions réutilisables) et en contrepartie c'est un peu lourd à maintenir.
- A propos de ta remarque sur l'intégration Java et le "look and feel" : il me semble que le principe de Swing c'est d'avoir quelque chose qui se présente partout pareil, donc c'est difficile d'obtenir quelque chose qui s'intègre graphiquement à tous les environnements graphiques (au sens de l'allure des composants par exemple). Mais peut-être que ce n'était pas ce que tu voulais dire...
