Allow creation of tooltips for all widgets using keyword argument

[RedFantom]

As suggested by @Dogeek, having tooltips in a way that they are easier to create would be beneficial for a lot of developers. Therefore, I have devised a way based on the way mtTkinter works, redefining the ttk.Widget.__init__ function during runtime and by so doing inserting two new keyword arguments into it: tooltip and tooltip_options.

All the developer has to do is import the module from ttkwidgets (I do not intend for it to be imported by default, as there would be a performance penalty, even if slight) and the two new keyword arguments become available in all widgets derived from ttk.Widget. See the example also created for a usage example.

The commit adding these features may be found here.

This issue is intended for discussion of this feature until such a time that it is ready to merge.

[sbordeyne]

Although the idea of overwriting the __init__ method of a widget is tempting in a developer experience point of view, as it's the easiest to use by far, there's still an issue, in that if another library wants to supplement the __init__ method of the ttk::Widget class, then there will be compatibility issues. In an effort to keep this library both user-friendly, and compatible through other libraries code, I still think that redefining all of tkinter and ttk's widgets to make them inherit from our new base is the best course of action

example :

import tkinter as tk
import tkinter.ttk as ttk

class Widget(ttk.Widget):
    pass # our code here

class Canvas(Widget, tk.Canvas):
    pass

class Label(Widget, ttk.Label):
    pass

# etc...

It would technically be a mixin for ttk. Which I find to be a bit better as far as maintainability goes.

[RedFantom]

What do you think of the current implementation in hook.py? It addresses your concern that it may be incompatible with other libraries that may depend on overwriting __init__. The only concern left is name-aliasing, but I have opted to use a naming scheme which is extremely unlikely to be overwritten.

In addition, it supports adding multiple hooks to the ttk widget set. These hooks are executed sequentially. This way, it would be possible to easily add more keyword arguments if desired. This could reduce the boiler-plate code significantly.

The code is neither long nor very complicated, and I do intend to extend the documentation and comments so that it becomes easier to see what is going on.

[sbordeyne]

I don't think name aliasing would ever be a real concern, since the naming scheme is quite unique enough, and people usually namespace their stuff, so it shouldn't ever be a problem.

I'll have to look it over some more, cause it's the first time I've seen metaprogrammation this intense, so it'll take me a bit (by the way, in your lambda definitions, the first argument should probably be named w since it refers to a widget, I don't know why you chose s as the variable name)

[sbordeyne]

@RedFantom Whenever you've documented the hook.py class, I'd like you to make the proper implementation for it, in order to hook the Widget class created in base_widgets.base_widget (tkinterpp-tooltip branch) into the ttk::Widget class.

My idea was that the hooking should be done in the __init__.py file for that submodule, so that people could just import the submodule if they want the new features on their widgets.

The new Widget class also implements a new bind method, which would be necessary imo. It turns the default behavior of bind from "overwrite" to "add", when a new event is bound to the widget, which is necessary if people want the tooltips to show up and have other events trigger on the "" and "" binds.

[RedFantom]

Documentation in the file itself is now up to scratch and the implementation for hooking a keyword argument for the tooltip is available in tooltips.py, though so far I have not yet implemented the configuration of the tooltip options. As it hooks the ttk.Widget class, all ttk widgets are hooked, so as long as your base widget inherits from ttk.Widget, it will support the new keyword argument.

I intend to keep the tooltip hooking separate from the actual Tooltip widget, so that they may still be used separately.

Yes, I agree that the binding method should be changed. After all, it has always been confusing to me why with default arguments only a single function may be bound to a single event.