TKinter in Python - advanced notions

[Chris Angelico]

On Sat, 24 Jun 2023 at 15:57, Thomas Passin via Python-list
<python-list at python.org> wrote:
> As a general comment (and I have not done anything tricky or complex
> with Tk), MVC or the other approaches in a similar vein, though good,
> can lead you into more complexity than you need, because of the extra
> abstractions involved.  Yes, for sure the GUI should not be doing domain
> or business logic. Yes, it's good to keep database access separate from
> the other parts of your program. But you may not need all the classes
> and layers that you think you might.  It all depends on what you need to
> do, of course.
>
> Another useful design thought is to try to keep as much of the GUI logic
> separate from Tk itself as possible.  Basically, you would write a more
> abstract (and simpler) GUI API, and then write an adapter that knows how
> to make Tk do those things.  One advantage is that this approach makes
> it easier to change to another GUI toolkit later (say PyQt, for
> example).  Another is that it helps you avoid getting sucked into too
> many Tk details that aren't needed for the program concept.

I'd agree, although what I would call this is a GUI *skeleton*. It's
not usually worth trying to isolate that from the actual GUI once you
reach production, but it's a great first step as you're building.

MVC and other such design patterns are excellent tools for learning
and conceptualizing, but I agree, it's not something you have to feel
locked into. When talking with students, I'll ask them to show me
whether something is part of the model, the view, or the controller,
but only to make sure they know what their code is doing. It's not
like I would ask them to make three separate files (usually - maybe
I'd pitch that to a struggling student as a teaching tool, but not in
prod).

ChrisA