Как отделить функции от класса gui в PySide?

Question

В моем PySide проекте у меня есть 3 файла:

• один, который содержит все гуй материал преобразуется в питон из Qt Designer,

• другие, который имеет сигналы, всю логику и функцию и

• еще один, который запускает все приложение.

Я думаю, что лучше отделить логику от функций.

Следующая простая функция вставки элементов в tablewidget:

# my_functions.py 
def fill_table(): 
    for row in range(10): 
     for col in range(10): 
     item_value = "...." 
     item = QtGui.QTableWidgetItem() 
     item.setText(str(item_value)) 
     table_widget.setItem(row, col, item) 

Моя главная проблема заключается в том, как вы бы ссылаться на виджет из вашего приложения в отдельном модуле.

Answer 1

Предполагая, что my_functions.py является вторым элементом в вашем списке файлов, похоже, что функция заполнения использует модуль-глобальный table_widget. Я не рекомендую этого, но если это действительно то, чего вы хотите, просто получите доступ к нему. Так с

# my_functions.py 
table_widget = ... # somewhere in that file, not shown in your post 
def fill_table(): 
    ...populate table_widget... 

Тогда:

# main.py 
import my_functions 
... 
... somewhere, use my_functions.table_widget... 

Лучше бы определить пользовательский класс в my_functions.py, экземпляр в main.py, и сделать fill_table() метод на пользовательский класс:

# my_functions.py 
class MyTableWidget(QTableWidget): 
    ... 
    def fill(self): 
     for row in range(10): 
      for col in range(10): 
       item_value = "...." 
       item = QtGui.QTableWidgetItem() 
       item.setText(str(item_value)) 
       self.setItem(row, col, item) 

# main.py 
from my_functions import MyTableWidget 
table = MyTableWidget() 
table.fill() 

Там есть много способов, но в основном кажется, что ваш текущий дизайн является процедурным, а не объектно-ориентированным. В этом нет ничего плохого, но через некоторое время вы столкнетесь с остальными PyQt и Python и не так просты в обслуживании и отладке, как только ваше приложение пройдет этап прототипирования. Поэтому я рекомендую второй подход.

Answer 2

Объекты в типичном приложении Qt соединены вместе в отношениях родителя/ребенка. Чаще всего есть главное окно верхнего уровня, которое функционирует как корневой объект, а все остальные объекты (виджеты, макеты и т. Д.) Расположены в иерархии под ним.

Учитывая это, очень естественно поместить всю связанную с gui программную логику в класс главного окна, потому что все остальные объекты будут доступны через self. Но если вы поместите всю связанную с gui логику в функции в отдельных модулях, то нет self. Поэтому вам будет необходимо предоставить эту недостающую функциональность.

Самый очевидный способ сделать это было бы сохранить ссылку на окно верхнего уровня в модуле, который запускает приложение, так что другие модули могут импортировать:

from app_module import main_window 

# my_functions.py 
def fill_table(): 
    for row in range(10): 
     for col in range(10): 
      item_value = "...." 
      item = QtGui.QTableWidgetItem() 
      item.setText(str(item_value)) 
      main_window.table_widget.setItem(row, col, item) 

В качестве альтернативы, вы может перепроектировать все функции так, что они работают только на один объект (или класс объектов), а затем явно передать экземпляр:

# my_functions.py 
def fill_table(table_widget): 
    ... 

Однако, каким бы образом вы это делаете, это трудно понять, как это может быть «лучшим» способом структурирования кода.

Большинство приложений gui состоят из нескольких довольно крупных подкомпонентов, которые работают независимо друг от друга независимо друг от друга, а также центрального контроллера/менеджера, который организует их все в единую функциональную единицу. Подкомпоненты обычно представляют собой подклассы виджетов (возможно, живущие в отдельных модулях), которые станут дочерними элементами главного окна, которое также может функционировать как контроллер/менеджер. Организация кода в этих строках намного больше соответствует тому, как Qt предназначен для работы, и автоматически избежит большинства потенциальных проблем связи между различными частями приложения.