I’m looking to build an app with Python (tkinter, ttkinter and ttkbbotstrap)
I’m trying to find out the best way to do it. The app will have a main window that will display data.
At first run, i want to do some kind of install windows that will receive information from the user and will set some things for the app to work.
The setup windows as for now are written in separate Python files. Each setup window will have ‘Next’, ‘Previous’, and ‘Cancel’ buttons so i can go back and forth in the setup.
The setup will run only once on the first run.
Now… what will be the best way to accomplish this? Be advised that i need to pass some of the info from one window (python file) to another.
What exactly is “this” - what part of the problem is causing a problem? For example, are you trying to figure out how to make it only show the setup windows the first time? Are you trying to figure out how to save information from the setup to use next time? Are you trying to figure out how to make the setup “windows” (I think you really want to use the same window and just display different content in it for each step of setup) appear properly in sequence? Are you trying to figure out how to make the main program show up after the setup is done?
Or just what is the point of confusion?
Files aren’t “things” in the Python program. There are modules, which are created by compiling the source code and importing it. But you can’t pass information into that process of importing. The primary way that you pass information “forward” in a program is to call a function (such as one that you find in a module), and use the parameters of the function definition to receive it, and the arguments of the function call to send it. But GUI programs are more complex than this, because you don’t control the sequence of events - the user does, and your code needs to work around that by implementing “callback” functions that are called e.g. when a button is clicked. Since you don’t control how the function was called in these cases, instead you need to read “state” by looking at the existing GUI elements - like in this example:
Using the same window and just displaying different content in it for each step of the setup is a good idea and i’ll be glad if you can direct me how to do that.
For now, each step of the setup is a Python file, so i thought to run the first file and from it to call the second one and to close the first one, and so on. Some of those files include user interaction (input) and some don’t (just like in an .EXE file of installing an app).
The main idea of this app is to store data in a DB and to display it according to the user queries.
It will have a main window and from it, you’ll be able to open an input data form (window) and submit the data to the DB.
The setup windows will run only the first time in order to get the DB details and to build it. From there and on, only the main window will be used with the data form i mentioned before.
My strong recommendation is to study the fundamentals of writing a command-line program first, especially the parts about splitting code across files. Making a GUI adds extra complexity that will only confuse you at this point.
“Database” can mean many things, and the most formal/official meaning describes something that is probably not necessary or useful for your program, given what’s been described so far.
What is your Python-competence/level? Do you have ‘the basics’ under your belt?
There are any number of tkinter tutorials on-the-web. Start by reading a few to find one which seems to make good-sense to you. When it comes to GUIs, it pays to think outside-in - start with the application’s window, create smaller sub-units, and thus get down to the individual fields and widgets.
Similarly, what is your level of experience in using Python with DBs? What is the current schema?
I have the basics and some more. I’m not an expert and i believe that my code needs improvement.
I have already made an app in Python and Tkinter, but it was a ‘One-file’ app.
I thought that if i’ll split my code, especially the GUI\Design windows into several code files, it would be easier to make changes since (as i mentioned before) the setup includes user input and according to the input, the setup will change. @kknechtel - Database in my case means ‘Database’ aka sqlite, MySQL, MongoDB, and even Excel. The setup will change according to the user’s choice of DB since the setup will build the DB. @d_n - my experience with DB’s is Little but i learn as i go It won’t be a complicated one, i need to store contract details.
Not to discourage you, but there are any number of apps ‘out there’, which will initialise and populate a DB. (ie use correct tool for the job)
Assuming you don’t care about that, and are ‘in it’ for the Python experience, the ‘split my code’ idea is a solid technique. Please read-up on import-ing modules into a script (or other modules). The authoritative-work/word is in the (excellent) Python Documentation. However, there are also plenty of tutorials and intro-level coverage to be found.
Again assuming - that you have a schema (see earlier question - unanswered), perhaps ignore the back-end and concentrate on the GUI/data-collection part first.
Later can turn to ‘the rest of it’. Given the level of expertise: recommend working with one back-end as a start, and becoming more ambitious later. Thus, Sqlite if you’ve used that before. However, maintain the idea of ‘modularising’ things, by keeping all the DB-interaction in one module and a minimally-appropriate number of classes/functions (to make it easier to add/substitute other DB-server choices, later) - questions for the future…
To which end, if code a function (for example) save_to_database( ...data-items... ) then can start-off testing/checking the data-collection phase, by using that to print a consolidated-report of the input collected. Later, when build first DB, can replace the printing commands with a SQL-INSERT - and later-still (as above) can add an extra argument to indicate which data-store should be used.
Thus, a path of continuous improvement/prototyping, without excessive amounts of code (and effort) being ‘thrown away’…
I’m doing it for my experience. It’s much more fun to use something that you know you build.
Anyhow, as for your question about the DB schema, i haven’t got there yet. I’m planning to make it as simple as possible.
I have just found out about the ‘Tkinter Toplevel’ which in a way can solve my issue. I don’t know if i can use it with multiple code files but from what i managed to understand until now is that i can have a backend window and as many toplevel windows as i want working simultaneously. I have to read more about it.
Thanks for your help and if you have any more ideas or link to direct me to, i’ll appreciate it