Malgré qu'il soit en anglais, cet article pourrait intéresser des
pythonneux :
http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57
--
@-salutations
--
Michel Claveau
Malgré qu'il soit en anglais, cet article pourrait intéresser des pythonneux : http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57 -- @-salutations -- Michel Claveau
Bon, et finalement c'est lequel qu'il faut préférrer si on veut pas se casser la tête et en rester à un GUI simple mais fonctionnel, et multi- plateforme (Win, Mac 'Aqua') ?
Olivier
On 23 jan, 13:32, "Méta-MCI (MVP)" <enleverlesX.X...@XmclaveauX.com>
wrote:
Bonjour !
Malgré qu'il soit en anglais, cet article pourrait intéresser des
pythonneux :
http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57
--
@-salutations
--
Michel Claveau
Bon, et finalement c'est lequel qu'il faut préférrer si on veut pas se
casser la tête et en rester à un GUI simple mais fonctionnel, et multi-
plateforme (Win, Mac 'Aqua') ?
Malgré qu'il soit en anglais, cet article pourrait intéresser des pythonneux : http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57 -- @-salutations -- Michel Claveau
Bon, et finalement c'est lequel qu'il faut préférrer si on veut pas se casser la tête et en rester à un GUI simple mais fonctionnel, et multi- plateforme (Win, Mac 'Aqua') ?
Olivier
Michel Claveau - NoSpam SVP ; merci
Salut !
lequel qu'il faut préférer si on veut pas se casser la tête et en rester à un GUI simple mais fonctionnel,
PLUIE3. Simple, mais avec des possibilités d'extensions/évolutions intéressantes.
et multi-plateforme (Win, Mac 'Aqua') ?
Aïe. PLUIE fonctionne uniquement avec la famille Windows. Et encore, uniquement sur les Windows à noyau NT avec GUI (donc, pas sur les Win-9x, ni sur les CE, ni sur les éditions "Mobile", ni sur Core).
@-salutations -- Michel Claveau
Salut !
lequel qu'il faut préférer si on veut pas se casser la tête et en
rester à un GUI simple mais fonctionnel,
PLUIE3. Simple, mais avec des possibilités d'extensions/évolutions
intéressantes.
et multi-plateforme (Win, Mac 'Aqua') ?
Aïe. PLUIE fonctionne uniquement avec la famille Windows. Et encore,
uniquement sur les Windows à noyau NT avec GUI (donc, pas sur les
Win-9x, ni sur les CE, ni sur les éditions "Mobile", ni sur Core).
lequel qu'il faut préférer si on veut pas se casser la tête et en rester à un GUI simple mais fonctionnel,
PLUIE3. Simple, mais avec des possibilités d'extensions/évolutions intéressantes.
et multi-plateforme (Win, Mac 'Aqua') ?
Aïe. PLUIE fonctionne uniquement avec la famille Windows. Et encore, uniquement sur les Windows à noyau NT avec GUI (donc, pas sur les Win-9x, ni sur les CE, ni sur les éditions "Mobile", ni sur Core).
@-salutations -- Michel Claveau
Eric Brunel
On Wed, 04 Feb 2009 23:52:44 +0100, Michel Claveau - NoSpam SVP ; merci wrote:
Bonsoir !
Tkinter n'est en fait qu'un "wrapper" autour d'un autre langage qui s'appelle tcl/tk.
J'en profite pour glisser un petit exemple de code, qui montre comment utiliser le langage TCL depuis Python (grâce à TKinter).
Je ne résiste pas, j'ai encore plus rigolo: une interaction entre Python et tcl/tk beaucoup plus poussée que ce qui est fait dans Tkinter. Le code brut de fonderie:
---------------------------------------- from Tkinter import *
Maintenant, le quiz du jour: à quoi ça peut bien servir? ;-)
Je sais, personne n'en a rien à cirer. Mais, je m'étais intéressé au problème il y a quelques temps. Alors je capitalise sur ce temps perdu...
Mmmmm... Pas mieux en fait... -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
On Wed, 04 Feb 2009 23:52:44 +0100, Michel Claveau - NoSpam SVP ; merci
<noZ.spamZ@ZZ.ZsvpZ.com> wrote:
Bonsoir !
Tkinter n'est en fait qu'un "wrapper" autour d'un autre langage qui
s'appelle tcl/tk.
J'en profite pour glisser un petit exemple de code, qui montre comment
utiliser le langage TCL depuis Python (grâce à TKinter).
Je ne résiste pas, j'ai encore plus rigolo: une interaction entre Python
et tcl/tk beaucoup plus poussée que ce qui est fait dans Tkinter. Le code
brut de fonderie:
----------------------------------------
from Tkinter import *
On Wed, 04 Feb 2009 23:52:44 +0100, Michel Claveau - NoSpam SVP ; merci wrote:
Bonsoir !
Tkinter n'est en fait qu'un "wrapper" autour d'un autre langage qui s'appelle tcl/tk.
J'en profite pour glisser un petit exemple de code, qui montre comment utiliser le langage TCL depuis Python (grâce à TKinter).
Je ne résiste pas, j'ai encore plus rigolo: une interaction entre Python et tcl/tk beaucoup plus poussée que ce qui est fait dans Tkinter. Le code brut de fonderie:
---------------------------------------- from Tkinter import *
Maintenant, le quiz du jour: à quoi ça peut bien servir? ;-)
Je sais, personne n'en a rien à cirer. Mais, je m'étais intéressé au problème il y a quelques temps. Alors je capitalise sur ce temps perdu...
Mmmmm... Pas mieux en fait... -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Eric Brunel
On Thu, 05 Feb 2009 09:32:17 +0100, OdarR wrote:
On 23 jan, 13:32, "Méta-MCI (MVP)" wrote:
Bonjour !
Malgré qu'il soit en anglais, cet article pourrait intéresser des pythonneux : http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57 -- @-salutations -- Michel Claveau
Bon, et finalement c'est lequel qu'il faut préférrer si on veut pas se casser la tête et en rester à un GUI simple mais fonctionnel, et multi- plateforme (Win, Mac 'Aqua') ?
Ah ben ça on va avoir du mal à choisir à ta place... Tout ça dépend de tes objectifs, de tes habitudes et de plein d'autres choses qui te sont personnelles.
Pour ma part, mon choix a été guidé par plusieurs critères: - D'abord, je ne voulais pas de bibliothèque monstrueuse qui réinventait l'eau tiède et redéfinissait tous les widgets sans s'occuper de la plateforme courante. Donc PyQt/QT et PyGtk/GTK étaient out... - Restaient donc en gros wxPython et Tkinter. Le fait est que j'avais commencé à utiliser le second il y a longtemps et que j'y étais plus habitué. Cela dit, même aujourd'hui, je pense que je referais le même choix, tout simplement parce que je n'arrive pas à me faire à l'API wxPython. Je trouve ça trop compliqué, avec trop de choses qui n'ont finalement pas grand chose à voir avec ce que je veux mettre dans ma GUI. J'avoue que j'ai un peu oublié comment on fait en wxPython (et j'ai aussi un peu la flemme de chercher...), mais quelque chose d'hyper-simple en Tkinter comme ça:
est - si mes souvenirs sont bons - *beaucoup* plus compliqué à coder avec wxPython.
Après plein d'autres critères peuvent entrer en compte, comme par exemple la disponibilité d'un outil de dessin pour la GUI. Personnellement, ça ne m'intéresse pas: j'en ai essayé beaucoup, et à chaque fois, j'ai fini par vouloir faire quelque chose que le toolkit savait faire, mais pas l'outil de dessin. Mais je sais qu'il y a des gens pour qui c'est impensable de coder une GUI à la main. Et dans ce cas là, Tkinter risque d'être out aussi, parce qu'à ma connaissance, un tel outil n'existe pas (à part quelques vieux tromblons, voire - horreur! - des outils payants...).
Donc en gros, c'est à toi de définir tes critères, de faire des recherches sur les toolkits, et éventuellement de poser quelques questions ici ou ailleurs s'il y a des choses que tu ne trouves pas. -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
On Thu, 05 Feb 2009 09:32:17 +0100, OdarR <olivier.odar@gmail.com> wrote:
On 23 jan, 13:32, "Méta-MCI (MVP)" <enleverlesX.X...@XmclaveauX.com>
wrote:
Bonjour !
Malgré qu'il soit en anglais, cet article pourrait intéresser des
pythonneux :
http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57
--
@-salutations
--
Michel Claveau
Bon, et finalement c'est lequel qu'il faut préférrer si on veut pas se
casser la tête et en rester à un GUI simple mais fonctionnel, et multi-
plateforme (Win, Mac 'Aqua') ?
Ah ben ça on va avoir du mal à choisir à ta place... Tout ça dépend de tes
objectifs, de tes habitudes et de plein d'autres choses qui te sont
personnelles.
Pour ma part, mon choix a été guidé par plusieurs critères:
- D'abord, je ne voulais pas de bibliothèque monstrueuse qui réinventait
l'eau tiède et redéfinissait tous les widgets sans s'occuper de la
plateforme courante. Donc PyQt/QT et PyGtk/GTK étaient out...
- Restaient donc en gros wxPython et Tkinter. Le fait est que j'avais
commencé à utiliser le second il y a longtemps et que j'y étais plus
habitué. Cela dit, même aujourd'hui, je pense que je referais le même
choix, tout simplement parce que je n'arrive pas à me faire à l'API
wxPython. Je trouve ça trop compliqué, avec trop de choses qui n'ont
finalement pas grand chose à voir avec ce que je veux mettre dans ma GUI.
J'avoue que j'ai un peu oublié comment on fait en wxPython (et j'ai aussi
un peu la flemme de chercher...), mais quelque chose d'hyper-simple en
Tkinter comme ça:
est - si mes souvenirs sont bons - *beaucoup* plus compliqué à coder avec
wxPython.
Après plein d'autres critères peuvent entrer en compte, comme par exemple
la disponibilité d'un outil de dessin pour la GUI. Personnellement, ça ne
m'intéresse pas: j'en ai essayé beaucoup, et à chaque fois, j'ai fini par
vouloir faire quelque chose que le toolkit savait faire, mais pas l'outil
de dessin. Mais je sais qu'il y a des gens pour qui c'est impensable de
coder une GUI à la main. Et dans ce cas là, Tkinter risque d'être out
aussi, parce qu'à ma connaissance, un tel outil n'existe pas (à part
quelques vieux tromblons, voire - horreur! - des outils payants...).
Donc en gros, c'est à toi de définir tes critères, de faire des recherches
sur les toolkits, et éventuellement de poser quelques questions ici ou
ailleurs s'il y a des choses que tu ne trouves pas.
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Malgré qu'il soit en anglais, cet article pourrait intéresser des pythonneux : http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57 -- @-salutations -- Michel Claveau
Bon, et finalement c'est lequel qu'il faut préférrer si on veut pas se casser la tête et en rester à un GUI simple mais fonctionnel, et multi- plateforme (Win, Mac 'Aqua') ?
Ah ben ça on va avoir du mal à choisir à ta place... Tout ça dépend de tes objectifs, de tes habitudes et de plein d'autres choses qui te sont personnelles.
Pour ma part, mon choix a été guidé par plusieurs critères: - D'abord, je ne voulais pas de bibliothèque monstrueuse qui réinventait l'eau tiède et redéfinissait tous les widgets sans s'occuper de la plateforme courante. Donc PyQt/QT et PyGtk/GTK étaient out... - Restaient donc en gros wxPython et Tkinter. Le fait est que j'avais commencé à utiliser le second il y a longtemps et que j'y étais plus habitué. Cela dit, même aujourd'hui, je pense que je referais le même choix, tout simplement parce que je n'arrive pas à me faire à l'API wxPython. Je trouve ça trop compliqué, avec trop de choses qui n'ont finalement pas grand chose à voir avec ce que je veux mettre dans ma GUI. J'avoue que j'ai un peu oublié comment on fait en wxPython (et j'ai aussi un peu la flemme de chercher...), mais quelque chose d'hyper-simple en Tkinter comme ça:
est - si mes souvenirs sont bons - *beaucoup* plus compliqué à coder avec wxPython.
Après plein d'autres critères peuvent entrer en compte, comme par exemple la disponibilité d'un outil de dessin pour la GUI. Personnellement, ça ne m'intéresse pas: j'en ai essayé beaucoup, et à chaque fois, j'ai fini par vouloir faire quelque chose que le toolkit savait faire, mais pas l'outil de dessin. Mais je sais qu'il y a des gens pour qui c'est impensable de coder une GUI à la main. Et dans ce cas là, Tkinter risque d'être out aussi, parce qu'à ma connaissance, un tel outil n'existe pas (à part quelques vieux tromblons, voire - horreur! - des outils payants...).
Donc en gros, c'est à toi de définir tes critères, de faire des recherches sur les toolkits, et éventuellement de poser quelques questions ici ou ailleurs s'il y a des choses que tu ne trouves pas. -- python -c "print ''.join([chr(154 - ord(c)) for c in 'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Méta-MCI (MVP)
Salut !
je n'arrive pas à me faire à l'API wxPython. Je trouve ça trop compliqué, avec trop de choses qui...
Et, je rajouterais que wxpython m'a posé suffisamment de problèmes de versions, et de conflit entre les versions utilisées en développement et les versions nécessitées par d'autres logiciels (sous Python).
De plus, pour ceux qui ont besoin de portabilité, il y a des choses qui, dans wx, ne tournent que dans certains OS.
@-salutations -- MCI
Salut !
je n'arrive pas à me faire à l'API wxPython. Je trouve ça trop
compliqué, avec trop de choses qui...
Et, je rajouterais que wxpython m'a posé suffisamment de problèmes de
versions, et de conflit entre les versions utilisées en développement et
les versions nécessitées par d'autres logiciels (sous Python).
De plus, pour ceux qui ont besoin de portabilité, il y a des choses qui,
dans wx, ne tournent que dans certains OS.
je n'arrive pas à me faire à l'API wxPython. Je trouve ça trop compliqué, avec trop de choses qui...
Et, je rajouterais que wxpython m'a posé suffisamment de problèmes de versions, et de conflit entre les versions utilisées en développement et les versions nécessitées par d'autres logiciels (sous Python).
De plus, pour ceux qui ont besoin de portabilité, il y a des choses qui, dans wx, ne tournent que dans certains OS.
@-salutations -- MCI
OdarR
On 5 fév, 11:59, Méta-MCI (MVP) wrote:
Salut !
> je n'arrive pas à me faire à l'API wxPython. Je trouve ça trop > compliqué, avec trop de choses qui...
Et, je rajouterais que wxpython m'a posé suffisamment de problèmes de versions, et de conflit entre les versions utilisées en développement et les versions nécessitées par d'autres logiciels (sous Python).
De plus, pour ceux qui ont besoin de portabilité, il y a des choses qui , dans wx, ne tournent que dans certains OS.
@-salutations -- MCI
Merci pour vos conseils, les gars. ça tombe bien, je comptais creuser un peu Tk, j'ai plein de doc papier sous la main (Tkinter, ça se prononce "té ka inne-tère", ou "té kin ne- tère" ? ;-)
j'espère que ce sera pas trop kinne-tère surprise.
Olivier
On 5 fév, 11:59, Méta-MCI (MVP) <enleverlesX.X...@XmclaveauX.com>
wrote:
Salut !
> je n'arrive pas à me faire à l'API wxPython. Je trouve ça trop
> compliqué, avec trop de choses qui...
Et, je rajouterais que wxpython m'a posé suffisamment de problèmes de
versions, et de conflit entre les versions utilisées en développement et
les versions nécessitées par d'autres logiciels (sous Python).
De plus, pour ceux qui ont besoin de portabilité, il y a des choses qui ,
dans wx, ne tournent que dans certains OS.
@-salutations
--
MCI
Merci pour vos conseils, les gars.
ça tombe bien, je comptais creuser un peu Tk, j'ai plein de doc papier
sous la main (Tkinter, ça se prononce "té ka inne-tère", ou "té kin ne-
tère" ? ;-)
j'espère que ce sera pas trop kinne-tère surprise.
> je n'arrive pas à me faire à l'API wxPython. Je trouve ça trop > compliqué, avec trop de choses qui...
Et, je rajouterais que wxpython m'a posé suffisamment de problèmes de versions, et de conflit entre les versions utilisées en développement et les versions nécessitées par d'autres logiciels (sous Python).
De plus, pour ceux qui ont besoin de portabilité, il y a des choses qui , dans wx, ne tournent que dans certains OS.
@-salutations -- MCI
Merci pour vos conseils, les gars. ça tombe bien, je comptais creuser un peu Tk, j'ai plein de doc papier sous la main (Tkinter, ça se prononce "té ka inne-tère", ou "té kin ne- tère" ? ;-)
j'espère que ce sera pas trop kinne-tère surprise.
> lequel qu'il faut préférer si on veut pas se casser la tête et en > rester à un GUI simple mais fonctionnel,
PLUIE3. Simple, mais avec des possibilités d'extensions/évolutions intéressantes.
> et multi-plateforme (Win, Mac 'Aqua') ?
Aïe. PLUIE fonctionne uniquement avec la famille Windows. Et encore, uniquement sur les Windows à noyau NT avec GUI (donc, pas sur les Win-9x, ni sur les CE, ni sur les éditions "Mobile", ni sur Core).
@-salutations -- Michel Claveau
bel effort et merci, mais je tiens de plus en plus à investir le peu de temps qu'il me reste à apprendre dans du multi-plateforme (d'où déjà le choix python). pour le gui c'est pareil. je touche comme beaucoup de monde à xp, unix, linux, mac.
> lequel qu'il faut préférer si on veut pas se casser la tête et en
> rester à un GUI simple mais fonctionnel,
PLUIE3. Simple, mais avec des possibilités d'extensions/évolutions
intéressantes.
> et multi-plateforme (Win, Mac 'Aqua') ?
Aïe. PLUIE fonctionne uniquement avec la famille Windows. Et encore,
uniquement sur les Windows à noyau NT avec GUI (donc, pas sur les
Win-9x, ni sur les CE, ni sur les éditions "Mobile", ni sur Core).
@-salutations
--
Michel Claveau
bel effort et merci, mais je tiens de plus en plus à investir le peu
de temps qu'il me reste à apprendre dans du multi-plateforme (d'où
déjà le choix python).
pour le gui c'est pareil. je touche comme beaucoup de monde à xp,
unix, linux, mac.
> lequel qu'il faut préférer si on veut pas se casser la tête et en > rester à un GUI simple mais fonctionnel,
PLUIE3. Simple, mais avec des possibilités d'extensions/évolutions intéressantes.
> et multi-plateforme (Win, Mac 'Aqua') ?
Aïe. PLUIE fonctionne uniquement avec la famille Windows. Et encore, uniquement sur les Windows à noyau NT avec GUI (donc, pas sur les Win-9x, ni sur les CE, ni sur les éditions "Mobile", ni sur Core).
@-salutations -- Michel Claveau
bel effort et merci, mais je tiens de plus en plus à investir le peu de temps qu'il me reste à apprendre dans du multi-plateforme (d'où déjà le choix python). pour le gui c'est pareil. je touche comme beaucoup de monde à xp, unix, linux, mac.
Olivier
Christophe
Eric Brunel a écrit :
On Thu, 05 Feb 2009 09:32:17 +0100, OdarR wrote:
On 23 jan, 13:32, "Méta-MCI (MVP)" wrote:
Bonjour !
Malgré qu'il soit en anglais, cet article pourrait intéresser des pythonneux : http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57 -- @-salutations -- Michel Claveau
Bon, et finalement c'est lequel qu'il faut préférrer si on veut pas se casser la tête et en rester à un GUI simple mais fonctionnel, et multi- plateforme (Win, Mac 'Aqua') ?
Ah ben ça on va avoir du mal à choisir à ta place... Tout ça dépend de tes objectifs, de tes habitudes et de plein d'autres choses qui te sont personnelles.
Pour ma part, mon choix a été guidé par plusieurs critères: - D'abord, je ne voulais pas de bibliothèque monstrueuse qui réinventait l'eau tiède et redéfinissait tous les widgets sans s'occuper de la plateforme courante. Donc PyQt/QT et PyGtk/GTK étaient out...
Ce n'est plus d'actualité pour PyQt quand même. L'intégration de ce dernier est très très bien faite.
- Restaient donc en gros wxPython et Tkinter. Le fait est que j'avais commencé à utiliser le second il y a longtemps et que j'y étais plus habitué. Cela dit, même aujourd'hui, je pense que je referais le même choix, tout simplement parce que je n'arrive pas à me faire à l'API wxPython. Je trouve ça trop compliqué, avec trop de choses qui n'ont finalement pas grand chose à voir avec ce que je veux mettre dans ma GUI.
Je suis parfaitement d'accord avec ce choix. Je trouve l'API wx particulièrement lourde que ce soit en C++ ou en Python (qui au final la réplique très précisément). Cette API me rappelle furieusement l'API Win32 elle même en fait ce qui n'est pas un gage de qualité :)
Eric Brunel a écrit :
On Thu, 05 Feb 2009 09:32:17 +0100, OdarR <olivier.odar@gmail.com> wrote:
On 23 jan, 13:32, "Méta-MCI (MVP)" <enleverlesX.X...@XmclaveauX.com>
wrote:
Bonjour !
Malgré qu'il soit en anglais, cet article pourrait intéresser des
pythonneux :
http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57
--
@-salutations
--
Michel Claveau
Bon, et finalement c'est lequel qu'il faut préférrer si on veut pas se
casser la tête et en rester à un GUI simple mais fonctionnel, et multi-
plateforme (Win, Mac 'Aqua') ?
Ah ben ça on va avoir du mal à choisir à ta place... Tout ça dépend de
tes objectifs, de tes habitudes et de plein d'autres choses qui te sont
personnelles.
Pour ma part, mon choix a été guidé par plusieurs critères:
- D'abord, je ne voulais pas de bibliothèque monstrueuse qui réinventait
l'eau tiède et redéfinissait tous les widgets sans s'occuper de la
plateforme courante. Donc PyQt/QT et PyGtk/GTK étaient out...
Ce n'est plus d'actualité pour PyQt quand même. L'intégration de ce
dernier est très très bien faite.
- Restaient donc en gros wxPython et Tkinter. Le fait est que j'avais
commencé à utiliser le second il y a longtemps et que j'y étais plus
habitué. Cela dit, même aujourd'hui, je pense que je referais le même
choix, tout simplement parce que je n'arrive pas à me faire à l'API
wxPython. Je trouve ça trop compliqué, avec trop de choses qui n'ont
finalement pas grand chose à voir avec ce que je veux mettre dans ma
GUI.
Je suis parfaitement d'accord avec ce choix. Je trouve l'API wx
particulièrement lourde que ce soit en C++ ou en Python (qui au final la
réplique très précisément). Cette API me rappelle furieusement l'API
Win32 elle même en fait ce qui n'est pas un gage de qualité :)
Malgré qu'il soit en anglais, cet article pourrait intéresser des pythonneux : http://ojs.pythonpapers.org/index.php/tpp/article/view/61/57 -- @-salutations -- Michel Claveau
Bon, et finalement c'est lequel qu'il faut préférrer si on veut pas se casser la tête et en rester à un GUI simple mais fonctionnel, et multi- plateforme (Win, Mac 'Aqua') ?
Ah ben ça on va avoir du mal à choisir à ta place... Tout ça dépend de tes objectifs, de tes habitudes et de plein d'autres choses qui te sont personnelles.
Pour ma part, mon choix a été guidé par plusieurs critères: - D'abord, je ne voulais pas de bibliothèque monstrueuse qui réinventait l'eau tiède et redéfinissait tous les widgets sans s'occuper de la plateforme courante. Donc PyQt/QT et PyGtk/GTK étaient out...
Ce n'est plus d'actualité pour PyQt quand même. L'intégration de ce dernier est très très bien faite.
- Restaient donc en gros wxPython et Tkinter. Le fait est que j'avais commencé à utiliser le second il y a longtemps et que j'y étais plus habitué. Cela dit, même aujourd'hui, je pense que je referais le même choix, tout simplement parce que je n'arrive pas à me faire à l'API wxPython. Je trouve ça trop compliqué, avec trop de choses qui n'ont finalement pas grand chose à voir avec ce que je veux mettre dans ma GUI.
Je suis parfaitement d'accord avec ce choix. Je trouve l'API wx particulièrement lourde que ce soit en C++ ou en Python (qui au final la réplique très précisément). Cette API me rappelle furieusement l'API Win32 elle même en fait ce qui n'est pas un gage de qualité :)
Michel Claveau - NoSpam SVP ; merci
Bonsoir !
me rappelle furieusement l'API Win32
De quelle API parles-tu, précisément ? Parce que, dans Windows, des API GUI, il y en a plusieurs. Des anciennes API de Win-9x (qui fonctionnent encore, 10 ans après leur arrêt), à Silverlight, en passant par WPF, Direct-X, DA, etc. On a l'embarras du choix. Perso, j'ai opté, avec PLUIE, pour DHTML+DA.
Pour en revenir à wx, je trouve qu'il ressemble aux API de Win-3.1 ; donc de plus de 15 ans...
@-salutations -- Michel Claveau
Bonsoir !
me rappelle furieusement l'API Win32
De quelle API parles-tu, précisément ? Parce que, dans Windows, des API
GUI, il y en a plusieurs. Des anciennes API de Win-9x (qui fonctionnent
encore, 10 ans après leur arrêt), à Silverlight, en passant par WPF,
Direct-X, DA, etc. On a l'embarras du choix.
Perso, j'ai opté, avec PLUIE, pour DHTML+DA.
Pour en revenir à wx, je trouve qu'il ressemble aux API de Win-3.1 ;
donc de plus de 15 ans...
De quelle API parles-tu, précisément ? Parce que, dans Windows, des API GUI, il y en a plusieurs. Des anciennes API de Win-9x (qui fonctionnent encore, 10 ans après leur arrêt), à Silverlight, en passant par WPF, Direct-X, DA, etc. On a l'embarras du choix. Perso, j'ai opté, avec PLUIE, pour DHTML+DA.
Pour en revenir à wx, je trouve qu'il ressemble aux API de Win-3.1 ; donc de plus de 15 ans...
@-salutations -- Michel Claveau
Christophe
Michel Claveau - NoSpam SVP ; merci a écrit :
Bonsoir !
me rappelle furieusement l'API Win32
De quelle API parles-tu, précisément ? Parce que, dans Windows, des API
La vielle, l'API Win32 pour moi c'est celle qui a été introduite avec le premier OS Microsoft 32bit, le vénérable Windows 95 lui même. Sans doute que j'ai pris cette habitude car à l'époque, on l'opposait à l'API 16 bits de cette façon.
GUI, il y en a plusieurs. Des anciennes API de Win-9x (qui fonctionnent encore, 10 ans après leur arrêt), à Silverlight, en passant par WPF, Direct-X, DA, etc. On a l'embarras du choix. Perso, j'ai opté, avec PLUIE, pour DHTML+DA.
Pour en revenir à wx, je trouve qu'il ressemble aux API de Win-3.1 ; donc de plus de 15 ans...
Mmm, c'est trop loin pour moi, je ne faisais que du DOS directement à l'époque mais c'est vrai que l'API des Win9x devait ressembler pas mal à celle de Win 3.1 si je me souviens bien.
Michel Claveau - NoSpam SVP ; merci a écrit :
Bonsoir !
me rappelle furieusement l'API Win32
De quelle API parles-tu, précisément ? Parce que, dans Windows, des API
La vielle, l'API Win32 pour moi c'est celle qui a été introduite avec le
premier OS Microsoft 32bit, le vénérable Windows 95 lui même. Sans doute
que j'ai pris cette habitude car à l'époque, on l'opposait à l'API 16
bits de cette façon.
GUI, il y en a plusieurs. Des anciennes API de Win-9x (qui fonctionnent
encore, 10 ans après leur arrêt), à Silverlight, en passant par WPF,
Direct-X, DA, etc. On a l'embarras du choix.
Perso, j'ai opté, avec PLUIE, pour DHTML+DA.
Pour en revenir à wx, je trouve qu'il ressemble aux API de Win-3.1 ;
donc de plus de 15 ans...
Mmm, c'est trop loin pour moi, je ne faisais que du DOS directement à
l'époque mais c'est vrai que l'API des Win9x devait ressembler pas mal à
celle de Win 3.1 si je me souviens bien.
De quelle API parles-tu, précisément ? Parce que, dans Windows, des API
La vielle, l'API Win32 pour moi c'est celle qui a été introduite avec le premier OS Microsoft 32bit, le vénérable Windows 95 lui même. Sans doute que j'ai pris cette habitude car à l'époque, on l'opposait à l'API 16 bits de cette façon.
GUI, il y en a plusieurs. Des anciennes API de Win-9x (qui fonctionnent encore, 10 ans après leur arrêt), à Silverlight, en passant par WPF, Direct-X, DA, etc. On a l'embarras du choix. Perso, j'ai opté, avec PLUIE, pour DHTML+DA.
Pour en revenir à wx, je trouve qu'il ressemble aux API de Win-3.1 ; donc de plus de 15 ans...
Mmm, c'est trop loin pour moi, je ne faisais que du DOS directement à l'époque mais c'est vrai que l'API des Win9x devait ressembler pas mal à celle de Win 3.1 si je me souviens bien.