前言
我们已经知道利用QtDesigner来设计界面,并通过Pycharm外部工具PyUIC将其转化成py源文件。不过由于要响应事件操作,往往会将相应的槽函数写在ui的py文件中,这样,界面和逻辑开发就混合在一起了,每一次的ui更新都会伴随着转换后py文件的槽函数的添加修改,及其不方便,造成效率低下。本例就来介绍如何将二者剥离。
实例讲解
设计ui
我们通过Pycharm新建一个项目,并打开QtDesigner做一个简答的界面mainwindow.ui,在其上添加两个Button对应ID为World和China,一个label对应ID为Title,一个Line Edit对应的ID为lineEdit
ui转换成py
在Pycharm中项目文件中选择mainwindow.ui右键选择外部工具–PyUIC,生成py源文件ui_mainwindow.py
剥离ui和逻辑
在项目中新建文件mainwindow.py,创建类MainWindow类
from PyQt5 import QtCore, QtGui, QtWidgets from ui_mainwindow import Ui_MainWindow class MainWindow(QtWidgets.QMainWindow, Ui_MainWindow): def __init__(self, parent=None): super(MainWindow, self).__init__(parent) self.setupUi(self) self.Title.setText("hello Python") self.World.clicked.connect(self.onWorldClicked) self.China.clicked.connect(self.onChinaClicked) self.lineEdit.textChanged.connect(self.onlineEditTextChanged) def onWorldClicked(self, remark): print(remark) self.Title.setText("Hello World") def onChinaClicked(self): self.Title.setText("Hello China") def onlineEditTextChanged(self,p_str): self.Title.setText(p_str)
在这里去绑定相应的signal和slot,实现业务逻辑,这样代码结构也清晰多了,以后如果再遇到ui更新,我们只需将更新的ui文件替换并生成行的ui_***.py,这样就实现了ui和逻辑的分离。
main函数中调用
在项目中新建主函数main.py,在其上实例化类MainWindow,并调用show方法显示
from PyQt5 import QtCore, QtGui, QtWidgets from mainwindow import MainWindow import sys if __name__ == "__main__": app = QtWidgets.QApplication(sys.argv) mainWindow = MainWindow() mainWindow.show() sys.exit(app.exec_())
到此这篇关于PyQt5 如何让界面和逻辑分离的方法的文章就介绍到这了,更多相关PyQt5 界面和逻辑分离内容请搜索小牛知识库以前的文章或继续浏览下面的相关文章希望大家以后多多支持小牛知识库!
问题内容: 我正在Django中编写一个项目,我发现文件中有80%的代码。这段代码令人困惑,并且在一段时间之后,我不再了解实际发生的事情。 这是困扰我的事情: 我发现模型级别(应该只负责处理数据库中的数据)在发送电子邮件,使用API到其他服务等方面也很丑陋。 另外,我发现在视图中放置业务逻辑也是不可接受的,因为这样很难控制。例如,在我的应用程序中,至少有三种方法来创建的新实例,但从技术上讲,它
null 我的数据库的实体,持久性级别:我的应用程序保留哪些数据? 我的应用程序的实体,业务逻辑级别:我的应用程序做什么? 在Django有哪些实施这种办法的良好做法?
问题内容: 我对node.js相当陌生,并且发现随着项目规模的扩大,将一个项目分成多个文件非常复杂。我之前有一个大文件,可以同时用作多人HTML5游戏的文件服务器和Socket.IO服务器。理想情况下,我想将文件服务器,socket.IO逻辑(从网络读取信息并将其写入带有时间戳的缓冲区,然后将其发送给所有其他播放器)和游戏逻辑分开。 使用socket.io中的第一个示例来演示我的问题,通常有两个文
对于任何一个有意义的应用来说,将所有的更新逻辑都放入到单个 reducer 函数中都将会让程序变得不可维护。虽然说对于一个函数应该有多长没有准确的规定,但一般来讲,函数应该比较短,并且只做一件特定的事。因此,把很长的,同时负责很多事的代码拆分成容易理解的小片段是一个很好的编程方式。 因为 Redux reducer 也仅仅是一个函数,上面的概念也适用。你可以将 reducer 中的一些逻辑拆分出去
我的目标是理解接口隔离原则,同时实现多态性。 我的预期结果是:我可以用接口分离原理实现多态。 我的实际结果是:不,我不能。我被迫创建样板并使用Liskov替换原则(如果有一个Worker,必须有一个Worker不能吃,所以为Worker创建一个可以吃的扩展Worker的接口)。我想我误解了接口隔离原则。 这是违反接口隔离原则的代码。 我被告知将接口分成两部分。 解决方法是使用Liskov替换原理。