Discussion :

[Emgoku]

Bonjour,

Pas évident d'être explicite dans le sujet.

Je souhaiterai me remettre à la programmation

J'ai, il y a bien longtemps ;-) , pas mal programmé en AMOS et STOS pour ceux qui connaissent / se rappellent , et "bidouillé" en assembleur, toujours sur AMIGA et ATARI ST. Puis j'ai un peu pratiqué Delphi sur PC

Depuis une quinzaine d'année, plus rien.

Le logiciel que je souhaite essayer de réaliser devra :

- charger des PDF et photo + les manipuler (mise à l'échelle, rotation, sauvegarde, etc.)

- insérer des graphismes (carré, rectangle, cercle, etc.)

- et surtout, je voudrai pouvoir tracer un trait d'un point A vers un point B (en non pas jusqu'à B) en contournant les graphismes que j'aurai ajouté

- si mon "trait" fait 100 points, il part du point A vers le point B. Mais si il rencontre un obstacle (ex, un carré), il le contourne dans la limite des 100 points

- être une appli autonome (exécuter depuis une clé usb par exemple)

- idéalement, pouvoir le rendre multi-plateforme par la suite (mais ce n'est pas la priorité)

Que me conseillez-vous comme langage de programmation pour ce type de logiciel (sur windows)?

Est-ce que , même si c'est un utilitaire, une orientation jeu vidéo , pour les graphismes, repérage obstacle, peut être un bon choix (C# + Unity par exemple)

Windev, C#, java, python?

en vous remerciant par avance

[joel.drigo]

Salut,

C'est probablement faisable dans la plupart des langages que tu cites, et, en tout cas, je confirme que c'est faisable en Java. Je pourrais dire aisément parce que je sais déjà comment je le ferais, puisque je connais déjà bien ce langage, et que j'ai déjà réalisé des applications du genre (manipulation d'image, génération de pdf, dessin vectoriel interactif...). Mais quelqu'un qui n'a jamais pratiqué Java (même s'il a déjà pratiqué d'autres langages et qu'il connait au moins les bases de la programmation structurée, voire orientée objet) , ça va demander un apprentissage préparatoire conséquent et ensuite pas mal de boulot.

[foetus]

Je ne suis pas d'accord avec joel.drigo : l'application est simple, c'est juste un canvas graphique qui peut être fait en OpenGL (ou une surcouche comme SDL). Par contre, la difficulté c'est sur les importations/ exportations:

• Importation d'un fichier PDF et transformation en objets graphiques de ton canvas
• Importation d'une image et ajout d'un objet image dans ton canvas
• Algorithme "path"/ détection de collisions/ ... pour tracer des lignes ou autres
• [Penser à]/ [Utiliser] un format de ficher pour exporter tous tes objets graphiques présent sur ton canvas (qui peut être un bête fichier CVS ou JSON)

Évidemment un tel canvas à coder est un peu ardu, parce qu'il faut

• surcharger un grand nombre d'évènements: clic, double-clic, déplacement souris, déplacer-glisser/coller, pinch, ...
• avoir une bonne gestion des objets graphiques présent sur ton canvas pour une détection rapide lorsqu'un évènement arrive, une bonne gestion du hors-écran, ...
• éventuellement gérer la profondeur (z-index) parce que tes objets peuvent se chevaucher
• éventuellement avoir un système undo/ redo avec des actions/ commandes
• éventuellement une bonne gestion des unités de mesures/ grille/ zoom parce que si le but c'est d'exportation en fichier PDF, alors une page c'est du A4

Pour le multiplateforme, c'est simple, il faut utiliser que des bibliothèques multiplateformes (OpenGL et SDL le sont) et coder le plus "conventionnellement" possible et éviter autant que faire se peut les spécificités des OSs (API, extensions, format de fichier propriétaire, ...) (<- sinon gérer les cas particuliers)

Pour l'application autonome, c'est aussi simple. C'est la gestion des ressources externes qu'il faut attention: images, dlls, icônes, ...
Toutes les ressources doivent être soit à la racine de tout exécutable dans des dossiers (**) soit à l'intérieur de ton application (*) (et dans ce cas privilégier les bibliothèques statiques .lib/.so aux bibliothèques dynamiques .dll/.a)

* -> avec ce type d'application, [on peut]/ [il faut] tester l'existence des ressources et recréer arborescence au besoin de la première solution (**)

[joel.drigo]

Ai-je écrit que c'était complexe ?

l'application est simple

Par contre, la difficulté

Évidemment un tel canvas à coder est un peu ardu

Simple mais ardu...

En quoi est-ce si en désaccord avec ce que j'ai écrit ? Tout ce que tu cites demande forcément un apprentissage pour celui qui n'en a jamais fait, que ça soit sur OpenGL/SDL ou n'importe quoi d'autre, mais est accessible aisément à celui qui maîtrise tout ça. Et ça demande quand même pas mal de travail.

[foetus]

Simple mais ardu...

Le simple ne porte pas sur la difficulté. Simple est plus connoté moderne/ épuré: pas de gros menus, pas de rubans/ pas X [sous-]fenêtres à gérer.
L'application peut avoir juste une fenêtre principale, avec le canvas qui prend une gros partie de cette fenêtre et un menu simple au clic droit.

En quoi est-ce si en désaccord avec ce que j'ai écrit ?

C'est du pignolage je voulais dire que les connaissances informatique ne sont pas trop conséquentes, le nombre de bibliothèques [peut être] très très restreint.
Par contre le notions mathématiques, la connaissance des formats de fichiers (PDF par exemple), un peu typographie, me semble plus nécessaire avant tout.

Après, on est d'accord : pour la maintenance, l'évolution, les optimisations, les temps de chargement, ... il faut ensuite connaître nettement plus de notions en informatique.

[joel.drigo]

Le simple ne porte pas sur la difficulté. Simple est plus connoté moderne/ épuré: pas de gros menus, pas de rubans/ pas X [sous-]fenêtres à gérer.
L'application peut avoir juste une fenêtre principale, avec le canvas qui prend une gros partie de cette fenêtre et un menu simple au clic droit.

A ce sujet, je suis d'accord. Mon propos ne concernait de toute manière pas l'interface, mais le fonctionnel. Tant que le noyau est bien conçu, on peut commencer avec une interface minimum, et faire ce qu'on veut ensuite (multidoc ou pas, undo/redo si on veut, gestion des fichiers (filesystem, cloud, git ou tout ce qu'on peut imaginer).

Par contre le notions mathématiques,

A ce sujet (et par extension, les notions algorithmiques), je dirais que même si on ne les maîtrise/connait pas, on peut trouver assez facilement tout ça sur Internet. Et même pour ce genre de choses, on peut trouver des bibliothèques (par exemple pour l'histoire du tracé de lignes que @Emgoku décrit). Dans le cas idéal, l'application peut être un simple assemblage d'un framework (genre Eclipse en ce qui me concerne) et bibliothèques, le code perso n'étant qu'un peu de glue

la connaissance des formats de fichiers (PDF par exemple)

Justement, tant qu'il existe les bibliothèques adéquates pour le langage choisi, ça ne demande pas forcément une grande maîtrise, mais juste de savoir lire une doc (et que la bibliothèque existe). Ma connaissance du format PDF est bien en deça de ma ma connaissance de l'utilisation des bibliothèques "PDF" de Java, et je m'en fous, parce que ce que je veux c'est essentiellement produire des documents PDF, pas savoir comment sont foutus les fichiers