10/20/2019 Pyqt Program Structure
PyQT Application Structure While we can code a simple window line-by-line without using Object Oriented Programming (OOP), we're going to find it to be quite the challenge to continue to ignore it as we improve the functionality of our application.
Imagine that you want to develop a non-trivial end-user desktop (not web) application in Python. What is the best way to structure the project's folder hierarchy?Desirable features are ease of maintenance, IDE-friendliness, suitability for source control branching/merging, and easy generation of install packages.In particular:. Where do you put the source?. Where do you put application startup scripts?.
Where do you put the IDE project cruft?. Where do you put the unit/acceptance tests?. Where do you put non-Python data such as config files?. Where do you put non-Python sources such as C for pyd/so binary extension modules? Doesn't too much matter. Whatever makes you happy will work.
There aren't a lot of silly rules because Python projects can be simple. /scripts or /bin for that kind of command-line interface stuff. /tests for your tests.
/lib for your C-language libraries. /doc for most documentation. /apidoc for the Epydoc-generated API docs.And the top-level directory can contain README's, Config's and whatnot.The hard choice is whether or not to use a /src tree. Python doesn't have a distinction between /src, /lib, and /bin like Java or C has.Since a top-level /src directory is seen by some as meaningless, your top-level directory can be the top-level architecture of your application.
/foo. /bar. /bazI recommend putting all of this under the 'name-of-my-product' directory.
So, if you're writing an application named quux, the directory that contains all this stuff is named /quux.Another project's PYTHONPATH, then, can include /path/to/quux/foo to reuse the QUUX.foo module.In my case, since I use Komodo Edit, my IDE cuft is a single.KPF file. I actually put that in the top-level /quux directory, and omit adding it to SVN. This is commonly given as an answer in #python on Freenode. Filesystem structure of a Python projectDo:. name the directory something related to your project. For example, if your project is named 'Twisted', name the top-level directory for its source files Twisted.
When you do releases, you should include a version number suffix: Twisted-2.5. create a directory Twisted/bin and put your executables there, if you have any. Don't give them a.py extension, even if they are Python source files. Don't put any code in them except an import of and call to a main function defined somewhere else in your projects. (Slight wrinkle: since on Windows, the interpreter is selected by the file extension, your Windows users actually do want the.py extension. So, when you package for Windows, you may want to add it. Unfortunately there's no easy distutils trick that I know of to automate this process.
Considering that on POSIX the.py extension is a only a wart, whereas on Windows the lack is an actual bug, if your userbase includes Windows users, you may want to opt to just have the.py extension everywhere.). If your project is expressable as a single Python source file, then put it into the directory and name it something related to your project. For example, Twisted/twisted.py. If you need multiple source files, create a package instead ( Twisted/twisted/, with an empty Twisted/twisted/init.py) and place your source files in it. For example, Twisted/twisted/internet.py.
put your unit tests in a sub-package of your package (note - this means that the single Python source file option above was a trick - you always need at least one other file for your unit tests). For example, Twisted/twisted/test/. Of course, make it a package with Twisted/twisted/test/init.py. Place tests in files like Twisted/twisted/test/testinternet.py. add Twisted/README and Twisted/setup.py to explain and install your software, respectively, if you're feeling nice.Don't:.
put your source in a directory called src or lib. This makes it hard to run without installing. put your tests outside of your Python package.
This makes it hard to run the tests against an installed version. create a package that only has a init.py and then put all your code into init.py. Just make a module instead of a package, it's simpler. try to come up with magical hacks to make Python able to import your module or package without having the user add the directory containing it to their import path (either via PYTHONPATH or some other mechanism).
You will not correctly handle all cases and users will get angry at you when your software doesn't work in their environment. Check out.Let me excerpt the project layout part of that excellent article:When setting up a project, the layout (or directory structure) is important to get right.
A sensible layout means that potential contributors don't have to spend forever hunting for a piece of code; file locations are intuitive. Since we're dealing with an existing project, it means you'll probably need to move some stuff around.Let's start at the top. Most projects have a number of top-level files (like setup.py, README.md, requirements.txt, etc).
Try starting the project using the template. It largely follows the best practices (e.g. ), but is better suited in case you find yourself willing to split your project into more than one egg at some point (and believe me, with anything but the simplest projects, you will. One common situation is where you have to use a locally-modified version of someone else's library).Where do you put the source?. For decently large projects it makes sense to split the source into several eggs. Each egg would go as a separate setuptools-layout under PROJECTROOT/src/.Where do you put application startup scripts?. The ideal option is to have application startup script registered as an entrypoint in one of the eggs.Where do you put the IDE project cruft?.
Depends on the IDE. Many of them keep their stuff in PROJECTROOT/. In the root of the project, and this is fine.Where do you put the unit/acceptance tests?. Each egg has a separate set of tests, kept in its PROJECTROOT/src//tests directory. I personally prefer to use py.test to run them.Where do you put non-Python data such as config files?. It depends.
There can be different types of non-Python data. 'Resources', i.e. Data that must be packaged within an egg. This data goes into the corresponding egg directory, somewhere within package namespace. It can be used via pkgresources package. 'Config-files', i.e.
Non-Python files that are to be regarded as external to the project source files, but have to be initialized with some values when application starts running. During development I prefer to keep such files in PROJECTROOT/config. For deployment there can be various options. On Windows one can use%APPDATA%//config, on Linux, /etc/ or /opt//config. Generated files, i.e. Files that may be created or modified by the application during execution.
I would prefer to keep them in PROJECTROOT/var during development, and under /var during Linux deployment. Where do you put non-Python sources such as C for pyd/so binary extension modules?. Into PROJECTROOT/src//nativeDocumentation would typically go into PROJECTROOT/doc or PROJECTROOT/src//doc (this depends on whether you regard some of the eggs to be a separate large projects). Some additional configuration will be in files like PROJECTROOT/buildout.cfg and PROJECTROOT/setup.cfg. I presume you are speaking about 'runtime data' - something people would often put under /var/packagename or /.packagename/var, or whatnot. Most of the time those choices are sufficient as a default that your users don't care to change. If you want to allow this behaviour to be tuned, options are rather abundant and I do not think there is a single fits-all best practice.
Typical choices: a) /.packagename/configfile, b) export MYPACKAGECONFIG=/path/to/configfile c) command-line options or function parameters d) combination of those.–Apr 3 '16 at 21:44. In my experience, it's just a matter of iteration. Put your data and code wherever you think they go.
Chances are, you'll be wrong anyway. But once you get a better idea of exactly how things are going to shape up, you're in a much better position to make these kinds of guesses.As far as extension sources, we have a Code directory under trunk that contains a directory for python and a directory for various other languages. Personally, I'm more inclined to try putting any extension code into its own repository next time around.With that said, I go back to my initial point: don't make too big a deal out of it. Put it somewhere that seems to work for you.
If you find something that doesn't work, it can (and should) be changed. Non-python data is best bundled inside your Python modules using the packagedata support in. One thing I strongly recommend is using namespace packages to create shared namespaces which multiple projects can use - much like the Java convention of putting packages in com.yourcompany.yourproject (and being able to have a shared com.yourcompany.utils namespace).Re branching and merging, if you use a good enough source control system it will handle merges even through renames; is particularly good at this.Contrary to some other answers here, I'm +1 on having a src directory top-level (with doc and test directories alongside). Specific conventions for documentation directory trees will vary depending on what you're using;, for instance, has its own conventions which its quickstart tool supports.Please, please leverage setuptools and pkgresources; this makes it much easier for other projects to rely on specific versions of your code (and for multiple versions to be simultaneously installed with different non-code files, if you're using packagedata).
Is a Python wrapper around the for creating graphical user interfaces, or GUIs.This tutorial is written in PyQt4, but there is a newer version, PyQt5, that you can use. There are some differences, and has ported this series code, by individual tutorial code, to PyQt5.First, we need to go ahead and get PyQT4. To do this, if you are on Windows, head to:.If you are on Mac or Linux, then you should be able to just do: sudo apt-get install python-qt4You can also get a wheel file for pip installation at:you have PyQT, let's create a simple application.First, we'll need some basic imports: import sysWe will use sys shortly just in case we want our application to be able to accept command line arguments, but also later on to ensure a nice, clean, close of the application when we want to exit.Next: from PyQt4 import QtGuiHere, we're importing QtGui, which deals with all things GUI with PyQT. Now some of you may be thinking 'isn't all PyQT GUI stuff?' Nope, PyQT does a lot of other things besides just GUIs, and QtGui is purely just the graphical stuff. All of the PyQT sections are:.
QtGui - Deals with the graphical elements. QtCore - other non-GUI essentials. QtNetwork - Networking, as you may have guessed. QtOpenGL - Allows for the incorporation of OpenGL!. QtSql - Wrapper for SQL handling.
QtSvg - support for support vector graphics. QtXML - for handling XML dataNext, we need some sort of application definition: app = QtGui.QApplication(sys.argv)We are creating a QApplication object, and saving it to 'app.' Here, we pass this sys.argv argument because sys.argv allows us to pass command line arguments to the application. For more information on this, see our. Window = QtGui.QWidgetNext, we define our window. Now this can sometimes be a little confusing. With GUIs, you generally have what is referred to as the 'application,' or the 'frame,' and then you have the 'window' or the actual 'gui' part.
The frame is just the encapsulation of the window, literally on the screen, as well as in the background. You will probably better understand this as time goes on, but think of 'application' as literally the border that goes around your window. Window.setGeometry(0, 0, 500, 300)Here, we can modify the window a bit. Keep in mind, that applications and their windows are created in memory first, then they are brought to the user's screen last. This is the same process that you see done with other forms of Graphics in programming, like games with PyGame, or graphing with Matplotlib.
The reason for this is graphical rendering is cumbersome, and it would be rather inefficient to continuously be making edits and refreshing to the user's screen for each element. So, when we modify the window like this, it is not like the window will pop up full screen, and then change shape moments later. The screen has not yet been shown to the user, we're just building it in the memory.setGeometry is a method that belongs to a few methods, but here the method is the QtGui.QWidget class.
It is taking four parameters from us. First you have the window's starting x coordinate, then you have the starting y coordinate (0 and 0). Next, you have the window's dimensions, which are 500 and 300, meaning 500 pixels wide and 300 tall.Next, we can do something like: window.setWindowTitle('PyQT Tuts!' )This method simply sets the window's title to what we choose.Finally, once we're content with the GUI that we have built, we invoke: window.show.show brings the window to the screen for the user. '.show' is a QT method.Full code for this: import sysfrom PyQt4 import QtGuiapp = QtGui.QApplication(sys.argv)window = QtGui.QWidgetwindow.setGeometry(0, 0, 500, 300)window.setWindowTitle('PyQT Tuts!' )window.showSo now you have a very basic GUI application.
Now that you see the fundamentals of how a GUI with QT works, we're going to talk about how to lay the foundation for a full application next.The next tutorial.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |