Quelle interface ?

[bartelby]

Bonjour, une petite question anodine.
J'aurai aimé savoir quel serait le langage le mieux adapté au développement d'interface utilisateur.
Le but est d'avoir une appli portable win/lin qui ai une interface la plus agréable qui soit.

En évitant Java et Html et quelque chose qui soit sexy et/ou proche de l'interface win.

Si vous avez une idée, je suis curieux.

[lu6fer]

je te dirais QT 4
ou alors wxWidget.

les 2 librairies sont portable linux/win/mac

Ma préférence irait de loin a QT4 mais a toi de voir surtout au niveau de tes competence en dev C++

[bartelby]

En fait coté compétence ce n'est pas trop le problème dans la mesure ou ce n'est pas moi qui vais développer la majeure partie de l'appli.
Par contre il faudra être capable de trouver de la main d'œuvre facilement.
Et partir sur une techno éprouvée mais qui sache évoluer (Pour pas avoir l'interface à grand papa).

Par contre il va falloir que je puisse rapidement acquérir les bases de la chose pour pouvoir faire de la supervision de code et autres joyeusetés de ce genre.

Je vais me renseigner de ce pas sur ces éléments, si il y en a d'autres il ne faut pas hésiter

[Davidbrcz]

Le C++ est puissant (Qt rooxe à mort, WxWidget moins) mais si le but c'est de développer rapidement une IHM, laisser tomber le C++ car ya mieux, surtout si en plus il faut que vous vous formiez.

Pour ma part, je pencherai plus pour du Python, bien plus simple et rapide à mettre en oeuvre que le C++ mais qui garde globalement la même puissance avec PyQt, Qt pour python.

[SYL666]

Idem : Je vote pour Python + Qt

[Alp]

Je vote pour le langage Python également.

Sauf que PyQt est moins élégant que Qt C++. En Python, les choses se passent bien avec wxPython, contrairement à wxWidgets version C++ qui est un peu "foutoir" hélas.

[reverse_engineer]

je vote pour le QT ,par expérience ca donne des interfaces trop conviviale comme si il était fait en VB.

[Davidbrcz]

Alp >> peut être un poil moins élégant, mais quand même tout aussi puissant, car python ou pas, Qt reste Qt.

reverse_engineer>> Je ne savais pas que QuickTime permetait de faire des interfaces

[bartelby]

Merci pour ces réponses,
Je ne suis pas sur d'avoir les idées beaucoup plus claires, car je sens que ça va vite tomber dans le débat d'expert et sur ce coup évidement ... je suis largué.

Mais si je résume bien, je prends le langage qui m'intéresse, genre java et je l'interface avec une bibliothèque du style python ou qt, selon les gouts et les couleurs.
Python semble être autonome également comme langage, je pourrais peut être développer entièrement mon appli avec ? L'appli pour être clair devra être un client riche accédant à une base de données.
Dans le cas de Python j'ai vu qu'il y avait ensuite le choix d'une bibliothèque (bibliothèque de bibliothèque ca fait un peu bp pour moi ...) graphique, avec Tkinter par défaut. C'est réputé ça ? c'est sexy ? On trouve des codeurs facilement ? Lisibilité, maintenance ?
Je pense faire une demande de dev au deux ou trois SSII avec lesquelles je travail et voir ce qu'elles me préconisent.

[wiztricks]

Si c'est pour demander à une SSII de faire le boulot, je ne vois pas l'intérêt de les scotcher à un langage particulier: ils ont peut être une bonne expérience sur des languages autres que Python/Qt mais tout aussi "utilisables" dans votre contexte.
Les questions a se poser sont peut être "qui va faire la maintenance?"... Si c'est l'équipe client quels sont les langages et les environnements maitrisés? Quelles sont les exigences côté documentations, tests qu'il faudra satisfaire pour pouvoir faire évoluer l'application?
Et si c'est la SSII qui a fait le développement, la question qui se pose est de savoir comment pouvoir en changer s'ils vous prennent pour une buse ou s'ils disparaissent...
- W

[bartelby]

Par expérience, si tu veux que ça soit bien fait, il ne faut pas se reposer sur les envies d'une SSII.

L'intérêt c'est de les pousser dans les cordes pour qu'ils se creusent la tête et qu'ils s'obligent à sortir de bonnes solutions.

Pour la maintenance il y a une grande partie faite par moi-même.
Le choix de la solution technique finira par nous revenir de toutes manières.
D'autant que c'est le genre de choix que tu dois assumer pendant de nombreuses années, c'est pour ça qu'il nous faut quelque chose qui tienne vraiment la route.

[SYL666]

Note que Python n'est pas une bibliothèque mais un langage de script à part entière. Comme Java, il a besoin d'une machine virtuel et est portable. Il a ses avantages et ses inconvénients.

Pour lisibilité / maintenance, Python est très bien (trop même, j'aime pas les langages qui force l'indentation). Il est parfaitement objet et nécessite beaucoup moins de lignes de code que son équivalent C++, voir Java. Il est facile à débugger. La communauté est très active pour faire évoluer la machine virtuelle, et on trouveras pas mal de bibliothèques pour tout et n'importe quoi.
Par contre, si tu souhaites cacher le code source, ou si tu veux de la puissance pur, il va falloir chercher ailleurs.

Je pense que le mieux et de choisir le langage qui conviendrait le mieux à ton application, puis de choisir une bibliothèque graphique qui convient le mieux au language.

[bartelby]

Envoyé par SYL666

Note que Python n'est pas une bibliothèque mais un langage de script à part entière. Comme Java, il a besoin d'une machine virtuel et est portable. Il a ses avantages et ses inconvénients.

Par contre, si tu souhaites cacher le code source, ou si tu veux de la puissance pur, il va falloir chercher ailleurs.

Je pense que le mieux et de choisir le langage qui conviendrait le mieux à ton application, puis de choisir une bibliothèque graphique qui convient le mieux au langage.

J'ai un peu tronqué la citation mais ces points m'interpellent.

Machine virtuelle = lenteur et lourdeur dans ma tete : vrai / faux ? Ce sentiment est appuyé par la phrase sur la puissance pure qu'il faut oublier.

Le code source n'est pas caché ? C'est a dire qu'on pose les sources sur les postes clients ? Vrai / Faux ? Ça me gêne que notre logique métier soit à dispo de tous les clients pour des raisons évidentes.

Je suis entièrement d'accord avec la dernière partie de ton post, c'est d'ailleurs la raison de mon post initial.

[SYL666]

Je dirais que les 2 affirmations sont à relativiser :
* Python n'est surement pas fait pour faire du calcul scientifique, mais la plupars des applications fonctionnement très bien. A ma connaissance, Python est bien plus léger que Java. De toute manière, les langages interprétés ont le vent en poupe.

* Je suppose qu'il doit exister un moyen de précompiler le fichier, comme en Java (les fichiers .class). Le code n'est alors pas lisible par l'oeil humain, mais parfaitement reverse-engineerable (oui, bon, qu'on me donne l'équivalent français!) par des logiciels.

Ceci dit, pour ma raison indiqué plus haut (indentation forcée), je ne me suis jamais lancé profondément dans ce langage et j'espère qu'un vrai expert pourra mieux répondre.

Quel type d'application est-ce? base de données, calcul, client/serveur, web service, application de gestion ?

[bartelby]

Merci ça éclaire vraiment bien ma lanterne ces indications.
Il s'agit d'une application back-office avec gestion de stocks.
Pour une enseigne de distribution.

coté serveur j'ai une base de données sous linux.
Et coté client j'ai du windows pour l'instant mais prochainement aussi des postes linux.
Aucun informaticien du coté des magasins l'appli doit donc être installable facilement sur les postes clients.

Coté client il faut jusque que ça soit plutôt joli, que je puisse l'interfacer avec du ms office ET de l'open office mais ça ne me tracasse pas du tout pour l'instant. Très peu de calcul coté client.
Coté performance les points a surveiller sont simple :
- Interface réactive
- Échange de données client/serveur

Voila je ne pense pas en demander trop à un langage

[wiztricks]

Côté maintenance faut-il préférer des clients lourds ou des clients légers?
- W

[bartelby]

Envoyé par wiztricks

Côté maintenance faut-il préférer des clients lourds ou des clients légers?
- W

De mon point de vu ni l'un ni l'autre
D'où l'intérêt d'un client riche.
Le client riche va juste mettre une interface plus sympa qu'un client html (y compris web 2.0 à mon avis).
Mais les traitements vont rester du coté du serveur.
Quand le client fait une requête par exemple (ce qu'est quand même l'essentiel d'une appli de gestion), la requête est traitée sur le serveur et seul les enregistrements nécessaires sont envoyés au client. On économise pas mal de ressource et de réseau comme ça par rapport à un client lourd.

En plus en général la configuration et l'installation des postes clients est plus legere. Le client lourd porte bien son nom.

D'un point de vu de maintenance, pour la mise à jour des postes ça doit être grosso modo la même chose et dépendre de la techno. Chez nous la techno embarque son système de mise à jour des postes client.

J'espère ne pas avoir été trop "hors sujet"