Une idée de projet farfelue : une nouvelle bibliothèque IHM ?

Invité · 12/04/2010, 22h18

Envoyé par Matthieu Brucher

Je n'ai pas forcément tout lu, mais je suggère dans la liste des features la possibilité d'intégrer une fenêtre Farfelue dans une fenêtre d'un autre langage (un peu comme le QWinMigrate de Qt).

Je crois que c'est une chose que la suggestion de Metagoto (de tout implémenter dans un premier temps directement en terme de primitives de fenêtrage de l'OS cible) permettra. En fait, si nos widgets farfelus s'implémentent comme des fenêtres win32, avec les procs de sousclassement et tout ca, alors ils s'intègrent dans n'importe quel système qui fonctionne de la même manière...

Mais ca reste un peu un must, si l'on veut que la librairie puisse être utilisée en renfort de projets existants.

Francois

**koala01** · 12/04/2010, 22h18

Envoyé par Matthieu Brucher

Je n'ai pas forcément tout lu, mais je suggère dans la liste des features la possibilité d'intégrer une fenêtre Farfelue dans une fenêtre d'un autre langage (un peu comme le QWinMigrate de Qt).

Si tu veux avoir un aperçu complet de l'état des features prévues, tu peux te reporter au fichier joint au message 225 de cette discussion.

Mais effectivement, ce genre de possibilité pourrait s'avérer utile, bien que je relègue l'idée dans la gamme des objectifs à terme

Avant d'en arriver là, il y aura en effet un grand nombre d'autre choses à mettre au point, et il s'agira de réfléchir à la faisabilité de la chose

Mais l'idée me semble intéressante, c'est pourquoi je l'adopte, sous réserve d'infaisabilité

**metagoto** · 13/04/2010, 02h10

A propos du doc de koala nom de code 01, quelques typos sympathiques:
- special tanks
- desing (2 fois)

La convention de nommage:
Je suis à mille lieux de ce qui est proposé, dommage

Je me rallie à la majorité, mais perso, j'aurai préféré un bon vieux standard à la std ou boost, cad pas une seule majuscule (à part les arguments de templates et le preproc), pas de camelCase, dIRE sTRAITS case (

), de prefix spéciaux ou de trucs comme ça.

.hpp: +1

SVN: j'ai une profonde subversion, non, aversion pour SVN! Là encore, je ne veux pas m'imposer. Mercurial ou git, si on en a la possibilité, je pense qu'il faut y songer

La license: je vous fais confiance pour un truc permissif (à mort).

Le nom Farfelue, OK, pas de prob.

Edit: j'ai oublié de préciser des liens potentiellement intéressants, à ajouter dans la section Sources d'inspiration du doc?
- The Ketchup Message Map Library
http://p-stade.sourceforge.net/ketchup/index.html
- Smartwin
http://smartwin.sourceforge.net/
- eGUI++
http://torjo.com/egui/index.html
- Designing a Cross-Platform GUI (April 01, 1995

)
http://www.drdobbs.com/cpp/184403013

**koala01** · 13/04/2010, 03h39

Envoyé par metagoto

A propos du doc de koala nom de code 01, quelques typos sympathiques:
- special tanks
- desing (2 fois)

La convention de nommage:
Je suis à mille lieux de ce qui est proposé, dommage

Je me rallie à la majorité, mais perso, j'aurai préféré un bon vieux standard à la std ou boost, cad pas une seule majuscule (à part les arguments de templates et le preproc), pas de camelCase, dIRE sTRAITS case (

), de prefix spéciaux ou de trucs comme ça.

Je comprends l'idée et la motivation, mais j'avouerai que je préfère vraiment faire une distinction franche et nette entre les fonctions / classe issues de la STL ou de boost et celles issues de la bibliothèque.

De plus, la convention utilisée est très proche de celle utilisée par la plupart des bibliothèques (actuellement utilisées et reconnues) actuelles... La transition sera surement plus simple

.hpp: +1

Je l'ai dit, je n'y suis pas opposé, loin de là... Pour autant que l'on ne vienne pas pleurer après chez moi parce que "nom d'une pipe, chaque fois je me laisse prendre par ce @##@ d'IDE qui crée des fichiers *.h par défaut"...

SVN: j'ai une profonde subversion, non, aversion pour SVN! Là encore, je ne veux pas m'imposer. Mercurial ou git, si on en a la possibilité, je pense qu'il faut y songer

Une chose est certaine: c'est que l'on n'en a pas la possibilité sur DVP...

De plus, je dois avouer avoir une préférence pour les systèmes qui indiquent expressément les fichiers mis à jour, or git t'emballe tout cela dans un nombre de fichiers et j'ai l'impression que c'est moins explicite.

Enfin, comme je l'ai déjà dit, je suis plus habitué à SVN ou à CVS qu'à git, que je connais à peine ou pire à Mercurial, que je n'ai utilisé (si mes souvenirs sont bons) qu'une seule fois pour récupérer des sources.

Ceci dit, je reste ouvert à la discussion, sous réserve:

de respecter le souhait de la majorité
de me trouver un site proposant "tout le package" nécessaire pour une gestion correcte et saine du projet... Gratuit, cela va sans dire (*)

(*) il faut bien se dire que nous allons tous intervenir gratuitement sur le projet, et qu'il y a peu de chances qu'il soit suffisamment avancé pour inciter les utilisateurs à le soutenir financièrement avant un certain temps... Et je présumes que vous comme moi préféreriez utiliser vos sous pour partir en vacances

La license: je vous fais confiance pour un truc permissif (à mort).

Le nom Farfelue, OK, pas de prob.

Edit: j'ai oublié de préciser des liens potentiellement intéressants, à ajouter dans la section Sources d'inspiration du doc?
- The Ketchup Message Map Library
http://p-stade.sourceforge.net/ketchup/index.html
- Smartwin
http://smartwin.sourceforge.net/
- eGUI++
http://torjo.com/egui/index.html
- Designing a Cross-Platform GUI (April 01, 1995

)
http://www.drdobbs.com/cpp/184403013

j'y jetterai un oeil, mais là, je commence à fatiguer

**epsilon68** · 13/04/2010, 04h32

pourquoi pas http://www.gitorious.org/
?

git c'est vraiment mieux que svn, c'est plus rapide et ca permet de bosser en déconnecté. Le truc important est qu'il est facile de faire des branches pour tester des trucs puis de "merger" avec une autre.

aussi pour les includes, ce que j'ai vu dans Qt et ce que je fais maintenant pour moi aussi, c'est que je peux avoir des includes séparés des mes sources.
par exemples:

source.cpp: contient 4 classes (parce que petites?) A,B,C et D
source.hpp: le header de A,B,C et D

je fais donc aussi et à part:
a.hpp: include de source.hpp
b.hpp: include de source.hpp
c.hpp: include de source.hpp
d.hpp: include de source.hpp

je trouve cela pratique.

**yan** · 13/04/2010, 09h38

Envoyé par epsilon68

pourquoi pas http://www.gitorious.org/
?

git c'est vraiment mieux que svn, c'est plus rapide et ca permet de bosser en déconnecté. Le truc important est qu'il est facile de faire des branches pour tester des trucs puis de "merger" avec une autre.

(comme on viens de créé un projet)

Pour QExtend on as choisie svn car git (extern) n'est pas interfaçable avec redmine.
Ce qui est dommage vue l'utilité de redmine.
Et il n'est pas prévue que dvp créé un server git.

A vous de voire.

**alexrtz** · 13/04/2010, 11h16

Envoyé par koala01

Enfin, comme je l'ai déjà dit, je suis plus habitué à SVN ou à CVS qu'à git, que je connais à peine ou pire à Mercurial, que je n'ai utilisé (si mes souvenirs sont bons) qu'une seule fois pour récupérer des sources.

Pour Mercurial, ce tuto est très bien fait

**koala01** · 13/04/2010, 11h29

Envoyé par epsilon68

pourquoi pas http://www.gitorious.org/
?

Bon, ce serait peut être une solution, mais cela ne rempli pour l'instant qu'une des conditions.

Pour ceux qui prévoient de participer plus ou moins au développement (après tout, je suis désolé, mais c'est surtout l'avis de ceux-là qui m'intéresse sur ce point

) qui préfère git, qui préfère SVN et qui n'a pas d'avis

Pour l'insant, il semble que metagoto et goten préfèrent git, mais qu'en est il des autres

Epsilon, tu as donné des avis qui me font douter de ton envie de participer, mais ce n'est qu'un ressenti... Quelles sont tes intentions

Messieurs, mesdames, comptez vous et donnez votre avis sur le sujet

Envoyé par yan

(comme on viens de créé un projet)

Pour QExtend on as choisie svn car git (extern) n'est pas interfaçable avec redmine.
Ce qui est dommage vue l'utilité de redmine.
Et il n'est pas prévue que dvp créé un server git.

A vous de voire.

C'est également un aspect à prendre en compte... je trouverais dommage de ne pas profiter de la visibilité de DVP du coté francophone

**koala01** · 13/04/2010, 12h07

Pour information, et comme convenu hier soir, j'ai demandé l'hébergement à DVP.

Je viens de recevoir confirmation que ma demande est à l'étude et, comme ils ont précisé (je cite) "Il ne devrait normalement y avoir aucun souci pour un projet d'un membre de l'équipe", je serais très mal venu de leur dire en définitive que je n'ai pas besoin de celui-ci.

Je suis donc désolé, mais ce sera SVN

**Matthieu Brucher** · 13/04/2010, 23h01

Envoyé par yan

(comme on viens de créé un projet)

Pour QExtend on as choisie svn car git (extern) n'est pas interfaçable avec redmine.
Ce qui est dommage vue l'utilité de redmine.
Et il n'est pas prévue que dvp créé un server git.

A vous de voire.

Ah bon ? Même si git est installé à côté du Redmine ?

**Matthieu Brucher** · 13/04/2010, 23h03

Envoyé par koala01

Pour information, et comme convenu hier soir, j'ai demandé l'hébergement à DVP.

Je viens de recevoir confirmation que ma demande est à l'étude et, comme ils ont précisé (je cite) "Il ne devrait normalement y avoir aucun souci pour un projet d'un membre de l'équipe", je serais très mal venu de leur dire en définitive que je n'ai pas besoin de celui-ci.

Je suis donc désolé, mais ce sera SVN

Ca ne pose pas vraiment problème puisqu'il existe des ponts pour pusher vers des SVN. Mais bon, SVN a tout de même des défauts gênants lors des fusions

**yan** · 13/04/2010, 23h06

Envoyé par Matthieu Brucher

Même si git est installé à côté du Redmine ?

Dans ce cas oui, mais dvp n'as pas prévue de proposer du git...
Donc ça coince

**Matthieu Brucher** · 13/04/2010, 23h28

Il me semble qu'il n'est pas nécessaire que git soit en mode serveur. Il suffit qu'il y ait le paquet pour que ça fonctionne. En tout cas, ça a l'air de fonctionner ainsi pour bzr et hg.

**yan** · 13/04/2010, 23h49

Envoyé par Matthieu Brucher

Il me semble qu'il n'est pas nécessaire que git soit en mode serveur. Il suffit qu'il y ait le paquet pour que ça fonctionne. En tout cas, ça a l'air de fonctionner ainsi pour bzr et hg.

Perso, j'y connait rien. Ca viens de la haute autorité de l'espace projet

**Klaim** · 13/04/2010, 23h53

git serait problématique sur Windows, il semblerait que mercurial soit un meilleur compromis dans le genre, mais pas non plus parfait. (voir le blog du mr. d'Ogre : http://www.stevestreeting.com )

**yan** · 14/04/2010, 00h01

Envoyé par Klaim

git serait problématique sur Windows, il semblerait que mercurial soit un meilleur compromis dans le genre, mais pas non plus parfait. (voir le blog du mr. d'Ogre : http://www.stevestreeting.com )

Quand j'avais testé git était vraiment bancale sous windows. Mais il parait que ça va mieux.

**Klaim** · 14/04/2010, 00h11

Je ne saurais pas dire mais j'ai entendu dire ça effectivement. Personellement tant que ça reposera sur cygwin je m'en méfierai. J'utilse tortoiseGIT pour récuperer certains projets toutefois.

Pour un "nouveau" projet open-source et j'utilise mercurial pour l'instant mais je n'en fais pas encore un usage bien lourd (et je suis seul dans l'équipe pour l'instant). De tout ce que j'ai lu, en tout cas, je pense que git ou hg seraient de toutes façons un sacrément meilleur choix que svn dans le cas d'un développement collaboratif (exemple: gros projet open-source). Surtout couplé avec un site façon gitorious/github et bitbucket qui sont quand même ultra pratiques pour gérer les propositions de modifications (l'équivalent des patchs en gros).

Sinon, je n'ai pas bien compris l'interet d'utiliser une license restrictive comme LGPL, surtout pour une bibliothque qui a pour but de s'insérer entre STL et Boost ... (voir qui pourrait faire partie de Boost un jour).
On gagnerai en participations avec une license MIT ou Boost à mon avis. Mais ce n'est que mon avis.

My 2 cents comme on dit.

**Alp** · 14/04/2010, 00h24

Sinon y'a toujours darcs (http://darcs.net) mais je doute que vous le choisissiez

**metagoto** · 14/04/2010, 06h37

Envoyé par Alp

Sinon y'a toujours darcs (http://darcs.net) mais je doute que vous le choisissiez

Pourquoi donc, ça ne peut être que mieux que SVN de toute façon ?
(troll facile du matin

)

**epsilon68** · 14/04/2010, 08h32

hello,

pour ma part j'ai travaillé avec svn,
et ca n'a rien franchement rien à voir avec git,
j'aime les outils rapides!
en plus les branches sont importantes, et svn ne les gere pas bien,
de plus oubliez les merges entre 2 versions!

Epsilon, tu as donné des avis qui me font douter de ton envie de participer, mais ce n'est qu'un ressenti... Quelles sont tes intentions

pour ma part, je trouve que la lib part de trop petit, il y a trop d'investissement à faire et vu mon trop peu de temps libre, je préfère utiliser Qt pour arriver à mes fins. En outre, je penche du coté web et j'ai encore beaucoup de choses à explorer (webkit) sans oubliez Quick (et wpf). Définitivement la "farfelue" lib est trop bas niveau pour moi mais je la suivrais

Une idée de projet farfelue : une nouvelle bibliothèque IHM ?

Contribuez C++

Discussions similaires

Partager

Partager