Les utilisateurs de DT sont de plus en plus nombreux sous Windows.
Pour ma part, j’utilise Linux et Windows, avec une appréciation différentiée des 2 environnements, sans ouvrir de débat.
Lorsque je me suis présenté sur ce forum, j’ai annoncé vouloir m’investir dans le développement de DT au sens large (pas que du codage).
Professionnellement, je suis un chef de projets informatique expérimenté. Je ne dis pas cela pour me vanter, mais pour indiquer mon niveau de compétence au groupe de développeur. En attendant de faire mes preuves pour vous.
J’ai demandé comment commencer efficacement, mais je n’ai pas (encore) eu de réponse très constructive, juste quelques indications. Je suis sur que cela va venir.
Je propose de rédiger un guide d’accueil pour les développeurs, au delà des règles de codage :
[list]
[]environnement de développement
[]architecture logiciel
[*]outils utilisés (pour la rédaction de la documentation et de ses traduction)
[/list]
Je pense que si on veut attirer des contributeurs, il faut leur faciliter la prise en main de l’environnement.
L’affichage se fait en prenant en compte latitude et longitude des images.
(Vincent Bourganel est informaticien. Il crée des thèmes pour le logiciel Zenphoto.)
J’ai déjà réalisé des applications de cartographie. Je pense pouvoir m’occuper de cela.
Quand tu parles d’améliorer la carte, est-ce que tu parles de l’aspect général de l’écran CARTE, ou uniquement du fond de carte.
En attendant, je me suis lancé dans la compilation de DT sous mingw-64. J’y suis arrivé,
Une bonne nouvelle pour les utilisateurs Windows. Peter Budai qui est le seul a maintenir le port Windows recherche de l’aide pour partager le travail car il manque de temps. Donc si tu es prêt une tâche que tu peux faire est de préparer les releases si ça te va ?
Ensuite, il y a pas mal de problèmes reportés par des utilisateurs Windows que personne ou presque ne regarde car sans environnement Windows pour développer. C’est aussi ici que tu peux prendre la main et proposer des PR sur GitHub.
Tout cela ne sont que des propositions, chacun doit trouver sa voie et surtout faire ce qu’il aime faire… C’est la seule solution pour un investissement perenne.
Je suis Pascal ici, TurboGit sur GitHub et je suis actuellement en charge des releases dt et développeur depuis plusieurs années sur dt.
Bonjour,
en ce qui me concerne, il n’y a aucun problème avec les fonds cartographiques. La géolocalisation directe fonctionne bien et la sélection d’une image déjà localisée depuis la table lumineuse l’affiche bien dans la module carte.
Le seul point qui reste à améliorer (en tout cas pour moi) est que les coordonnées gps soient inscrites aussi dans les champs exifs correspondants de l’image originale et pas seulement dans le xmp . Peu m’importe que ces coordonnées soient transmises à l’export, ce qui me serait utile, c’est qu’elles soient aussi présentes dans l’original comme on peut le faire avec les outils tiers comme geosetter par exemple.
Cdlt
Les cartes et la présentation de l’écran c’est pas le problème. Tout va bien. C’est juste l’apparition des images localisées sous forme de cercles de couleurs puis en zoomant les repères bleus puis en cliquant sur ces repères bleus voir l’image
Quand il y a beaucoup de photos sur un petit endroit géographique la présentation de Vincent Bourganel est plus facile et plus fluide.
Je pense que tu pourrais améliorer la présentation pour éviter le « tas » de vignettes sur une ville par exemple qui n’est ni pratique ni esthétique.
Je pense que je vais commencer par aider Peter Budai sur la version Windows. Car DT a tout intérêt à devenir populaire sur cet environnement. Il va falloir que je contacte en anglais car je doute qu’il suive ce forum.
J’ai d’abord besoin de découvrir le code de l’application, car il est conséquent et assez peu documenté semble-t-il.
Quels sont les usages ? Chacun se débrouille avec le code, ou est-ce qu’un mentor est disponible pour aider à défricher ?
En anglais, la liste de diffusion mail développeurs (donc tous les développeurs darktable) dont tu trouveras le lien d’accès (et plus d’infos sur le développement de darktable) ici : https://www.darktable.org/development/
Tu as aussi un IRC, etc., mais c’est listé sur le lien précédent (et IRC et moi…).
Quels sont les usages ? Chacun se débrouille avec le code, ou est-ce qu’un mentor est disponible pour aider à défricher ?
Mon expérience est qu’il faut beaucoup s’investir sur la connaissance du code. Comme tu l’as toi même constaté, il n’y a pas de « chef » et par conséquent aucune « obligation » de documentation. Tout ça est inhérent au modèle de développement du logiciel libre.
Il existe cependant quelques recommandations de codage disponibles sur redmine.darktable.org (H.S aujourd’hui)
Aurélien a également mis en ligne une roadmap qui concerne surtout les développements autour des module de développement.
Quels sont les usages ? Chacun se débrouille avec le code, ou est-ce qu’un mentor est disponible pour aider à défricher ?
Oui c’est un peu cela. Chacun se débrouille et travail sur un point qui lui tien à cœur. Au préalable c’est toujours bien d’en discuter car travailler des jours sur un point rejeté n’est jamais très plaisant.
Donc, tu peux créer des « issues » sur GitHub par exemple en présentant un bug ou une nouvelle fonctionnalité. Différents devs répondront, parfois je suis un peu long car je ne peux pas tout suivre. Tu peux utiliser le @ pour attirer l’attention ou si tu as besoin de retours. Il y a aussi le canal dev de Matrix comme le disais @nicoauffray.
Partant également pour donner un coup de main pour la compil sous Windows.
Je suis en train de me monter des environnements (VM + docker).
J’ai pu compilé Darktable via la console mingw-64 et avec VsCode (bcp plus pratique pour débugger). Je mets le tout par écrit histoire que ça puisse profiter à d’autres.
Le code est assez touffu, mais compréhensible, mais manque un peu de cohérence à mon sens. Une mise à plat ne fera pas de mal. J’ai conscience du boulot que ça implique, mais par moment, il vaut mieux « casser » pour reconstruire correctement.
Petite question (sans polémique aucune) aux anciens : avez-vous une idée du pourquoi être resté sur la combinaison C/GTK3 ? Cela ne pourrait-il pas nuire à la pérennité de la maintenance du soft ?
@Loukournan29, tu proposais de rédiger un guide d’accueil pour les développeurs, avais-tu une idée précise ? Sous quelle forme ?
Et tu proposerais quoi en échange (sans polémique ). Moi, je pense que C/GTK est une solution perenne. En plus je connais pas vraiment les solutions portables entre différents systèmes.
Les JS/Node/CSS/HTML j’aime pas. Et c’est pas adapté côté performances.
Après je sais pas où est historiquement la compatibilité entre chaque GTK N et GTK N-1.
J’imagine que récrire tout c’est un boulot monstre. Changer le toolkit graphique n’est pas une mince affaire non plus (j’ai programmé pas mal il y a très très longtemps en C/GTK, puis C++/Qt maintenant plutôt Python/Qt, mais c’est pas le cœur de mon travail et j’ai pas les besoin de performances). Faire une nouvelle couche toolkit GUI ? Le libre office le fait toujours ou ils on basculé sur quoi ? J’ai pas suivi depuis trop longtemps.
Les JS/Node/CSS/HTML sont même pas fait pour ça. Déjà, Gtk4 est toujours en développement et n’est pas sorti. La plupart des applications, l’environnement Gnome compris, utilisent Gtk3. Gimp, pour lequel Gtk a été créé, n’est même pas encore officiellement en Gtk3. La version officielle 2.10.22 actuelle est toujours sur Gtk2. Gimp 3.0 approche et sera sous Gtk3.
Quand au C, j’ai souvenir d’avoir lu des débats sur le sujet pour passer au C++ avec des avantages et inconvénients évoqués mais là, c’est hors de mes compétences.
En tout cas oui tout réécrire est un boulot monstre. Et un des fondateurs de darktable a d’ailleurs commencé ce travail en programmant darktable en C/Vulkan (Vulkan remplaçant Gtk). Après, ça reste expérimental et encore loin en fonctionnalités de darktable. Le code de ce, peut-être (ou pas, ça aussi ça a fait et fait toujours débat), futur darktable : https://github.com/hanatos/vkdt
). Moi, je pense que C/GTK est une solution perenne. En plus je connais pas vraiment les solutions portables entre différents systèmes.