Author Topic: GUI for Python?  (Read 16571 times)

0 Members and 4 Guests are viewing this topic.

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2539
  • Country: 00
Re: GUI for Python?
« Reply #25 on: June 10, 2022, 08:04:06 am »
1. Qt and its "Qt Designer" - (that was some time ago, IIRC the wrapper module was called PyQt), thought I remember it as very cumbersome, hard to learn and also Qt is not entirely free, certainly not FOSS

Qt is entirely and certainly FOSS. Pick your license: GPL or LGPL at your choice.

The fact that they also offer a commercial license doesn't make Qt "less FOSS".

If you say that software that's opensource and released under the GPL and/or LGPL isn't FOSS,
then many software will not be FOSS like for example the GTK toolkit.
 
The following users thanked this post: RoGeorge

Offline RoGeorgeTopic starter

  • Super Contributor
  • ***
  • Posts: 8450
  • Country: ro
Re: GUI for Python?
« Reply #26 on: June 10, 2022, 08:39:02 am »
Built some large things in wxpython. Can recommend.

Thank you, followed your advice and looked at it minutes ago.  Though I won't use wxPython because it is based on wxWidgets, which wxWidgets main webpage https://www.wxwidgets.org displays a banner with political declarations/sides/opinions/whatever.

I don't care and don't want to know who one is with, or against, or how righteous one might be, or not be, I just don't want activism/political endorsed software, no matter who's side it takes, and no matter how much technical merits that software might have.

I'm so full sick of any kind of propaganda.  Writing code is a part of my tinkering hobbies, and I want to enjoy the time spent with a hobby project.  I don't want to be reminded to worry about anything during that particular time frame.  That's the whole point of doing a hobby activity:  getting a refuge from the worries one might have because of the problems existing in the world, or in the own life.  Also, I don't like to be told who's side to take, or to be guilt-tripped for not taking any side, and so on.  Got enough propaganda trauma during Ceausescu's Romania, before 1989, and now (in the last decade) propaganda is at unbearable levels again, just like it was back then, except that now it's coming from other ideologies than back then.  Same shit, different flavors.
« Last Edit: June 10, 2022, 08:43:48 am by RoGeorge »
 
The following users thanked this post: Karel, eugene, GeeBee2020

Offline RoGeorgeTopic starter

  • Super Contributor
  • ***
  • Posts: 8450
  • Country: ro
Re: GUI for Python?
« Reply #27 on: June 10, 2022, 08:52:30 am »
1. Qt and its "Qt Designer" - (that was some time ago, IIRC the wrapper module was called PyQt), thought I remember it as very cumbersome, hard to learn and also Qt is not entirely free, certainly not FOSS

Qt is entirely and certainly FOSS. Pick your license: GPL or LGPL at your choice.

My misunderstanding, sorry, and thanks for taking the time to explain.  Corrected my post with a text strike through.

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2539
  • Country: 00
Re: GUI for Python?
« Reply #28 on: June 10, 2022, 09:49:53 am »
I don't care and don't want to know who one is with, or against, or how righteous one might be, or not be, I just don't want activism/political endorsed software, no matter who's side it takes, and no matter how much technical merits that software might have.

I'm so full sick of any kind of propaganda.  Writing code is a part of my tinkering hobbies, and I want to enjoy the time spent with a hobby project.  I don't want to be reminded to worry about anything during that particular time frame.  That's the whole point of doing a hobby activity:  getting a refuge from the worries one might have because of the problems existing in the world, or in the own life.  Also, I don't like to be told who's side to take, or to be guilt-tripped for not taking any side, and so on.  Got enough propaganda trauma during Ceausescu's Romania, before 1989, and now (in the last decade) propaganda is at unbearable levels again, just like it was back then, except that now it's coming from other ideologies than back then.  Same shit, different flavors.

I couldn't agree more.
 
The following users thanked this post: Ed.Kloonk

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23102
  • Country: gb
Re: GUI for Python?
« Reply #29 on: June 10, 2022, 09:58:34 am »
Everyone has political, religious, social ideologies which are probably incompatible with yours. It doesn't mean we don't have to be in the same room as them. It's best to be objective and focused on the problem you are solving otherwise you will just end up walking round in circles trying to find people who agree with you and being disappointed.

I would suggest we keep this focused on technical merit.
 
The following users thanked this post: newbrain, GeeBee2020

Offline RoGeorgeTopic starter

  • Super Contributor
  • ***
  • Posts: 8450
  • Country: ro
Re: GUI for Python?
« Reply #30 on: June 10, 2022, 01:35:22 pm »
There is this big list of GUI software for Python.   :-+
https://wiki.python.org/moin/GuiProgramming

Adding it here just for the docs, and because it didn't pop in the previous searches.
 
The following users thanked this post: bd139

Offline mag_therm

  • Frequent Contributor
  • **
  • Posts: 783
  • Country: us
Re: GUI for Python?
« Reply #31 on: June 10, 2022, 02:34:56 pm »
As with RoGeorge, I am hobby linux user.
I have a license for Xojo but it is too cumbersome for a simple GUI.

There is a very basic editor called Gtkdialog that is maybe one step up from Zenity and Glade.
This is different from the more popular one using C, with a similar name.

Gtkdialog allows a persistent window populated with multi controls and tabs and can run as a parent for underlying bash or python scripts etc.
It is a bash script with a multiline command written in xml, that defines the window and controls.
A limitation is that (as far as I know) there is no way that an external process can update a field until a control action on the GUI.
Comms to and from the controls can be done by  files, as I use it.

With all its limitations (included sparse documentation) I was able to get a job done in short time with no problems
I put up a screenshots recently on the ham forum, here again:
https://app.box.com/s/v24an4ea1iiib9jvcpyeh49j9wx0518i  showing the simple layout, across and down in order of the xml lines
https://app.box.com/s/tf7936ph90rf4vljgbo427sevbtn6i85  showing how to get back data from a button press.

The best description I found so far:
https://pclosmag.com/html/Issues/201408/page07.html
 
The following users thanked this post: RoGeorge

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: GUI for Python?
« Reply #32 on: June 10, 2022, 03:01:03 pm »
There is this big list of GUI software for Python.   :-+
https://wiki.python.org/moin/GuiProgramming

Adding it here just for the docs, and because it didn't pop in the previous searches.


not really .... it is not like that... 

They are several implementations of the same thing...  most of them are wrappers over the same toolkit  GTK.. Qt ... Wx... and even Python itself...   that just mean that you will have problems to have a sane single wrapped ...

reason being...:
- unreliable newbie shit over others...
- same thing several times instead of a single framework well maintained..
- very fast obsolete versions leading to disaster next corner..

.. you consider a TOOLKIT?

First thing on the list is - WELL MAINTAINED
A wrapper?   it must be over a solid toolkit  done by clever skilled people w/long term sight.

Python reached a vast legion of newbies.. 
this result is very problematic

you should avoid these over and over wrappers...

Paul
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23102
  • Country: gb
Re: GUI for Python?
« Reply #33 on: June 10, 2022, 03:03:10 pm »
Ah PKTKS to fulfil those requirements it sounds like you're promoting something well maintained, stable and no wrapping at all. May I recommend win32 and c++ :-DD
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: GUI for Python?
« Reply #34 on: June 10, 2022, 03:06:25 pm »
Not at all..


Surprisingly  as I pointed above...  FPC as of today holds the most broad well maintained and supported UNITS  (they are really native API calls UNITS not just  wrappers)  over the main toolkits

GTK  Qt  Wx  Postgres MySQL sqlite.. and dozen others..  like TurboVision

There is no duplicated efforts  ..
no traceback shit

Definitively  not newbie work ...

Just confirm for yourself..

Paul
 
The following users thanked this post: MK14

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23102
  • Country: gb
Re: GUI for Python?
« Reply #35 on: June 10, 2022, 03:12:32 pm »
I've written a fair bit of Pascal over the years. Just no.
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: GUI for Python?
« Reply #36 on: June 10, 2022, 03:21:00 pm »
I've written a fair bit of Pascal over the years. Just no.

I was introduced to PASCAL on  an Burroughs mainframe. Later on IBM mainframe...

Then over 90s/00s there was a shift to more "FAST/RAD" tools...

Nevertheless never really could spare PASCAL..

Recently over the last decade.. the progress of Object Oriented PASCAL made me gradually turn over and over to the fast stable and good finish of the whole thing...

I am using it today on regular base...  My BENCH inventory now is SQLite TurboVision  based..
and other tools keep being very well ported..  easier than C++

Paul
 
The following users thanked this post: MK14

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 17777
  • Country: fr
Re: GUI for Python?
« Reply #37 on: June 10, 2022, 05:51:46 pm »
Modern Object Pascal is pretty good. You may have myriads of reasons for not using it (the ecosystem, too few potential developers available, very few compilers, not standardized AFAIK, you already have a large code base in other languages and want to reuse it, etc), but if you're a lone developer or a small team for which those points are not a problem, go for it.

 
The following users thanked this post: MK14

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: GUI for Python?
« Reply #38 on: June 10, 2022, 06:01:05 pm »
Modern Object Pascal is pretty good. You may have myriads of reasons for not using it (the ecosystem, too few potential developers available, very few compilers, not standardized AFAIK, you already have a large code base in other languages and want to reuse it, etc), but if you're a lone developer or a small team for which those points are not a problem, go for it.


... and it has been just like this...   since late 70s on the Burroughs...
early 80s... IBM..

Pretty steady and predictable...  ^-^

Paul
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 5385
  • Country: gb
Re: GUI for Python?
« Reply #39 on: June 10, 2022, 06:11:13 pm »
TurboVision  based..

Do you really mean TurboVision, or are you actually talking about Free Vision ?

https://en.wikipedia.org/wiki/Turbo_Vision

https://wiki.freepascal.org/Free_Vision

Free Vision seems to be the FreePascal (IDE) version.
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: GUI for Python?
« Reply #40 on: June 10, 2022, 06:16:31 pm »
TurboVision  based..

Do you really mean TurboVision, or are you actually talking about Free Vision ?

https://en.wikipedia.org/wiki/Turbo_Vision

https://wiki.freepascal.org/Free_Vision

Free Vision seems to be the FreePascal (IDE) version.

That is really FreeVision - which is a more or less direct translation of Turbo Vision.

It is faster and more TERM friendly than TurboVision.

I do have TurboVision as well but the API is C++ based.

FreeVision is a perfect implementation ... a very good work.. all in native PASCAL


BTW thanks for pointing that...

worth mention that although both can run on any term...
FreeVision is more easy to set .. VT100 and XTerm are best supported

RXTERM works pretty well on both

Actually the IDE is all based on FreeVision with integrated debugger...

The FreeVision itself is a 99.999% ported TurboVision PASCAL UNIT

Paul


PS> anyone interested should look for Robert Hohne port of latest Borland TurboVision for UNIX
 latest Borland 2.0 was ported and match tvision-2.2.1 (under Robert Hohne rhide)

Borland made TurboVision for PASCAL available in TurboPascal 7.0
and that implementation seems to be root for FreeVision..  (my opinion based on my use)

Both (C++ Robert Hohne ) and PASCAL (from FPC) work pretty fine


« Last Edit: June 10, 2022, 06:30:40 pm by PKTKS »
 
The following users thanked this post: MK14

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 17777
  • Country: fr
Re: GUI for Python?
« Reply #41 on: June 10, 2022, 06:20:08 pm »
Ah, but FreeVision is text-based UI only, right?
I would call that UI, but not GUI.
But you can definitely design GUIs with FreePascal and Lazarus. It's close-ish to Delphi as far as I could tell, but I haven't touched either in ages so I'm not too sure.
 

Offline PKTKS

  • Super Contributor
  • ***
  • Posts: 1766
  • Country: br
Re: GUI for Python?
« Reply #42 on: June 10, 2022, 06:34:04 pm »
Ah, but FreeVision is text-based UI only, right?
I would call that UI, but not GUI.
But you can definitely design GUIs with FreePascal and Lazarus. It's close-ish to Delphi as far as I could tell, but I haven't touched either in ages so I'm not too sure.

Far more than this...

TurboVision is a whole DESKTOP SOLUTION from Borland...

A TUI  Dekstop  with streaming object capabilities and several other class goods
in short you can even record your TUI to a file..
The whole thing is a marvelous work

Paul

PS. btw it has also object record and streaming (like dialogs.. records... anything)
« Last Edit: June 10, 2022, 06:39:19 pm by PKTKS »
 
The following users thanked this post: MK14

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 8349
  • Country: fi
    • My home page and email address
Re: GUI for Python?
« Reply #43 on: June 11, 2022, 05:24:51 pm »
Qt is entirely and certainly FOSS. Pick your license: GPL or LGPL at your choice.
Anything and everything in Qt that an application developer can use, definitely.  Everything Qt installed in Linux distributions is available under FOSS licenses.

However, there is one or two Qt packages that are not licensed under FOSS licenses, and not available in standard Linux distributions.  The main one is Qt for MCUs, which is only available under a commercial or an evaluation license.



I've talked about this in a different thread, but I'll repeat the core points: One can create proprietary Qt applications based on the LPGL license.  One will not be required to expose their own source code.  Open source applications can use the GPL license, proprietary applications the LGPL license (if they link dynamically to the Qt libraries).  The commercial license gives you commercial support.

Satisfying the Qt developer community, and the Qt company, is easy: be proud of using Qt in your application, link to qt.io for further information, and abide by the license.  If you compile your own distributable Qt binaries, be open about the exact toolchain (including compiler version and library configuration); optimally, you'd provide build scripts that builds them for each target OS and architecture when run in a directory containing the pristine upstream sources.  If you do modify any of the Qt sources, you do need to provide your customers with the modified Qt sources too.

In short: the language at the web pages may seem scary to those used to very friendly FOSS projects, but that's just marketing.  Everything behind that is quite friendly to FOSS developers.  And if you are a developer relying on the LGPL license, they aren't hostile, just indifferent: you neither hurt nor help.  (But, if you do stuff I mentioned above, you actually do help a bit, at least as an example of doing things right as a completely outside party.)



If you say that software that's opensource and released under the GPL and/or LGPL isn't FOSS,
then many software will not be FOSS like for example the GTK toolkit.
The fact proprietary non-FOSS closed-source applications and libraries are explicitly allowed to dynamically link to any LGPL-licensed library/toolkit/framework, can be confusing to those who do not understand the core idea of FOSS:  it is not about zero price, it is about end-user freedom.

Even the dynamic linking requirement is really about end users: they must be able to recompile or create their own variants of those LGPL-licensed libraries, so that they can have the proprietary non-FOSS application run with those modified/different libraries.

This is the reason why so many of the core libraries are LGPL-licensed.  (I do not consider LGPL to be a "compromise" that for example the Wikipedia LGPL article claims, because LGPL fits perfectly well within the free software philosophy: it is about personal, end-user freedom.  After all, it initially wasn't "Lesser GPL", it was "Library GPL".  It's just that it depends on the exact library what license is best suited; not all libraries need to or are best licensed under LGPL.)
 
The following users thanked this post: RoGeorge, eugene, SiliconWizard

Offline RoGeorgeTopic starter

  • Super Contributor
  • ***
  • Posts: 8450
  • Country: ro
Re: GUI for Python?
« Reply #44 on: June 11, 2022, 07:46:47 pm »
No longer than this morning I've tried to install the latest and greatest Qt, which is Qt6, only to realize that there is no Qt6 installer binaries.  Then I've bumped into this blog https://embeddeduse.com/2020/02/02/less-love-for-foss-qt-users/ so it seems the last binary available without a Qt account was Qt5.14, and from that one on, one either has to register on Qt.io, or build from sources.  :-//

Not sure if I properly understood that, but if it is so, then I'll strike out Qt from the candidates.  I understood that I can build from sources without an account, but such a trend still worries me.  Whatever needs an online account is a big no for me, will only use such products only if there is no other option.



Guess I tried too many GUI frameworks in a too shorter time and probably burned out, because now I'm seriously thinking in just scribbling future GUIs on a piece of paper and manually translate the hand drawings to Tkinter code, or maybe to PySimpleGUI (a simplified wrapper over many possible frameworks, including Tkinter, Qt, etc.)  PySimpleGUI has good documentation and many online tutorials. 

For Tkinter there is this standalone WYSIWYG editor called PAGE (should work to generate Tcl/Tk, too), but I've tried it only for Python, and it worked.  A little too basic, from sourceforge, seems straight from the 90s and not very intuitive for these days, but it kind of works.  :)

Meanwhile tried REMI, too.  It finally worked but seems an underpowered project, with almost no documentation.  Has enough examples, though.  Should work on RaspberryPi, too, but didn't try that yet.
« Last Edit: June 11, 2022, 08:02:42 pm by RoGeorge »
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 5385
  • Country: gb
Re: GUI for Python?
« Reply #45 on: June 11, 2022, 08:12:06 pm »
No longer than this morning I've tried to install the latest and greatest Qt, which is Qt6, only to realize that there is no Qt6 installer binaries.  Then I've bumped into this blog https://embeddeduse.com/2020/02/02/less-love-for-foss-qt-users/ so it seems the last binary available without a Qt account was Qt5.14, and from that one on, one either has to register on Qt.io, or build from sources.  :-//

Not sure if I properly understood that, but if it is so, then I'll strike out Qt from the candidates.  I understood that I can build from sources without an account, but such a trend still worries me.  Whatever needs an online account is a big no for me, will only use such products only if there is no other option.





I was tempted to mention it, but now you have, I will as well.

I also recently tried QT.  I had a mini-nightmare of a time trying to install it, because it is so big (like >10 Gig, temporarily needed, just to install itself), and sometimes like 47.5 GB, just to add more stuff to the QT.  It tended to be very fussy about how it was installed, and tended to NOT work out of the box.

I had to make an account on the QT thing (for this supposedly FREE open source software), rather/very annoying.  But if it is included with a version of Linux, you can escape needing a free account.

Eventually, I did get it to install and work, by using openSuse, and pre-selecting it to be installed.  I think the repositories of a particular Linux, would have a working version, as well.

I suspect QT is worthwhile, if a rather big GUI project, or lots of GUIs or professional looking/maintainable GUIs are required.

But for hobby, one-off, quick (until you climb its learning curve), things.  Other choices, such as FreePascal/Lazarus, may make more sense.  But if you're determined to go the Python route, then Pascal maybe isn't for you.
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2539
  • Country: 00
Re: GUI for Python?
« Reply #46 on: June 11, 2022, 08:31:00 pm »
I had to make an account on the QT thing (for this supposedly FREE open source software), rather/very annoying.

Absolutely not. Here you go:

https://ftp1.nluug.nl/languages/qt/official_releases/qt/

And here is a mirrorlist if you prefer another source:

https://download.qt.io/static/mirrorlist/

 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2539
  • Country: 00
Re: GUI for Python?
« Reply #47 on: June 11, 2022, 08:34:27 pm »
However, there is one or two Qt packages that are not licensed under FOSS licenses, and not available in standard Linux distributions.  The main one is Qt for MCUs, which is only available under a commercial or an evaluation license.

This thread is about a GUI for Python. So, I was clearly speaking about the Qt GUI framework which is FOSS.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 5385
  • Country: gb
Re: GUI for Python?
« Reply #48 on: June 11, 2022, 08:37:21 pm »
I had to make an account on the QT thing (for this supposedly FREE open source software), rather/very annoying.

Absolutely not. Here you go:

https://ftp1.nluug.nl/languages/qt/official_releases/qt/

And here is a mirrorlist if you prefer another source:

https://download.qt.io/static/mirrorlist/

Your link says ......

Quote
Due to The Qt Company offering changes, open source offline installers are not available any more since Qt 5.15. Read more about offering changes in the https://www.qt.io/blog/qt-offering-changes-2020 blog.

If you need offline installers, please consider our new Qt for Small Business offering: https://www.qt.io/blog/available-now-qt-for-small-businesses

Here:
https://ftp1.nluug.nl/languages/qt/official_releases/qt/6.3/6.3.0/OFFLINE_README.txt

TL;DR
Maybe just the framework itself, QT.  Can be downloaded.  But if you want their GUI designers, it seems to get harder to obtain, without an account (but can be done, without, with a degree of difficulty).
I'm NOT especially familiar with QT, so there may be better/easier ways of doing it.

Most free/open source software, can be just used.  This QT thing, has left a bad taste in my mouth.  Why it has to be so difficult, it puts me off from being involved with QT.  Technically speaking it is open source, but in practice, the hoops you have to sometimes jump through for it, can be frustrating.
« Last Edit: June 11, 2022, 08:52:33 pm by MK14 »
 

Offline Karel

  • Super Contributor
  • ***
  • Posts: 2539
  • Country: 00
Re: GUI for Python?
« Reply #49 on: June 11, 2022, 09:55:22 pm »
Maybe just the framework itself, QT.  Can be downloaded.

Not "maybe", for sure. But you are right about the installers and probably also Qt Designer and Qt creator (the IDE).
But you don't need them. I write software with grafical interfaces using Qt for 10 years and the only thing I need is the
Qt framework (the libraries), a good editor (Kate) and a compiler (GCC).

On Linux, programming with Qt is easy. When I want to release a windows version, I fire up a virtual machine and recompile
it for windows. No installer, no IDE. I simply download the Qt source and compile the libraries with MinGW-64.
Then I compile my program static. That way I don't need to install a gazillion of dll's when deploying my program
and I don't risk any version conflicts. The result is an executable with everything needed inside it.
 
The following users thanked this post: MK14


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf