Au départ j'ai proposé à Fred de développer le projet sous Qt en langage C,C++. Mais je ne connais pas (encore) Qt, donc cette proposition impliquait une période d'apprentissage pour moi.

Puis, comme je faisais mon propre tableau, il m'est venu l'idée de réaliser ça sous OpenOffice. Là je connais, j'ai déjà développé de petites applications avec oooBasic, donc j'économise sur l'apprentissage. L'autre avantage est que la communauté OOo est nombreuse et qu'on pourra y trouver de l'aide sans problème.

Comme je suis un ardent défenseur des logiciels libres depuis plus de dix ans(presque 15), quelque soit la plateforme de développement les sources seront ouverts et placé sous la licence GPL (ou à la rigueur LGPL).

Donc la voie actuelle du développement est OpenOffice.

Dans le message suivant je vais décrire ce qui me paraît être les atouts de ce choix.


   [ Message modifié par  favdb  le  17-08-2010  à  20:58 ] 

Choix de OOo : les avantages

En premier lieu OOo est lui même un logiciel ouvert. Tout un chacun, pour peu qu'il en ait le courage, peut aller farfouiller dans les sources pour trouver son bonheur. Mais attention il vaut mieux en savoir un bout sur la programmation en C++ et s'armer de beaucoup de patience. En effet, j'ai été confronté à une difficulté pour l'utilisation et la programmation d'une fonction particulière. Malgré mes demandes d'aide je n'ai pas trouvé de solution satisfaisante. J'ai donc entrepris de rechercher dans le code l'endroit qui m'intéressait pour éventuellement proposer une modification qui me satisfasse. Je dois bien avouer qu'après quelques semaines j'ai abandonné et j'ai solutionné mon problème autrement (mais de manière moins élégante).

Ceci dit oooBasic me paraît assez simple à apprendre et la macros développées sont très performantes. On en trouve d'ailleurs de très complexes.

Autre avantage, sans forcément programmer on peut tout à fait réaliser la représentation d'un tableau électrique avec les différents outils, en particulier Draw l'outil de dessin. En combinant les trois outils de base (Draw pour le dessin, Calc pour les tableaux, et Writer pour le texte) on obtient une plateforme qui prend parfaitement en charge tout les aspects graphiques qui sont les plus délicats à programmer.

En plus je suis issu de l'informatique de gestion, donc le traitement des données (numériques ou non) je sais faire.

Dans un second temps, lorsque nous aurons atteint un stade acceptable nous serons toujours à temps de redévelopper tout ça en C++.

Reprise du débat ici.

Donc le développement a atteint un stade "intéressant" sous OOoBasic. La structure générale du code et de sa dynamique globale touche aux limites de ce que peut faire OOoBasic. Ainsi j'ai été obligé de re-écrire la partie graphique pour abandonner l'utilisation du "quadrillage" offert par Calc, du fait du manque de précision qui se manifeste en fonction des plate-formes (Windows ou Linux) ou des niveaux de zoom. J'ai donc programmé cette partie en n'utilisant que des fonctions de dessin.

La question de la plate-forme du langage reste cependant ouverte. Certains limitations sous OOoBasic ne permettent pas d'améliorer véritablement l'interface utilisateur. Ainsi OOoBasic ne permet pas l'usage des onglets, ce qui dans le cas de notre projet serait un véritable plus en terme de convivialité.

Une première option serait de reprendre le code existant sous Java. Ceci permettrait de rester dans le contexte OOo puisque les passerelles existent entre Java et OOo. Ainsi toutes les données, paramètres du logiciel et données de l'utilisateur, pourraient toujours être mémorisés sous forme de fichiers OOo. L'inconvénient est que le package livrable se présenterait sous la forme de deux fichier séparé (au moins), le programme Java d'un côté le fichier initial de paramètres de l'autre. Je dois dire que j'aime mieux l'idée de n'avoir qu'un seul fichier à distribuer.

Par ailleurs Java a aussi ses limitations en terme d'interface graphique. Ainsi, je trouve que les fonctions de base ne produisent pas une interface "à mon goût" d'un point de vue esthétique. L'intérêt majeur de Java, comme d'OOo, est d'être compatible intrinsèquement avec toutes les plate-formes (Windows, Linux et Mac) sans aucune adaptation particulière.

L'autre alternative demeure la programmation sous C++, avec l'IDE Qt. Là c'est le gain de la liberté totale dans toutes les fonctionnalités de visualisation. La contrepartie est la complexité technique qui exige un investissement dans la maîtrise du langage et de l'IDE de Qt.

Ce sujet reste donc ouvert, et les avis y sont les bienvenus. Que vous soyez informaticien de haut niveau, programmeur amateur, ou un simple utilisateur, vous êtes donc cordialement invités à participer à ce brain-storming. Donnez vos avis permettra non seulement d'orienter le choix des développements futurs mais aussi, certainement, de répondre au mieux à vos besoins.


   [ Message modifié par  favdb  le  06-11-2010  à  11:20 ] 

"...et les avis y sont les bienvenus"
Alors je donne le mien

La durée de vie de entraidelec.com, la richesse et la qualité de son contenu semble indiqué une bonne maîtrise du média Internet et de ses implications techniques.
Plutôt que de s'orienter vers une "application traditionnelle", pourquoi ne pas envisager une "application online" ?
Le développement serait certainement assuré en PHP / mySQL. FavDB y trouverez-vous votre compte à vous former à PHP plutôt que Qt ?
La communauté PHP / mySQL est ... vaste ! On y côtoie le meilleur comme le pire

En imaginant que la paternité en revienne à entraidelec.com et que l'équipe responsable assume l'hébergement de l'application et des données, on peut imaginer des fonctions sympas comme le partage d'un tableau en cas de soucis technique pour illustrer un post dans le forum.

Les mises à jours sont instantanées pour tout le monde. Inutile de développer un module idoine ; les utilisateurs n'ont pas à télécharger des patch, etc ...

Sous réserve de validation technique les graphismes peuvent être correctement traités avec PHP. Mais il existe de nombreuses solutions complémentaires comme le Flash ou le PDF.
C'est mon manque de connaissance du "cahier des charges" qui m'empêche d'être plus précis ici.

L'application gère une bdd en ligne. C'est trés souple : un simple dijoncteur peut être graphiquement mis à jour et "hop", tous les schémas déjà réalisés sont mis à jour

Cette approche à son lot de contraintes qu'il faut assumer !
Par exemple les schémas seront enregistré sur le serveur. L'hébergeur du système à donc des responsabilités de sauvegarde. Evidement un utilisateur averti fera des exports sur son ordinateur et des impressions PDF ou papier.

Finalement, il existe tout un cadre juridique adapté pour le partage sur Internet (licences), comme Creative Commons ou le GPL déjà évoqué ...

J'arrête là car il ne s'agit que d'un avis. Mais il y aurait long à dire.
Je peux ajouter ceci : je dois sérieusement me plonger dans l'électricité (en tri) chez moi et j'ai quelques compétences polyvalentes (graphisme, dev).
Alors participer au projet me permettrais d'acquérir les compétences nécessaires en électricité tout en "renvoyant la balle" ...

Cordialement.

Salut Renaud,

Ta suggestion est tout à fait fondée. J'avais effectivement pensé à faire ça aussi sous PHP/MySQL, mais, outre la partie strictement programmation, il y a je pense quelques difficultés autres.

Ainsi, et tu y fais allusion, il y a l'aspect du partage de l'information, genre : je fais un schéma, je le partage pour avoir des avis, des contributeurs donnent leurs avis et enregistrent des modifications.

Rien d'insurmontable, comme je dis souvent "en informatique on peut tout faire, le tout en question ne se résume qu'à une appréciation de l'investissement à faire (temps et disponibilité)".

Donc PHP pourquoi pas? C'est à débattre.

Bonjour à tous et félicitations au développer !

En tant qu'utilisateur, je préfère de loin une application standalone.
En que développer amateur, je trouve le java plus simple et plus rapide que C++ / QT. Surtout qu'une application de ce type n'a pas forcement besoins de grosses performances (en temps de rapidité de traitement).
Pour des problèmes de "fonctionnalité de visualisation" sous java, je n'y ai jamais été confronté encore trop novice dans ce domaine.

@+

Bonjour stunko,

Merci pour ton petit mot. J'ai décidé effectivement de me tourner vers Java et de reprendre tout le développement. Malheureusement je suis beaucoup moins disponible qu'il y a quelques mois. Du coup mon apprentissage (auto-apprentissage) est assez lent. Je n'ai pas encore réussi à convaincre ma hiérarchie de me payer un stage tout fait, donc...

Salut à vous,

@Renaud-CB (message que j'ai zappé),

Oui c'est jouable, mais il y a toujours cet éternel problème de disponibilité. pour ma part j'ai déjà trop de choses en cours. Je travail actuellement sur une nouvelle version d'EntraidElec et j'en ai pour un bout de temps, ce qui me contraint déjà ne pas publier de contenu de manière régulière.

J'essaierais de me réserver une bonne demain durant l'été pour préparer le terrain et voir si c'est réalisable sans un trop gros investissement de temps.

++

Quelques mots sur ma stratégie actuelle en Java. Après avoir découvert le confort de la conception des table à onglets, je rencontre des difficultés sur la taille impressionnante de mon code résultant au sein d'une unique class. Si ça devient trop pénible je risque de tout casser et recommencer différemment en utilisant des class séparées pour réduire la dimension du code. Je ne sais pas si les performance s'en ressentiront.


   [ Message modifié par  favdb  le  22-11-2011  à  00:11 ] 

Un petit point sur l'évolution du développement du projet.

Ces derniers temps ma disponibilité s'est quelque peu réduite. Par ailleurs, comme chaque année à cette époque, je me suis mis en tête de faire évoluer mon système (Mandriva). Après les 2 jours de galère habituelle, j'ai décidé d'abandonner la distribution qui m'accompagnait de puis plus de 6 ans. J'ai donc finalement installé Ubuntu (version 11.10). Résultat : que du bien, tout s'est installé sans à-coup et en moins de deux heures j'avais un système opérationnel et parfaitement à jour.

Je vais donc pouvoir reprendre mes travaux dès que mes autres occupations me laisseront un peu tranquille.

Pour mémoire, voici donc maintenant ma configuration de développement :
Ordinateur portable de marque Acer
Ubuntu 11.10 (je n'ai même plus Windows que je n'utilisais qu'une à deux fois dans l'année)
NetBeans 7.0.1 (pour le développement de jTE)
LibreOffice 3.4.4 (pour la maintenance de oTE, compatibilité déjà vérifiée)
Qt 4.7.4 (pour un éventuel développement de qTE)

A noter que j'ai pu suivre ce weekend un atelier de découverte consacré à Qt Quick et QML, un nouveau langage plutôt consacré à la conception d'application pour mobile (type iPhone). Ce langage interprété embarque la possibilité d'y intégrer du !javascript!, peut être une ouverture vers une version mTE (pour mobile TableauElec). Reste à savoir si une telle version serait vraiment utile.

Parallèlement, j'ai demandé la création d'un espace d'hébergement sur Gna! de manière à pouvoir y déposer les sources dans la perspective de faciliter un éventuel développement collaboratif. Je suis en attente de la décision qui devrait intervenir cette semaine si tout va bien.