I've been looking for ways to make a GUI with a .py file, and have so far only found frameworks and modules like Tkinter. However, my ultimate goal is for this code to run on a lot of computers that don't necessarily have these modules installed. The machines are only guaranteed to have Python on them. Does anyone know a way to make a GUI under these restrictions?
The best way to do this would be to ship your application with those modules as a part of it; the user's computer doesn't need to have the GUI framework installed if you provide it.
What you're asking would essentially require you to write an entire GUI framework, which would give a result that would be similar or worse - with a LOT more work.
Related
I recently stumbled upon an SO question that pointed at using WinRT (discontinued in Python 3.10), that helps handle Windows Runtime APIs. I wanted to use it to develop a basic desktop overlay that shows a list of currently running audio sources (primarily, Spotify). I did accomplish everything else, concering the UI and such, using tkinter.
The main problem is that the support for Python WinRT discontinued for the 3.10 version, (and onwards), and I can not find libraries that might substitute it. The main solutions I find include downgrading to Python 3.9 (or, using a venv, which sounds better), or just using a community fork (PyWinrt), but I'm not really putting these hacks or workarounds at a priority, I might be willing to opt for these if there is no other possible solution.
Is it still possible to develop such an overlay using only Python? Since I'm using Tkinter, all i would need is an image of the current playing track, the application that is running it, progress in the audio (in ms or s), and the name of the track. Keeping it simple, I'm trying to avoid audio control, such as skipping the track, or changing the relative timestamp.
I did try using the Spotify WebAPI to specifically grab info related to the track currently playing, but the work involved with refresh oauth tokens, and creating logins for just looking at the track seems a bit much work, since I believe it would be easier done natively; plus, what I'm trying to aim for, is a general purpose audio source info, rather than just Spotify.
Here, is a picture of Windows' Gamebar, that shows what I'm trying to achieve:
GamebarOverlay.
Recently I've been developing Python code as a freelancer. I've mostly worked on social media bots, my usual way of delivering the code is as a Python script for people to run on their compilers. However, I've started to run into people that lack the technical knowledge of installing modules and running the code that way. How do I create a package like software and deliver it in a way that can be ready-to-run and users don't have to download anything extra? Thank you in advance for your feedback.
Check out py2exe. It is a wrapper that converts your script into an executable, so the user can run it without needing to install any python libraries.
Alternatives to py2exe are:
PyInstaller - the advantage of using this is that it lets you build executables in formats other than exe, if you want to make your program run on non-Windows platforms, for example.
cx_Freeze - this is also another cross-platform alternative.
One method would be (as stated in the previous answer) is to use exe converters, but that wouldn't be as effective if you target Mac and Linux users as well.
My solution is going to take you a little more time, but it will be worth it. Here goes:
Please learn Angular JS, or some other framework (I prefer Angular). Once you know that, you can easily develop a web app for your project, and add your Python to that.
The good news is, there are lots of tutorials for this, such as https://codehandbook.org/creating-a-web-app-using-angularjs-python-mongodb/ (also teaches you mongodb) Anyways, you can find other tutorials on your own.
You could of course, I guess, build it into a mobile app, but I think web app would be easier.
I have written a program. I don't know if it is important how it is written but you can find it here: http://pastebin.com/Z3ZvVPV8 Basically, it asks you to assign values to variables and will perform calculations depending on what variables you chose, and prints the answer.
I would like to know how I can make the program run in a window other than cmd (I am using Windows Vista 32bit). I don't need much at all in terms of GUI, just a window that is a bit more user friendly/easier to look at when they are using the program.
EDIT: To those suggesting using IDLE, while that would work for me, if others want to use the program they would have to download it, so I was hoping for a way for that not to happen.
Python comes with a sort of default GUI package TkInter you can use it.
Also there is a lot of other GUI packages available.
The Python standard library offers a lot of ways to implemt simple (but also rather complex) GUIs. I'd like to point you at the documentation of TK (tool kit for graphical interfaces) http://docs.python.org/library/tk.html where you will find also some useful example of use.
Py2Exe is a viable option if you really don't need a gui. This will make it run and look like a command prompt, but it will be an .exe file. Here is a quick quote from thier page: "py2exe is a Python Distutils extension which converts Python scripts into executable Windows programs, able to run without requiring a Python installation."
Another alternative is to get Portable Python. Here is a quote from thier webpage: "Portable Python is a Python® programming language preconfigured to run directly from any USB storage device, enabling you to have, at any time, a portable programming environment. Just download it, extract to your portable storage device or hard drive and in 10 minutes you are ready to create your next Python® application." After packaging the portable python and your .py or .pyc file then create a .bat file that runs the portable python "Python-Portable.exe" with the correct command line parameters for loading your script. Be sure to use relative paths in the batch file in case they are running it from a flash drive, or something other than the same location as you.
NOTE: This is really not a good way to do this as thier download page states: "Installed size: based on selected packages, between 49MB and 480MB". Also be sure to read the the current Python Software Foundation License, as that is what Portable Python is released under, and it may or may not be legal to package it in a closed source project. I haven't really looked at the license myself to be able to tell you. If you are releasing it as open source, then there would not be an issue though. As a quick side note, if you need that .bat file to be a .exe file then you can use a .bat to .exe converter battoexe.com is one. This is really going the long way about doing the whole thing, but it is an option.
Sources:
Working with Python on and off for 7 years now, a lot that using a portable version on a flash drive, and also dealing with Batch files much longer.
I'm planning to take a non-GUI Linux distro (no Gnome, KDE, etc) and build my own front-end GUI for it. While I have a few years of Python programming experience, I have never attempted to do something quite like this.
To be more specific about my project, I'm building a CarPC and I have everything pretty much worked out so far, except the front-end. Most pre-existing front-ends for CarPCs run on Windows and the ones that run on Linux are hard to find (they either quit development or only run on specific hardware). My front-end will always be full-screen and I do not want to run a desktop environment unless I absolutely have to; it would just slow down the boot time and provide unnecessary features.
My question is basically where I should start. What Python graphics libraries are out there that would allow me to build a front-end GUI without a desktop environment?
You'll probably want to look at other answers and questions on this topic such as this one
Another good link is this one on the Python websitewhich lists different GUI toolkits.
While I haven't used it, Kivy looks like a good place to start. It's apparently got touch screen capabilities which I assume you would use and it doesn't look constrained to a GUI desktop env.
Hopefully you can find a way to do this without a desktop env. If not perhaps consider using X11 as your layer and go from there.
You should probably consider DirectFB. You can even use a DE on it if you like (although not required).
WxPython is awesome. I use it with Python and plain WxWidgets in C++ too. I've had great luck with making native GUIs from it and internationalization is supported too. Good luck!
Edit: I missed the "without a desktop environment bit". I'm not sure my answer is relevant. You should edit the Title of the question. Just disregard.
I'm under the impressions that Python runs in the Triforce smoothly. A program that runs in Windows will run in Linux. Is this sentiment correct?
Having said that, if I create my application in QT For Windows, will it run flawlessly in Linux/Mac as well?
Thanks.
Yes. No. Maybe. See also: Java and "write once, run anywhere".
Filesystem layout, external utilities, anything you might do with things like dock icons, character encoding behaviors, these and more are areas you might run into some trouble.
Using Qt and Python, and strenuously avoiding anything that seems tied to Windows-specific libraries or behaviors whenever possible will make running the application on Mac and Linux much easier, but for any non-trivial application, the first time someone tries it, it will blow up in their face.
But through careful choice of frameworks and libraries, making the application work cross-platform will be much more like bug fixing than traditional "porting".
As other posters mentioned, the key issue is making sure you never touch a different non-Qt non-cross-platform API. Or really even a different non-Qt crossplatform API, if you use Qt you kind of need to commit to it, it's a comprehensive framework and for the most part sticking with Qt is easier than going to anything else. There's some nice advantages as the basic primitives in your program will work the same way all over the place. (i.e. a QString in your networking code will be the same as a QString in your interface code.) Portability-wise, if you stay within the API Qt provides you, it should work on multiple platforms.
There will be areas where you may need to call some Qt functions which provide specific cross-platform tweaks more important to some platforms than others (e.g. dock icons) and you won't immediately have a polished application on all three platforms. But in general, you should remain very close to an application that compiles and runs on all three. (Try to use qmake or a similar build system too, as the build process for Qt applications varies depending on the platform. Different flags, etc.)
There's some odd issues that come up when you mix Qt with other APIs like OpenGL, in particular the way windows locks GL contexts differs from the way OS X and Linux does, so if you intend to use OpenGL with multiple threads, try to periodically compile on the other platforms to make sure nothing is completely busted. This will also quickly point out areas where you might have inadvertently used a non-cross-platform system API.
I've used Qt with a team to build a multi-threaded 3-d multiplayer real-time networked game (read: non-trivial application that fully utilized many many areas of Qt) and we were nothing but blown away by the effectiveness of Qt's ability to support multiple platforms. (We developed on OS X while targeting Windows and I regularly made sure it still ran on Linux as well.) We encountered only a few platform specific bugs, almost all of which arose from the use of non-Qt APIs such as OpenGL. (Which should really tell you something, that OpenGL was more of a struggle to use cross platform than Qt was.)
At the end of the experience we were pleased at how little time we needed to spend dealing with platform-specific bugs. It was surprising how well we could make a GUI app for windows given almost none of the team actually used it as a primary development platform through the project.
But do test early and often. I don't think your approach of writing an entire application and then testing is a good idea. It's possible with Qt, but unlikely if you don't have experience writing portable code and/or are new to Qt.
Yes. The code that you write using Qt will work on Windows, Mac, Linux/X11, embedded Linux, Windows CE and Symbian without any change.
You can take a look here.
Generally - as long as you don't use code that is not covered by Qt classes - yes.
I have several time just recompiled applications I wrote in Linux(64bit) under Windows, and the other way arround. It works for me every time.
Depends on your needs, you might also find compiler problems, but I am sure you will know how to work around them. Other people mentioned some issues you should look for, just read the other posts in the question.
It might run well, but it will take some testing, and of course Qt only handles the GUI portability, not the myriad of other things that might cause portability problems.
Qt apps generally don't fit in very well on MacOS because they don't have Applescript support by default and don't necessarily have the right keybindings. But if you do the work to fix those issues, they work, but not nicely. On the Mac, it's far better to build a native UI. If this is an in-house app, Qt is probably OK, but if it's for sale, you won't make many sales and will create yourself some support hassles.
As the others said, everything which is done using Qt-Functionality will most likely run quite flawlessly, WHEN you dont use platform specific functionality of qt.
There isnt that much (most of it has to do with window-manager stuff) , but some things might not work on other systems.
But such things are surely mentiond in the documentation of Qt.
Still there are things which cant be done using Qt, so you will have to do that yourself using plain Python...
Yeah "Python" itself is platform-independent (well it should), but there are lots of other things involved ... well mainly the OS.
And how the OS reacts you will plainly have to findout yourself by testing the application on all target OS.
Recently i wrote an quite simple GUI-application, while it ran flawlessy on Windows, it didnt run on Linux, because on Linux Python interpreted files encoded in unicode differently than on Windows.
Additionally a small script which should return the hostname of the machine, which it did on Windows, only returned "localhost" on Linux, which was obviously not what i wanted.