Найкращий спосіб структурувати додаток tkinter?

Далі йде загальна структура моєї типової програми python tkinter.

def funA():
    def funA1():
        def funA12():
            # stuff

    def funA2():
        # stuff

def funB():
    def funB1():
        # stuff

    def funB2():
        # stuff

def funC():
    def funC1():
        # stuff

    def funC2():
        # stuff


root = tk.Tk()

button1 = tk.Button(root, command=funA)
button1.pack()
button2 = tk.Button(root, command=funB)
button2.pack()
button3 = tk.Button(root, command=funC)
button3.pack()

funA funBі funCвідобразить ще одне Toplevelвікно з віджетами, коли користувач натисне кнопку 1, 2, 3.

Мені цікаво, чи це правильний спосіб написати програму python tkinter? Звичайно, це спрацює, навіть якщо я напишу так, але це найкращий спосіб? Це звучить нерозумно, але коли я бачу коди, написані іншими людьми, їхній код не переплутаний з купою функцій, і в основному у них є класи.

Чи є якась конкретна структура, яку ми повинні дотримуватися як добру практику? Як мені запланувати перед тим, як почати писати програму python?

Я знаю, що немає такої речі, як найкраща практика в програмуванні, і я цього не прошу. Мені просто хочеться поради та пояснень, щоб вести мене в правильному напрямку, коли я сам навчаюсь Python.

Я виступаю за об'єктно-орієнтований підхід. Це шаблон, з якого я починаю:

# Use Tkinter for python 2, tkinter for python 3
import tkinter as tk

class MainApplication(tk.Frame):
    def __init__(self, parent, *args, **kwargs):
        tk.Frame.__init__(self, parent, *args, **kwargs)
        self.parent = parent

        <create the rest of your GUI here>

if __name__ == "__main__":
    root = tk.Tk()
    MainApplication(root).pack(side="top", fill="both", expand=True)
    root.mainloop()

Важливо помітити:

• Я не використовую імпорт підстановки. Я імпортую пакунок як "tk", що вимагає попередньо встановити всі команди tk.. Це запобігає забрудненню глобального простору імен, а також робить код абсолютно очевидним при використанні класів Tkinter, класів ttk або деяких власних.

• Основний додаток - клас . Це дає вам приватний простір імен для всіх ваших зворотних дзвінків та приватних функцій, і просто в цілому полегшує організацію коду. У процедурному стилі ви повинні кодувати зверху вниз, визначаючи функції перед їх використанням тощо. За допомогою цього методу ви цього не робите, оскільки ви фактично не створюєте головне вікно до останнього кроку. Я вважаю за краще успадковувати tk.Frameлише тому, що я зазвичай починаю зі створення кадру, але це аж ніяк не потрібно.

Якщо у вашому додатку є додаткові вікна на рівні рівнів, я рекомендую зробити кожен із них окремим класом, успадковуючи його tk.Toplevel. Це дає всі ті ж переваги, про які було сказано вище - вікна атомні, у них є власний простір імен, і код добре організований. Крім того, це дозволяє легко вставити кожен у свій модуль, як тільки код починає набирати великі розміри.

Нарешті, ви можете розглянути можливість використання класів для кожної основної частини вашого інтерфейсу. Наприклад, якщо ви створюєте додаток за допомогою панелі інструментів, панелі навігації, панелі стану та основної області, ви можете зробити кожен з цих класів. Це робить ваш основний код досить малим і легким для розуміння:

class Navbar(tk.Frame): ...
class Toolbar(tk.Frame): ...
class Statusbar(tk.Frame): ...
class Main(tk.Frame): ...

class MainApplication(tk.Frame):
    def __init__(self, parent, *args, **kwargs):
        tk.Frame.__init__(self, parent, *args, **kwargs)
        self.statusbar = Statusbar(self, ...)
        self.toolbar = Toolbar(self, ...)
        self.navbar = Navbar(self, ...)
        self.main = Main(self, ...)

        self.statusbar.pack(side="bottom", fill="x")
        self.toolbar.pack(side="top", fill="x")
        self.navbar.pack(side="left", fill="y")
        self.main.pack(side="right", fill="both", expand=True)

Оскільки всі ці екземпляри мають спільний батьківський контроль, батько фактично стає частиною "контролера" архітектури модельного перегляду та контролера. Так, наприклад, головне вікно може розмістити щось на панелі стану, зателефонувавши self.parent.statusbar.set("Hello, world"). Це дозволяє визначити простий інтерфейс між компонентами, допомагаючи зберегти з’єднання до мінімуму.

Розміщення кожного вікна верхнього рівня в його окремий клас дає можливість повторного використання коду та кращу організацію коду. Будь-які кнопки та відповідні методи, наявні у вікні, повинні бути визначені всередині цього класу. Ось приклад (взято звідси ):

import tkinter as tk

class Demo1:
    def __init__(self, master):
        self.master = master
        self.frame = tk.Frame(self.master)
        self.button1 = tk.Button(self.frame, text = 'New Window', width = 25, command = self.new_window)
        self.button1.pack()
        self.frame.pack()
    def new_window(self):
        self.newWindow = tk.Toplevel(self.master)
        self.app = Demo2(self.newWindow)

class Demo2:
    def __init__(self, master):
        self.master = master
        self.frame = tk.Frame(self.master)
        self.quitButton = tk.Button(self.frame, text = 'Quit', width = 25, command = self.close_windows)
        self.quitButton.pack()
        self.frame.pack()
    def close_windows(self):
        self.master.destroy()

def main(): 
    root = tk.Tk()
    app = Demo1(root)
    root.mainloop()

if __name__ == '__main__':
    main()

Також дивіться:

• простий світ привіт від tkinter docs
• Приклад коду Tkinter для кількох вікон, чому кнопки не завантажуються правильно?
• Tkinter: Як показати / приховати вікно

Сподіваюся, що це допомагає.

Це не погана структура; це буде працювати чудово. Однак у функції потрібно виконувати команди, коли хтось натискає кнопку або щось таке

Тож, що ви можете зробити, це написати класи для них, тоді у класі є методи, які обробляють команди для натискання кнопки і таке інше.

Ось приклад:

import tkinter as tk

class Window1:
    def __init__(self, master):
        pass
        # Create labels, entries,buttons
    def button_click(self):
        pass
        # If button is clicked, run this method and open window 2


class Window2:
    def __init__(self, master):
        #create buttons,entries,etc

    def button_method(self):
        #run this when button click to close window
        self.master.destroy()

def main(): #run mianloop 
    root = tk.Tk()
    app = Window1(root)
    root.mainloop()

if __name__ == '__main__':
    main()

Зазвичай програми tk з декількома вікнами - це кілька великих класів, і __init__всі записи, мітки тощо створюються, і тоді кожен метод полягає в обробці подій натискання кнопки

Насправді це не правильний спосіб зробити це, що б не працювало для вас, і робота буде виконана до тих пір, поки вона не читається, і ви можете легко пояснити це, тому що якщо ви не можете легко пояснити свою програму, мабуть, є кращий спосіб це зробити. .

Погляньте на Мислення в Tkinter .

OOP повинен бути підходом і frameповинен бути змінною класу замість змінної екземпляра .

from Tkinter import *
class App:
  def __init__(self, master):
    frame = Frame(master)
    frame.pack()
    self.button = Button(frame, 
                         text="QUIT", fg="red",
                         command=frame.quit)
    self.button.pack(side=LEFT)
    self.slogan = Button(frame,
                         text="Hello",
                         command=self.write_slogan)
    self.slogan.pack(side=LEFT)
  def write_slogan(self):
    print "Tkinter is easy to use!"

root = Tk()
app = App(root)
root.mainloop()

Довідка: http://www.python-course.eu/tkinter_buttons.php

Впорядкування програми за допомогою класу полегшує вам та іншим, хто працює з вами, налагоджувати проблеми та вдосконалювати додаток легко.

Ви можете легко організувати свою заявку так:

class hello(Tk):
    def __init__(self):
        super(hello, self).__init__()
        self.btn = Button(text = "Click me", command=close)
        self.btn.pack()
    def close():
        self.destroy()

app = hello()
app.mainloop()

Напевно, найкращий спосіб навчитися структурувати свою програму - читаючи код інших людей, особливо якщо це велика програма, до якої внесли свій внесок багато людей. Переглянувши код багатьох проектів, ви повинні отримати уявлення про те, яким повинен бути стиль консенсусу.

Python, як мова, особливий тим, що є кілька чітких рекомендацій щодо того, як слід форматувати свій код. Перший - так званий "Дзен Пітона":

• Красиве краще, ніж потворне.
• Явне краще, ніж неявне.
• Простий - краще, ніж складний.
• Комплекс краще, ніж складний.
• Квартира краще, ніж вкладена.
• Розріджений краще, ніж щільний.
• Читання рахується.
• Особливі випадки недостатньо спеціальні для порушення правил.
• Хоча практичність перемагає чистоту.
• Помилки ніколи не повинні проходити мовчки.
• Якщо явно мовчати.
• В умовах неоднозначності відмовтеся від спокуси здогадатися.
• Повинно бути один - і бажано лише один - очевидний спосіб це зробити.
• Хоча цей спосіб може бути спочатку не очевидним, якщо ви не голландці.
• Зараз краще, ніж ніколи.
• Хоча ніколи часто краще , ніж прямо в даний час.
• Якщо реалізацію важко пояснити, це погана ідея.
• Якщо реалізацію легко пояснити, це може бути хорошою ідеєю.
• Простори імен - це чудова ідея - давайте зробимо більше таких!

На більш практичному рівні існує PEP8 , посібник зі стилів для Python.

Маючи на увазі, я б сказав, що ваш стиль коду не дуже відповідає, особливо вкладеним функціям. Знайдіть спосіб вирівняти їх, використовуючи класи або переміщуючи їх в окремі модулі. Це полегшить розуміння структури вашої програми.

Я особисто не використовую заперечений орієнтований підхід, здебільшого тому, що він а) лише заважає; б) ти ніколи не будеш використовуєте це як модуль.

але щось, про що тут не йдеться, - це те, що потрібно використовувати нитку чи багатообробку. Завжди. інакше ваша заявка буде жахливою.

просто зробіть простий тест: запустіть вікно, а потім отримайте якусь URL-адресу чи щось інше. зміни - ваш інтерфейс користувача не буде оновлюватися, поки відбувається запит мережі. Значить, вікно вашої програми буде порушено. залежать від ОС, на якій ви перебуваєте, але в більшості випадків вона не перемальовується, все, що ви перетягнете через вікно, буде замазано на ній, поки процес не повернеться до основної версії TK.