Consider an alternative to extending tk classes

[bennuttall]

A suggestion: rather than extend tk classes, would you consider creating new classes where the tk object is exposed as a property, so that only the guizero goodness is exposed to most users, but those who wish to (forgive me) tinker below the surface can still get to the nasty tk stuff?

The tk stuff is messy and most of it isn't useful. Using tab completion to find property and methods you're looking for is really difficult:

For example:

class Slider:
    def __init__(self, master, start=0, end=100, horizontal=True, command=None, grid=None, align=None):
        orient = HORIZONTAL if horizontal else VERTICAL
        self.tk = Scale(master, from_=start, to=end, orient=orient, command=command)
        utils.auto_pack(self, master, grid, align)

    @property
    def value(self):
        return (self.tk.get())

    @value.setter
    def value(self, value):
            self.tk.set(value)

    def add_command(self, command):
        self.tk.config(command=command)

So instead of inheriting Scale and running super()__init__() you create a tk Scale object belonging to the guizero Slider object. You would provide guizero alternatives to anything useful within the tk object, such as value and add_command as shown. Any methods which need access to the tk object just refer to self.tk instead of self.

The result:

Somewhat related to @martinohanlon's #25

[lawsie]

That seems nice. Need to find some time to work on this - haven't had much lately!

[lawsie]

Nice. I implemented this for Slider in a test version and it seems pretty cool. I don't have an IDE that offers the auto complete though so can't test that.

[bennuttall]

pip install ipython

It's just like the Python shell but better (no harder to use) 👍

[lawsie]

I think this approach runs into problems if you try to apply it to the App class. Because the other objects have to reference App, if you have an embedded Tk object within an App object, when another object references the App object as its master, it lacks the necessary properties of the Tk object to be able to act as the master. At least, I think that's what is happening. So, potentially I could apply this principle to all of the classes barring App (and possibly Box which is also a container)?

[bennuttall]

Yeah if you can't make it work for App or Box, then you could always leave them as they are.

[DavidWhaleMEF]

The app could have a tk property, and the child classes could access App.tk - so any child accesses the tk via it's parent (container) tk attribute. Just saying, because I might or might not have solved a similar problem myself recently :)

Tip: Get your head around the 'is-a' vs 'has-a' relationships, to get stronger architecture.

[lawsie]

I believe I have done this with commit 757beea

[bennuttall]

Neat! So we're just waiting for the 0.4 release? I'll test it when I get chance.

[lawsie]

Well, I have various other things that are unfinished and might not work - in particular the after() method, and some other extras I want to add. However I think I've successfully converted all of the classes to have an internal tk object!