Discussion :

[Apranax]

Bonjour.

Je débute en Python et j'essaie de comprendre le fonctionnement.

Lorsque l'on crée un Label tkinter

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
tex1=Label(fen1,text='Bonjour',fg='red')

Text et fg sont-ils des attributs de tex1 ? Lorsque j'entre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
tex1.text

Python retourne une erreur : Label object has no attribute text.

J'ai vu que l'on pouvait modifier le texte avec la méthode config, avec text en argument.

Quel est le statut des arguments lorsque l'on crée un Label (je pensais pouvoir modifier en écrivant tex1.text='Aurevoir') ?

Merci.

[PauseKawa]

Bonjour,

Tout simplement car 'text n'est pas un 'attribut' Python mais Tcl/Tk'.

Il me raconte quoi lui ?

Pour rappel T(t)kinter est un Wrapper de Tcl/Tk
A partir de là il fournis des classes Python (ici pour vous la classe Label) permettant de créer/gérer (entre autre) des objets Tcl/Tk ayants leurs méthodes/attributs.
Vous y avez accès via:
label['text']
label.config(text='texte') (config=configure)
ou encore
label.cget('text') (label.__getitem__('text'))

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
    def cget(self, key):
        """Return the resource value for a KEY given as string."""
        return self.tk.call(self._w, 'cget', '-' + key)
    __getitem__ = cget
    def __setitem__(self, key, value):
        self.configure({key: value})

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
>>> l['text'] = 'toto'
>>> l['text']
'toto'

Edit: Comprendre par la qu'utiliser un wrapper pour comprendre les attributs/méthodes n'est pas une bonne idée

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
>>> l = Tk.Label()
>>> l.config(text='toto')
>>> l['text']
'toto'
>>> l.text = 'tutu'
>>> l.text
'tutu'
>>> l['text']
'toto'
>>> l.cget('text')
'toto'

[Apranax]

Merci pour cette réponse détaillée.

Tkinter n'est donc pas conçu à la base pour Python, mais adapté, et les principes que j'ai vu pour Python ne se transpose pas forcément ?

Est-ce que toutes les interfaces graphiques ont leur propre mode de fonctionnement ?

[wiztricks]

Salut,

Tkinter n'est donc pas conçu à la base pour Python, mais adapté, et les principes que j'ai vu pour Python ne se transpose pas forcément ?

Si vous prenez la peine de lire la documentation sur l'interface Tk vous verrez qu'on parle "d'option" pour les "objets" Tk et non d'attributs.
"text" est "option" de l'objet tk "label" et non attribut de la classe Python correspondante.

Est-ce que toutes les interfaces graphiques ont leur propre mode de fonctionnement ?

Il existe plein d'interfaces graphiques (GUI) accessibles via Python: Wx, GTK, Qt,.. le seul avantage de tkinter est qu'il est livrée avec Python de base (pas besoin d'installer autre chose...).

Pour des raisons d'efficacité, ces GUI sont écrits en C ou C++ (Tk est écrit en C). L'accès a la librarie C depuis Python (interprété) se fera via une "couche d'interface" qui permettra d'accéder aux fonctionnalités du GUI par des objets Python.

Tous ces GUI définissent widgets, modalité de changements de leur état,... et des modalités différentes pour construire une interface utilisateur "avec".
(et ce même si "in fine" le look & feel pourra être "semblable").

Pour ne pas ré-écrire une documentation de Tk, Qt,... spécifique à Python, cette couche d'interface doit éviter de réaliser plus qu'un "wrapper": i.e. des principes de "mapping" entre les objets du GUI et les objets "Python" présentés par l'interface et la documentation d'utilisation "native" du GUI (présentant les interfaces C++, C ou TCL dans le cas de Tk) pour le reste.

Pour le programmeur "avancé" la difficulté est ensuite d'apprendre à traduire ce que dit la documentation "native" dans la représentation Python associée.
Ceci dit en général, il y a de bon tutos qui permettre de faire les premiers pas pour acquérir ces automatismes tout en apprenant les bases d'utilisation du GUI (qu'il faut bien faire).

Cordialement,
- W

[PauseKawa]

Si vous prenez la peine de lire la documentation sur l'interface Tk vous verrez qu'on parle "d'option" pour les "objets" Tk et non d'attributs.
"text" est "option" de l'objet tk "label" et non attribut de la classe Python correspondante.

Merci pour la rectification wiztricks ().
Pour ce qui est de tkinter on parle bien d'options (standard ou spécifique)
Vous pouvez les retrouver dans la doc ou via nomduwidget.keys(), cela n'as rien a voir avec ce que vous retourne un dir(nomduwidget)

[Apranax]

Encore merci, je vais poursuivre mon travail.

[wiztricks]

Salut,

Merci pour la rectification wiztricks ().
Pour ce qui est de tkinter on parle bien d'options (standard ou spécifique)
Vous pouvez les retrouver dans la doc ou via nomduwidget.keys(), cela n'as rien a voir avec ce que vous retourne un dir(nomduwidget)

Mon propos n'était pas de "rectifier" mais d'essayer d'apporter un autre éclairage sur cette notion d'interface et comment positionner le curseur entre une interface bête et méchante avec les API d'une librairie écrite dans d'autres langages et les éventuelles implications d'une chose plus "Pythonique".

En fait, côté Python, rien n'empêcherait de définir un attribut "text" qui soit mis en correspondance avec l'option "text" via un __getattr__ ou autre descriptor.

Mais une fois le pied là dedans, où s'arrêter?
Et comment garder une interface suffisamment "light" pour que la documentation TCL/TK reste "utilisable" (et ne pas avoir à faire une documentation spécifique).
nota, je ne suis pas convaincu que tkinter soit aussi "light" que çà.

Cordialement,
- W