Discussion :

[PauseKawa]

Je proposais de coder une fonction delta(event) qui calcule le delta en fonction de la plate-forme, i.e. pousser le spécifique le plus bas quand c'est possible.

Dans cette approche

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
    def __mouse_wheel__(event):
        # Boutton 4
        if event.num == 4:
            delta = -1
        # Button 5
        elif event.num == 5:
            delta = 1
        # event.delta
        else:
            delta = int(event.delta)
        self.index += delta
        __actu_entry__()

Il ne manque plus que quelques print sous win/mac pour le else et cela devrait le faire.

Edit:
Si des mac/windows peuvent donner le résultat de ce qui suit... Merci d'avance :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
try:
    import Tkinter as Tk
except:
    import tkinter as Tk
 
def OnMove(event):
    print(event.delta)
 
root = Tk.Tk()
root.bind('<MouseWheel>', OnMove)
root.mainloop()

[MzBouba]

Alors Windows

-120 et 120

delta
Pour des événements MouseWheel (roue de souris), cet attribut contient un entier dont le signe est positif pour faire défiler en haut, et négatif pour faire défiler en bas. Sous Windows, cette valeur sera un multiple de 120; par exemple, 120 signifie faire défiler en haut d'un pas et -240 faire défiler en bas de deux pas. Sous MacOS, il sera un multiple de 1, ainsi 1 signifie faire défiler en haut d'un pas et -2 faire défiler en bas de deux pas. Pour le support de roue de souris Linux, voir la note sur l'attache d'événement de Bouton dans la section (p.).

[PauseKawa]

Dans ce cas:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    def __mouse_wheel__(event):
        # Boutton 4
        if event.num == 4:
            delta = -1
        # Button 5
        elif event.num == 5:
            delta = 1
        # event.delta
        else:
            if int(event.delta)%120 == 0:
                delta = int(event.delta/120)
            else:
                delta = int(event.delta)
        self.index += delta
        __actu_entry__()

Et on garde les trois bind

[MzBouba]

comment appelez vous la méthode __mouse_wheel__.
Sur linux, le bind '<MouseWheel> n 'existe pas ?

[PauseKawa]

<MouseWheel> est considéré comme un virtual event

[MzBouba]

Si je comprend bien on laisse

Code :

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

self.entry.bind('<MouseWheel>', __mouse_wheel__)

Pourtant sous linux, la methode n'est pas appelé

[wiztricks]

Salut,
Non je pensais plutôt à qqc comme une fonction qui construise la bonne fonction (non testée):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
def delta():
    if platform.startswith('linux'):
        def get_value(event):
            if event.num == 4:
                return -1
            elif event.num == 5:
                return 1
            return 0
    elif platform == 'win32':
        get_value = lambda e: -e.delta // 120
    elif platform == 'darwin':
        get_value = lambda e: -e.delta
    return get_value

Pour pouvoir faire:

Code :

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

self.entry.bind('<<MouseWheel>>', lambda e: self._update_index(delta()(e)))

Ce qui suppose créer le "virtual event" <<MouseWheel>> en fonction de la plate-forme:

Code :

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

1
2
.event_add('<<MouseWheel>>', '<Button-4>', '<Button-5>') #pour Linux et
.event_add('<<MouseWheel>>', '<MouseWheel>') #pour les autres.

La motivation étant qu'il n'y a pas de bonne raison d'enfouir ces dépendances côte plate-forme "trop" dans le "widget" car elles pourraient être "utilisées" "ailleurs".

- W

[PauseKawa]

Pourquoi ne pas 'normaliser'

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
 
try:
    import Tkinter as Tk
except:
    import tkinter as Tk
 
 
def GenerateMouseWheel(e, delta):
    if hasattr(e.widget, 'focus_displayof'):
        e.widget.event_generate('<MouseWheel>', delta=delta, state=e.state,
                                rootx=e.x_root, rooty=e.y_root, x=e.x, y=e.y,
                                time=e.time)
 
def MouseWheelEvent(event):
    if event.delta%120 == 0:
        delta = event.delta/120
    else:
        delta = event.delta
    print(delta)
 
 
root = Tk.Tk()
root.bind_all('<Button-4>', lambda e: GenerateMouseWheel(e, 120))
root.bind_all('<Button-5>', lambda e: GenerateMouseWheel(e, -120))
root.bind('<MouseWheel>', MouseWheelEvent)
root.mainloop()

[wiztricks]

Salut,

Pourquoi ne pas 'normaliser'

L

La fonction delta "normalise" déjà (et les autres méthodes employées) le retour d'event.delta (indépendamment de la plate-forme).
Et si çà fonctionne... qu'est ce qui nous fera préférer une solution par rapport à une autre?

Dans le cas de "GenerateMouseWheel", je suis perplexe sur les .bind_all car il va falloir gérer des events même pour les widgets qui ne les écoutent pas.

Mais, j'aime bien l'idée des .bindtags qui permettent de 'stacker' les objets à qui pourront être expédiés les 'events'. Car, on peut "potentiellement" remplacer _all par ce qu'on veut et créer un gestionnaire d'évènements qui pourra être associé au widget.

Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import tkinter as tk
from tkinter.constants import *
 
def on_click(event, who=''):
    print ('who: %s, window: %s' %  (who, event.widget))
 
root = tk.Tk()
frame = tk.Frame(root, name='frame')
frame.bind('<1>', lambda e: on_click(e, who='frame'))
 
entry = tk.Entry(root, name='entry')
entry.bind('<1>', lambda e: on_click(e, who='entry'))
 
tags = list(entry.bindtags())
tags.insert(1, frame._w)
entry.bindtags(tuple(tags))
entry.insert(END, 'sfshdjkhsdh')
entry.pack()
 
tk.mainloop()

Ca fait quoi?
On crée frame et entry comme fils de root avec le bind d'un click sur le button-1 qui va afficher: le widget et le "bind" correspondant.
Puis côté .bindtags, on intercale la "frame" juste après "entry".
(Et pas besoin d'afficher 'frame' pour que çà fonctionne).

- W

[MzBouba]

La je commence à être un peu perdu.
Mes connaissances n'en sont pas encore là.

[PauseKawa]

Boujour,

La fonction delta "normalise" déjà (et les autres méthodes employées) le retour d'event.delta (indépendamment de la plate-forme).
Et si çà fonctionne... qu'est ce qui nous fera préférer une solution par rapport à une autre?

C'est bien pour cela que j'ai proposé d'utiliser event.delta/event.num plutôt que de tester sys.platform qui ne sert qu'a donner la fonction adéquate (que ce soit pour delta ou autre self.entry.bind('<Button-4>', lambda e: __mouse_linux__(-1))).
En fait nous avons bien plus dans l'event et la fonction pourrait se nommer _update_index, comme proposé, et remplacerait aussi les __keypress_up__ et autres __keypress_down__.
Puisque nous avons tout dans l'event je me dit qu'il est inutile de se perdre dans quelque chose que nous ne 'contrôlons pas' (cf le platfrom.startswith).
A partir de la sys.platform ne sert que pour le bg='white': N'est il pas plus sage de se poser la question sur la géométrie avec Tkinter pour arriver à quelque chose d'universel ?

Dans le cas de "GenerateMouseWheel", je suis perplexe sur les .bind_all car il va falloir gérer des events même pour les widgets qui ne les écoutent pas.

Ce n'est que pour l'exemple (vous remarquerez que ce n'est pas appliqué au code de MzBouba): Générer un virtual event '<MouseWheel>' sans être plateform dépendant.

Ce qui suppose créer le "virtual event" <<MouseWheel>> en fonction de la plate-forme

L'utilisation des tags est quelque chose de puissant (tout le contenu de Misc en fait (+ lambda)) sous Tkinter mais comme nous n'avons ici a gérer qu'un Widget est ce vraiment utile ?

@+

[PauseKawa]

Code :

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

1
2
3
4
5
 
    #
    def index_to_item(self, index=0):
        """Renvoi l'élément de la liste se trouvant à la ligne(index)"""
        return self.items[index]

Tite question.
Pensez-vous qu'il est utile de mettre des if, try ...
Après tout, autant que cela est le même fonctionnement qu'une liste non ?

Pour rappel le code d'origine était

Code :

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

1
2
3
4
    def index_to_item(self, index=0):
        """Renvoi l'élément de la liste se trouvant à la ligne(index)"""
        try: return self.items[index]
        except: pass

Ici la première erreur attendue est IndexError
soit du fait que nous passions un index (list index out of range) qui n'est pas dans la liste,
soit que nous ne passions pas d'index et la index = 0 (list index out of range si len(liste) == 0).
Dans ce cas nous pouvons utiliser if x > len(liste)-1

La deuxième erreur est humaine: L'utilisateur passe autre chose qu'un int et la il est possible de tester type(index).

Cela donne

Code :

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

1
2
3
4
5
6
 
    #
    def index_to_item(self, index=0):
        """Renvoi l'élément de la liste se trouvant à la ligne(index)"""
        if type(index) == int and index > len(self.items):
            return self.items[index]

On teste en premier le type d'index avant d'en vérifier la valeur, if s’arrête au premier False.

Personnellement je remplacerais index=0 par index pour deux raisons (déjà abordé):
1) Vous documentez le code donc l'utilisateur sait qu'il doit donner un index. De plus le nom index_to_item est assez explicite pour qu'il comprenne qu'il doit donner un index. Après cela il mérite une erreur TypeError: index_to_item() takes exactly 2 arguments (1 given)
2) Si la liste est vide on tombe sur IndexError (voir plus haut).

Quiz du try:
Je n'ai rien contre try mais seulement s'il y a risque d'erreur inattendue.
Je laisserais à try la gestions des erreurs et éviterais les try/except pass qui ne remontent rien d’intéressant (c'est ce que je nomme le cache misère).
Il est possible d'écrire quelque chose comme:

Code :

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

1
2
3
4
5
6
try:
    ....
except TypeError:
    ...
except IndexError:
    ...

Mais pourquoi le gérer comme cela alors que l'utilisateur mérite une erreur ?

Donc oui pour if et non pour try.

@+

[wiztricks]

Salut,

L'utilisation des tags est quelque chose de puissant (tout le contenu de Misc en fait (+ lambda)) sous Tkinter mais comme nous n'avons ici a gérer qu'un Widget est ce vraiment utile ?

C'est juste pour accommoder les effets du .bind_all (que vous avez) proposé.

Et accessoirement "ouvrir" la porte sur l'intérêt du paramètre class_ dans la construction de Widget Tk à partir de tkinter.


-W

[PauseKawa]

J'avais bien compris le sens de tout cela.
En fait je pense que nous devrions oublier cette histoire de bind_all (et autre), hors contexte, du fait de n'avoir qu'un Widget a gérer. L'utilisation de l'event me semble bien plus simple.

[MzBouba]

Personnellement je remplacerais index=0 par index pour deux raisons (déjà abordé):
1) Vous documentez le code donc l'utilisateur sait qu'il doit donner un index. De plus le nom index_to_item est assez explicite pour qu'il comprenne qu'il doit donner un index. Après cela il mérite une erreur TypeError: index_to_item() takes exactly 2 arguments (1 given)
2) Si la liste est vide on tombe sur IndexError (voir plus haut).

Oui, j'ai commencer à revoir le code dans ce sens.
De même, que pour les if et try.

Concernant le bindtag, est il possible de les utiliser dans la gestion de fermeture de la toplevel.
En faisant plusieurs tests sur Windows et Linux, j'ai constaté qu'il y a beaucoup de bind ('<FocusOut>, <Map>, <Configure> <Leave>) à gérer afin d'avoir un comportement cohérent, le principé étant que, la toplevel doit se fermer dès l'instant où je clique (quelque soit le bouton de soursi) en dehors de son cadre.
J'ai constaté aussi que le clique sur le cadre de la fenêtre principal ne fermait pas la toplevel, et ceux malgré un self.bind_all(<Button-1>, ...).

[MzBouba]

Code :

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

1
2
3
4
5
6
 
    #
    def index_to_item(self, index=0):
        """Renvoi l'élément de la liste se trouvant à la ligne(index)"""
        if type(index) == int and index > len(self.items):
            return self.items[index]

Oui cela me semble très bien !!!!!

[PauseKawa]

En faisant plusieurs tests sur Windows et Linux, j'ai constaté qu'il y a beaucoup de bind ('<FocusOut>, <Map>, <Configure> <Leave>) à gérer afin d'avoir un comportement cohérent, le principé étant que, la toplevel doit se fermer dès l'instant où je clique (quelque soit le bouton de soursi) en dehors de son cadre.
J'ai constaté aussi que le clique sur le cadre de la fenêtre principal ne fermait pas la toplevel, et ceux malgré un self.bind_all(<Button-1>, ...).

Normalement <FocusOut> est la pour cela: Avez vous tester avec self.toplevel.overrideredirect(1) après la création des Widgets et les binds ?

[MzBouba]

C'est ok sur windows et linux.
Par contre sur windows, j'ai toujours cet effet indésirable d'ouverture instantanée de la toplevel lors du double appuie sur le bouton.

[PauseKawa]

Par contre sur windows, j'ai toujours cet effet indésirable d'ouverture instantanée de la toplevel lors du double appuie sur le bouton.

C'est a dire un double clic (<Double-Button-1>) ? Comme si command=self.__create_toplevel__ était executé deux fois avant le

Code :

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

1
2
3
4
5
6
7
8
        if self.toplevel:
            close_list()
            return
        self.button.config(text='▲')
        self.toplevel=Toplevel(self,
                                self.__widget_arg__('toplevel', self.Arg),
                                #height=self.height,
                                )

?

[MzBouba]

C'est a dire un double clic (<Double-Button-1>) ? Comme si command=self.__create_toplevel__ était exécuté deux fois avant le

Non pas le double clic, voici ce qui se passe sous Windows :
1er appui sur le bouton: la toplevel s'ouvre.
2eme appui sur le bouton (alors que la toplevel est toujours ouverte):
1/Ferme la toplevel
2/Rouvre la toplevel instantanément

En fait, voici ce que je conclu:
lors du deuxième appui, voilà ce qu'il se passe:
1ere étape => la souris va sur la fenêtre principal.
Le click, <Button-1>, de la souris "enlève" le focus de la toplevel et la ferme (dû au bind <FocusOut>).
2eme étape => Au relaché du bouton de souris (<ButtonRelease-1>), activation de 'command=__create_list__' du bouton et rouvre donc la toplevel.