Démarrer avec wxpython

Installation de wxPython Phoenix

[wxPython Phoenix] [1] est la dernière version de wxPython (actuellement * septembre 2016 * sans version officielle). Il prend en charge Python 2 et Python 3. Vous pouvez télécharger une version instantanée (c’est-à-dire une roue Python) pour votre plate-forme et votre version Python [ici][2].

wxPython Phoenix utilise un mécanisme largement automatisé pour générer à la fois les liaisons python pour la bibliothèque wxWidgets et la documentation. La [documentation Phoenix wxPython][3] est spécifiquement générée pour elle-même en utilisant [Sphinx][4]. Cela augmente la clarté par opposition à la documentation C++ de la version classique, qui inclut de nombreuses surcharges qui ne sont pas disponibles dans wxPython.

Python et pip doivent être installés avant que wxPython Phoenix puisse être installé.

Vous pouvez utiliser pip pour installer la version Phoenix de wxPython. Voici la méthode recommandée actuellement :

python -m pip install --no-index --find-links=http://wxpython.org/Phoenix/snapshot-builds/ --trusted-host wxpython.org wxPython_Phoenix

Lorsque vous utilisez cette commande, pip installe également wxWidgets. Cette commande pip complexe deviendra probablement « pip install wxpython » lorsque Phoenix sera officiellement publié.

Remarque : wxPython Phoenix est actuellement en version bêta et ne dispose pas de tous les widgets de la version classique.

[1] : https://wiki.wxpython.org/ProjectPhoenix [2] : http://wxpython.org/Phoenix/snapshot-builds/ [3] : https://wxpython.org/Phoenix/docs/html/main.html [4] : http://sphinx-doc.org/

Installation de wxPython Classic

wxPython Classic est une version Python 2 de la bibliothèque wxPython. La génération des liaisons python nécessite un grand nombre d’interventions manuelles et la documentation est simplement la documentation wxWidgets qui contient quelques annotations sur les mécanismes wxPython en tant que tel il y a normalement un délai de plusieurs semaines à plusieurs mois entre une nouvelle version de wxWidgets et la version correspondante de wxPython .

Accédez à la page [téléchargement][1] sur le site Web de wxPython pour voir s’il existe déjà une version de wxPython que vous pouvez télécharger pour votre plate-forme.

La dernière version de Classic est 3.0.2.0

Les fenêtres

Il existe des programmes d’installation pour Python 2.6 et 2.7 pour les plates-formes Windows 32 bits et 64 bits sur le site Web. Il suffit de télécharger l’un d’entre eux et de l’exécuter pour l’installer.

Remarque : Assurez-vous de télécharger un programme d’installation wxPython pour le bon Python que vous avez installé. Par exemple, si vous avez Python 2.7 32 bits, vous voulez un programme d’installation wxPython 32 bits

Mac

Si vous avez OSX 10.5 ou supérieur, vous devrez télécharger et installer la version Cocoa de wxPython. La version Cocoa prend également en charge les Mac 64 bits.

Si vous avez un Mac avec une version d’OSX inférieure à 10.5, vous voudrez la version Carbon.

Linux

La première chose à vérifier est le gestionnaire de packages de votre plate-forme Linux (c’est-à-dire yum, apt-get, etc.) pour voir s’il dispose d’une version de wxPython que vous pouvez installer. Malheureusement, de nombreux packages Linux pour wxPython sont pour la version 2.8.12.1 au lieu de 3.0.2.0. Si votre gestionnaire de paquets n’a pas la dernière version, vous devrez probablement la construire vous-même.

Il existe des instructions de construction pour 3.0.2.0-Classic [ici] [2]

[1] : https://wxpython.org/download.php [2] : https://wxpython.org/builddoc.php

Bonjour le monde

Un moyen simple de créer un programme Hello World :

import wx
app = wx.App(redirect=False)
frame = wx.Frame(parent=None, id=wx.ID_ANY, title='Hello World')
frame.Show()
app.MainLoop()

Production:

[![Sortie Hello World][1]][1]

Un exemple plus typique serait de sous-classer wx.Frame :

import wx

class MyFrame(wx.Frame):

    def __init__(self):
        wx.Frame.__init__(self, None, title='Hello World')
        self.Show()

if __name__ == '__main__':
    app = wx.App(redirect=False)
    frame = MyFrame()
    app.MainLoop()

Cela peut également être réécrit pour utiliser le super de Python :

import wx  

class MyFrame(wx.Frame):
        
    def __init__(self, *args, **kwargs):
        """Constructor"""
        super(MyFrame, self).__init__(*args, **kwargs)
        self.Show()

if __name__ == '__main__':
    app = wx.App(False)
    frame = MyFrame(None, title='Hello World')
    app.MainLoop()

[1] : http://i.stack.imgur.com/BxlIr.png

Qu’est-ce qu’une série de versions wxPython ?

Le projet wxWidgets a adopté le modèle de version utilisé par le projet Linux Kernel où il existe des ensembles alternés de versions où un ensemble est considéré comme “stable” et l’ensemble suivant est considéré comme “développement”. Pour wxWidgets, “stable” et “development” ne font pas référence au bogue, mais à la stabilité de l’API et à la rétrocompatibilité.

  • Stable : pendant la durée de la série, les API existantes ne sont pas modifiées, bien que de nouvelles méthodes de classe non virtuelles et autres puissent être ajoutées. La compatibilité binaire des bibliothèques C++ est maintenue en n’autorisant aucune modification modifiant la taille ou la disposition en mémoire des classes et des structures. Cela peut imposer et impose souvent des limitations sur les types d’améliorations ou de corrections de bogues pouvant être effectuées dans une série de versions stables, mais cela n’affecte vraiment que la couche C++ car en Python, la rétrocompatibilité a une connotation légèrement différente.

  • Développement : l’objectif principal de la série de versions de développement est d’ajouter de nouvelles fonctionnalités ou de corriger des problèmes qui n’ont pas pu être corrigés dans une série stable en raison de problèmes de compatibilité binaire, le tout dans le but de créer la prochaine série stable . Ainsi, pendant la durée de la série de développement existante, les API peuvent être modifiées ou supprimées selon les besoins, bien que la plupart du temps, la compatibilité au niveau de la source C++ soit maintenue via des fonctions ou des macros surchargées obsolètes, etc. Pour wxPython, cela signifie souvent qu’il y aura être des incompatibilités au niveau de la source car il n’y a pas de surcharge ou de macros, et afin de prendre en charge la nouvelle version de l’API, l’ancienne version doit parfois être supprimée.

En raison des problèmes de compatibilité binaire, la dernière version de développement de wxWidgets/wxPython peut souvent être moins boguée que la dernière version de la dernière série de versions stables. Cependant, il y a le compromis que les API peuvent changer ou évoluer entre les versions de la série de développement.

Comment fonctionnent les numéros de version ?

Pour les versions, wxPython utilise un numéro de version à 4 composants. Bien que cela ressemble beaucoup à la façon dont les numéros de version sont utilisés dans d’autres projets Open Source, il existe quelques différences subtiles. Ainsi, pour certaines versions A.B.C.D, vous pouvez en déduire ce qui suit :

  1. Série de versions : les deux premiers composants du numéro de version (A.B) représentent la série de versions, et si le composant B est un nombre pair, il s’agit d’une série stable, si c’est un nombre impair alors c’est une série de versions de développement. Par exemple, 2.4, 2.6 et 2.8 sont stables et l’API est plus ou moins figée dans chaque série, et 2.3, 2.5 et 2.7 sont en cours de développement et l’API et les fonctionnalités peuvent changer ou évoluer selon les besoins.

Pour cette raison, il peut y avoir des changements assez importants entre une série stable et la suivante (disons 2.4 à 2.6) et cela déroute souvent les gens car dans d’autres projets, des changements de cette ampleur auraient provoqué le changement du premier composant du numéro de version. Au lieu de cela, vous devriez considérer la combinaison de A.B comme étant le numéro majeur de la version.

  1. Numéro de version : le troisième composant du numéro de version (C) représente l’une des versions d’une série de versions. Par exemple, 2.5.0, 2.5.1, 2.5.2, 2.5.3… sont toutes des versions de la série de versions 2.5. (Et puisque dans ce cas, il s’agit d’une série de développement, l’API et les fonctionnalités de 2.5.3 ont évolué pour être différentes par endroits de ce qu’elles étaient dans 2.5.0.) Les versions C++ wxWidgets s’arrêtent généralement ici et seules les versions A.B.C sont créées.

  2. Numéro de sous-version ou version de wxPython : le quatrième composant du numéro de version (D) est utilisé pour représenter une sous-version ou des versions incrémentielles entre les versions officielles de wxWidgets. Ces versions incluent des correctifs pour les bogues wxWidgets que wxPython peut avoir exposés, ou des améliorations mineures qui sont importantes pour wxPython. Il ne s’agit pas d’un instantané arbitraire de wxWidgets, mais plutôt d’une version testée du code avec des correctifs et des améliorations qui ne sont pas encore disponibles à partir de wxWidgets, à l’exception du référentiel de code source.

Source : https://wiki.wxpython.org/ReleaseSeries