Python becomes the most popular language

[madires]

In network automation there's a new trend to move from Python to Go. The herd is moving on ...

[Picuino]

Hopefully better languages than Python will be developed and become popular. That's the best thing for the users.

In the meantime I'm glad I don't have to learn to do macros, regular expressions and templates with Perl (that was the popular language when I learned Python) and I'm also glad I don't have to struggle with JavaScript other than in some of the frontend of my website. I much prefer working with Python for many reasons for macros and templating.

[RoGeorge]

A good tutorial [for adding a GUI] would start by describing the limitations and differences in the different toolkits, then describe what widgets are, then what difference does code-based versus XML description make.  Then, one could go into layout and display widgets, events/signals, event handling, and sane processing of data related to events (you don't do heavy computation in an event handler, because that causes the UI to freeze; you need to use either an idle handler that only does a bit of work at a time, or better, a separate worker thread that uses a thread-safe queue to talk to the UI thread).  Most of those is the same for Gtk and Qt.

Where/how to start then, any recommended link/book/videolist please?  (for Qt on Linux w KDE)

Last time I've tried (cca 2021) to write python code with a GUI was a fail.  Did try already:

• PAGE - works, but nope, struggling with the editor, seems as buggy as an alpha version, erratic jumps on the screen, copy paste in GUI not working, etc.  IIRC the kit was 10-20 years old, yet buggy on Linux, looked like abandonware.
• tkinter - followed (partially) this 18 hours video https://youtu.be/mop6g-c5HEY has a detailed ToC in the video description
  
  
• REMI - https://github.com/rawpython/remi - seemed in early development stage, small community, not something to gamble it will last for 20 years
  
  
• PySimpleGUI - https://www.pysimplegui.com/ - IIRC text only (tkinter based), no graphic designer for forms
  
  
• DearPyGui - https://github.com/hoffstadt/DearPyGui - don't even recall which one was this (all GUI ways I've tried are mixing together  ;D) - from my notes back then:  overall DearPyGui is nice, but ImGui was rather made for games than for creating programs' GUI
  
  
• Qt/4/5/6 - great visual appearance, has forms designer, but huge.  Was handling everything, audio, video, peripherals, etc.  Got overwhelmed by such a mixture framework, plus confused by the differences between Qt4/5/6.

Might have tried a few other packages I don't remember.  Qt seemed the way to go, for having a forms designer, and for being a mature product with many developers and big community.  It is not exactly FOSS, in fact Qt was the most weird license I've ever heard off:  commercial product, closed development, but the commercial owner loose all ownership if in one year (or 2) they don't open source it, or something like that.  So, closed source for a year + open/free for products older than a year.  Plus no binary downloads without a Qt account, though it is possible to build from sources without a Qt account.  Weird.  But apparently there is no other free option close enough to the old VB5 from 20 years ago.  :-//


Dunno for others, but what bothers me the most is the lack of discoverability.  In VB5/6 all the properties of the graphic objects were listed in the forms designer, in a GUI box that was populating itself with all the attributes once a GUI object was clicked, or dragged into its place.  Easy to see how to make a button invisible, or to change its text/color without digging the docs for the exact text syntax.

When you make a GUI only once or twice a year, you won't remember anything from last time.  I can barely remember how the program was called, or what exactly did I used.  Have a brief text log inside each project, including how to (re)start the SW tools, how to build my own project, etc.  Not only that I forget, but most programs won't even start after a year left untouched.  Other packages will try to update themselves and fail.  It looks like nobody is considering LTS in software development (long term support).

Even worst, there is a trend to make all online, not only the installers, but even the docs are now online.  Except, with time websites changes, companies got acquired and all the pdf links becomes unusable, and so on.  It has to be all offline, from installer, to running, to help and doc pages.

The only way to span a project over many years is to make a virtual machine for each project.  Not kidding.  Want to blink a LED with your devboard?  Make a virtual machine, install all there, isolate the VM from internet, and store the VM in your project folder.  Then keep that VM frozen in time and never update it.  There is no other way, and even this one is fading away fast (i.e. current Arduino 2 IDE only has online help, which is stupid no matter how free it is).  :horse:

Sorry for the rant.  Any hints how to start with Qt please?  (or maybe with something else as a GUI for own python code)

[Nominal Animal]

Where/how to start then, any recommended link/book/videolist please?  (for Qt on Linux w KDE)

I haven't yet seen a good one.

Qt seemed the way to go, for having a forms designer, and for being a mature product with many developers and big community.  It is not exactly FOSS

Bullshit.  KDE desktop is completely based on the Qt toolkit.  Because you are using KDE, you are already using Qt, based on the GPL and LGPL licenses.


Tough love follows.

Start with this:

Install qttools5-dev-tools.  This provides Qt Designer (at /usr/lib/qt5/bin/designer), which you can use to create the user interface.  It's user manual is here.  Do not confuse it with Qt Quick, Qt QML, or Qt Design Studio, which are a completely different thing.  Do not use it to generate code, simply save the user interface as an XML .ui file.  Ignore anything that talks about code and code generation.  Make sure you create each interactive element an unique ID (using only ASCII letters, followed by ASCII letters, digits, or underscore; case sensitive), because that way, we can associate your event handlers with the correct UI objects just by using our own naming scheme and resolver.

If you like that, then install libpyside2-py3-5.15, python3-pyside2.qtcore, python3-pyside2.qtgui, python3-pyside2.qtsvg, python3-pyside2.qtuitools, python3-pyside2.qtxml, python3-pyqt5, python3-pyqt5.qtsvg.  This gives you both PySide2 and PyQt5 bindings for Python3, so that you can test and write your Python3-Qt5 application that selects whichever is installed at run time.
If you used a Gtk+-based desktop instead of KDE, also install qt5-gtk-platformtheme, which helps Qt apps look more like Gtk+ apps on Gtk+-based desktops.

If you don't like that, install glade.  This is the Gtk+ UI designer, the Gtk+ equivalent to Qt Designer.  It's user manual is here.  The same thing applies: ignore anything related to code generation, make sure you give each of your interactive UI elements an unique descriptive ID (using only ASCII letters, followed by ASCII letters, digits, or underscore, case sensitive), and save the UI as an XML .ui file.

If you like that, then install python3-gi, python3-gi-cairo, gir1.2-gtk-3.0, libgtk-3-0, libgtk-3-bin, libgtk-3-common, libgtk-3-dev, libgtk-3-doc (this will provide HTML documentation under /usr/share/gtk-doc/html/gdk3/ you can browse locally).  This gives you Gtk+ Python bindings via GI (gobject introspection, sometimes written as gir).

If you're not happy with either, there is also wxWidgets and wxGlade and wxFormBuilder.  In line with my suggestions above, use XRC for the code generation in wxGlade and wxFormBuilder, to get an XML resource file that can be instantiated at run time.

The steps forward from that point depend on which way you pick.  Gtk+ can also be used from C, if you're more comfortable with C than Python.
Qt requires C++.  One might consider using Lua with wxWidgets, although C++ and Python also work.

When you make a GUI only once or twice a year, you won't remember anything from last time.

Tough.  The same thing applies to every single technical task.  Dumbing down the tools is not a viable solution; it leads to "blunt scissors" tools that are designed to not cut anything, because otherwise those who like to eat glue and stuff crayons up their nose might hurt themselves with them.

What you need to do, is document yourself better.

As an example, whenever I switch to a new Linux distro or desktop environment, I record the list of packages I end up liking, as well as make notes on the changes I make.  (For example, I like to use a variant of the Oblivion Gtk+ theme, except replace the gray backgrounds with true black.)  It is not worth it to try and automate this, because just jotting the details down in a plain text file in a dedicated location, say your home directory, takes less time than any effort in automating this.  It is a habit you have to adopt, if you want to survive without permanent brain damage from constant frustrations.
This way, I do not need to rediscover what I like; I already have the basis I need to continue my day-to-day stuff, within an hour or so if I have to switch computers.  Which is also why I every day consider whether I created anything I would be upset about if lost, and back them up if I did.

It looks like nobody is considering LTS in software development (long term support).

I disagree.  It is true that things change – for the exact same reason why the Linux kernel does not have stable internal APIs: having that would stifle innovation and limit what kind of things could be changed.  That change is a necessity for things to develop at all, because human developers are just not getting paid or their dopamine kicks from maintaining existing code; they need to create something new to benefit.

Python 2/3 and changes in 3.x wrt. Windows support is a bitch; very true.  I don't like that at all.

While Gtk4 and Python6 are "current"/"development"/"head", I personally target Gtk+ 3 and Qt 5, and can install all necessary libraries from standard repos to run my Gtk+2, Gtk 4, Qt 4, and Qt 6 code.  That is, I have zero issues running my years-old code, because I always known this will happen, and prepared for it beforehand.

If you install Gtk3 support, and then run pkg-config --libs gtk+-3.0, it will tell you the libraries C code linked against Gtk+ 3.0 needs: libgtk-3, libgdk-3, libpangocairo-1.0, libpango-1.0, libharfbuzz, libatk-1.0, libcairo-gobject, libcairo, gdk_pixbuf-2.0, libgio-2.0, libgobject-2.0, libglib-2.0, all dynamically (.so).  Alternatively, you can run your native program via strace -e openat -o logfile program [args...] to log all files it accesses.  Using your package manager, you can find their owner packages, and list the package names required to run the application.  Some of these will pull in additional packages, of course.

To distribute software in native Linux packages, you need to package them as .deb/.rpm/etc., and thus record their dependencies.  This is done using the package names.  This is crucial, so that installing an application will automatically ensure its dependencies are present.  This has to be done by the developer, so if you intend to ever distribute anything you created yourself in a native package, you have to learn to track the package dependencies.  Fortunately, it isn't hard, it is just something you have to spend the time to learn.
(If you also have a snapshot of a VM of a pristine install of the distributions and desktop environments you target, it is very easy and fast to verify the dependencies are sufficient.  Verifying they are correct, i.e. even if someone removes packages included in the default installs, is a bit more complicated; your snapshot must be a minimal install then, and you'll also end up testing the dependencies of the entire package tree up to your own package, which will be slow.  Unless you use a local SSD as the repository, in which case it is not that slow.  And you generally only need to do that once, or when you add a dependency on a new library or other.  For basic Python3 + Gtk/Qt applications, none of that is necessary; it's easy to just list the few root packages as dependencies.  Mine above includes SVG support, but excludes multimedia, webkit (browser), and OpenGL widget support.)

A shortcut to distributing software is using Snap, Flatpack, etc. application images.  Essentially, all the required libraries (and the services those libraries depend on) are provided with the application image.

An intermediate version of those is what I suggest for the cases when one wishes to distribute proprietary software.  The software is installed system-wide, but for each user, a configuration directory (under their home directory) is used, populated with symlinks to the actual libraries the binaries will be using.  This covers e.g. LGPL library update requirements, as long as the mechanism is described to the users and actually works.  This includes the exact interpreter used, with the system-wide application "binary", say /usr/bin/your-proprietary-app, is actually a shell script that ensures the configuration symlink directory exists for the current user (perhaps populating it if necessary), and executes the user-specific interpreter via the symlink, with dynamic library resolution order (LD_LIBRARY_PATH and so on; see man ld.so).  For many-many-users environments, if there is no user-specific directory, a global default directory can be used instead, to reduce disk space use.  (Although symlinks don't take up much disk space at all.)

The only way to span a project over many years is to make a virtual machine for each project.

It is the easiest way, yes, but definitely not the only way.  I personally don't need to do that, and can run stuff I wrote a decade ago right now without modifications –– might need to install a couple of libraries in some cases, but I tend to have those requirements listed, or they are obvious (as in Gtk+-2.0, or Qt 4 with PyQt4 bindings).

Even my embedded C code tends to be impervious to compiler version changes, because of my practical approach towards the standard and language implementation.  The Python 2 vs 3 did bite me slightly (mostly just str vs bytes), but not enough to bother me too much.

There is no other way, and even this one is fading away fast (i.e. current Arduino 2 IDE only has online help, which is stupid no matter how free it is).

It may apply to Arduino and the proprietary world, but I definitely don't see that in the Linux distributions I use.  Applications and projects –– including LibreOffice –– that use browser-based help files store them in /usr/share/doc/package/ just like they always have.  (The only annoying thing is that if they use UTF-8, they need to explicitly state that with <meta charset="utf-8"> or <meta http-equiv="Content-Type" content="text/html; charset=utf-8">, because although all text files on my system are UTF-8, I cannot set my browser default character set to UTF-8, because someone decided only legacy character sets can be the default character set and the only non-legacy character set is UTF-8. )

My Arduino IDE is still 1.8.19, as that works fine with Teensyduino 1.59.

[brucehoult]

The only way to span a project over many years is to make a virtual machine for each project.

It is the easiest way, yes, but definitely not the only way.  I personally don't need to do that, and can run stuff I wrote a decade ago right now without modifications –– might need to install a couple of libraries in some cases, but I tend to have those requirements listed, or they are obvious (as in Gtk+-2.0, or Qt 4 with PyQt4 bindings).

Virtual Machine disk images are pretty heavy-weight.

Docker is a pretty interesting way to manage this.

You can create a docker container for each project, and it uses disk space only for the actual files of that project -- which might be only a few KB or MB.

Docker containers are read/write. They are a layer (and the only writable layer) over the top of N immutable layers of other stuff. The immutable layers are called "images".

You can run multiple containers from one image. They each use just the delta of disk space. You can at any time save a snapshot of a container as a new image (again, just using that delta of disk space) and then launch any number of independent new containers using it.

As an example, I have an image riscv64/ubuntu which I got from the internet. It uses 61.6 MB of disk space (the x86 Ubuntu for some reason uses only 56.4 MB, I don't know why).

I have my own image, called "rvdev" which is riscv64/ubuntu with gcc, emacs and other stuff I use in most or all projects added to it (using apt install). It's about 3 GB.

Then I have a container for each project.

For example, I just ran a new container based on "rvdev"  (docker run -it rvdev bash), edited hello.c, compiled it with gcc, and run it, and exited from the container.

The container size is 9.36 KB.  I can run that at any time. I can "commit" it to an image, which also uses 9.36 KB.  If I'm truly paranoid I can export it to a tar file, which has everything from all images it depends on, and is therefore 3.1 GB.

There are alternatives which do much the same thing e.g. podman.

[DiTBho]

I have a container for each project.

I do the same 

[Picuino]

Another tool I use in Python are virtual environments, which allow you to keep different packages installed for a particular application isolated.

[PlainName]

You can create a docker container for each project, and it uses disk space only for the actual files of that project -- which might be only a few KB or MB.

How is that different from having a base VM and then your project VMs being linked clones of that? Only the differences are stored in the clones, so pretty much just the actual project files. AFAIK, both VMWare and VirtualBox allow linked clones.

[RoGeorge]

Start with this:

Install qttools5-dev-tools.  This provides Qt Designer (at /usr/lib/qt5/bin/designer), which you can use to create the user interface.  It's user manual is here.  Do not confuse it with Qt Quick, Qt QML, or Qt Design Studio, which are a completely different thing.  Do not use it to generate code, simply save the user interface as an XML .ui file.  Ignore anything that talks about code and code generation.  Make sure you create each interactive element an unique ID (using only ASCII letters, followed by ASCII letters, digits, or underscore; case sensitive), because that way, we can associate your event handlers with the correct UI objects just by using our own naming scheme and resolver.

If you like that, then install libpyside2-py3-5.15, python3-pyside2.qtcore, python3-pyside2.qtgui, python3-pyside2.qtsvg, python3-pyside2.qtuitools, python3-pyside2.qtxml, python3-pyqt5, python3-pyqt5.qtsvg.  This gives you both PySide2 and PyQt5 bindings for Python3, so that you can test and write your Python3-Qt5 application that selects whichever is installed at run time.

That was very helpful, thank you.  Installed, and Qt5 designer is the one I like the most! 

Apart from those packages, I've installed 2 more suggested by the sudo apt install <whatever>, some 'whatwever-doc' packages, which I assume it's the offline documentation.  Have space on disk, so installed them too, in total:
qttools5-dev-tools, qt5-doc   <---   this one suggested by qttools5-dev-tools was funny, it dragged in a ton of extra packages, about +100MB extra  ,
libpyside2-py3-5.15, python3-pyside2.qtcore, python-pyside2-doc, python3-pyside2.qtgui, python3-pyside2.qtsvg, python3-pyside2.qtuitools, python3-pyside2.qtxml, python3-pyqt5, python3-pyqt5.qtsvg, all of them installed with sudo apt install <package name> from the Ubuntu repositories.

Didn't took yet the tour/read of the QT 5 Designer manual you linked to, only opened the designer and made a very simple designer_try_1.ui form (attached).  My understanding so far is that we use the 'designer' only as a graphic editor, good to drag in place buttons and other GUI elements.  The rest (attach code to GUI events and such) is to be done from python.

Since I do not know the architecture of a GUI system (and how python/tk/qt interacts between them), and since all components have either py or qt in their name, to me it's a total confusion.  For example, I understand that I've just installed 2 components:  pyqt5 and pyside2.  Do these two need each other in order to have a working GUI in python, or are they 2 distinct possibilities from which to choose one?

Anyway, having the install and the attached .ui file, what's the next step please?

[ve7xen]

You can create a docker container for each project, and it uses disk space only for the actual files of that project -- which might be only a few KB or MB.

How is that different from having a base VM and then your project VMs being linked clones of that? Only the differences are stored in the clones, so pretty much just the actual project files. AFAIK, both VMWare and VirtualBox allow linked clones.

As far as storage, the container uses the host OS, so even the base image will be much smaller than a VM image as it will basically just include the Python interpreter and standard library, for example. You also have a storage advantage in that you aren't tracking access time for every file in the image, temporary storage, caches and whatever other random stuff gets written as you use it. The container image is something you build with the application, and isn't writable at runtime. Writable storage in the container is either ephemeral or something you specifically define as persistent.

The main advantage of containers though is that they run in the host OS, so it is much easier to integrate them with a local workflow. Startup time is on the order of milliseconds not minutes, you can easily access local files without messy network mounting etc., a command can be passed into the container at startup. With minimal setup you can basically treat container commands the same as local commands. You can also build your images on top of 'reference' images maintained by someone else. For example if you are targeting Python 3.10, you can use the python:3.10 image tag published by the Python team, and you'll track the latest point release whenever you rebuild.

Mostly though, containers are just much nicer to use. They integrate much easier with the host system, so it's feasible to run a 'convenience' script inside a container, against files on your local machine. For example maintaining KiBot and all its dependencies is a nightmare, so I use their published container to run it against my projects locally. They're also much more conducive to reproducibility elsewhere. Container images are well defined, and as long as they're built for the architecture they're running on, should 'just work'. VM images require the correct hypervisor, correct hardware profile etc.

[Nominal Animal]

My understanding so far is that we use the 'designer' only as a graphic editor, good to drag in place buttons and other GUI elements.

Yes.

For example, I understand that I've just installed 2 components:  pyqt5 and pyside2.  Do these two need each other in order to have a working GUI in python, or are they 2 distinct possibilities from which to choose one?

They are two distinct possibilities.  They arise from history: Qt did not provide Python bindings prior to Qt 5, but RiverBankComputing provided them as the PyQt4 package.  For Qt5, there are now two separate possibilities: PyQt5 and PySide2.  Either one can be used, and they are almost identical.  PyQt5 is GPL, PySide2 is LGPL.

Anyway, having the install and the attached .ui file, what's the next step please?

You create a minimal skeleton in Python for the ui.

You created a dialog, which closes as soon as either button is pressed.  As it is, there is not much coding to add in Python, because after the dialog has closed.
Assuming you name the UI file rogeorge.ui, the corresponding rogeorge.py might be

Code: [Select]

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# SPDX-License-Identifier: CC0-1.0
import sys

try:
    # Prefer PyQt5,
    from PyQt5 import QtCore, QtGui, QtWidgets
    from PyQt5.uic import loadUi
except ImportError as err:
    # but fall back on PySide2.
    from PySide2 import QtCore, QtGui, QtWidgets, QtUiTools
    def loadUi(uifile):
        return QtUiTools.QUiLoader().load(uifile)

class RoGeorge(object):

    def __init__(self):
        super().__init__()

        self.ui = loadUi("rogeorge.ui")
        for slot in dir(self):
            if slot.startswith("on_") and slot.find("_", 3) > 3:
                method = getattr(self, slot)
                widgetName, signalName = slot[3:].rsplit("_", 1)
                source = self.ui.findChild(QtCore.QObject, widgetName)
                signal = getattr(source, signalName, None)
                if signal:
                    signal.connect(lambda *args, **kwargs: method(source, *args, **kwargs))

        self.show = self.ui.show

    def on_radioButton_3_USB_clicked(self, widget, clicked):
        print("clicked on %s" % widget.objectName())

if __name__ == '__main__':
    app = QtWidgets.QApplication(sys.argv)
    win = RoGeorge()
    win.show()
    status = app.exec_()

    if win.ui.result() == QtWidgets.QDialog.Accepted:
        if win.ui.findChild(QtWidgets.QRadioButton, "radioButton_1_LAN").isChecked():
            print("LAN: %s" % win.ui.findChild(QtWidgets.QLineEdit, "lineEdit_IP").text())
        elif win.ui.findChild(QtWidgets.QRadioButton, "radioButton_2_COM").isChecked():
            print("COM: %s" % win.ui.findChild(QtWidgets.QLineEdit, "lineEdit_IP_2").text())
        elif win.ui.findChild(QtWidgets.QRadioButton, "radioButton_3_USB").isChecked():
            print("USB: %s" % win.ui.findChild(QtWidgets.QLineEdit, "lineEdit_IP_3").text())
        else:
            print("None selected")
    else:
        print("Canceled")

    del win
    del app
    sys.exit(status)
For an example of the event handling, I created the on_radioButton_3_USB_clicked() handler.  Note that I use a lambda function, essentially a closure, to provide the handler both the context to the RoGeorge object (self), as well as the object that generated the signal (widget), followed by any additional parameters provided by the signal like checked boolean for clicked() signal.  It just makes things easier.

The above works.  I recommend you run it from a terminal, so you can see the 'clicked on' message as well as the result status when the window is closed or either button pressed.

If you resize the window, you'll see that everything stays in place, even though the window size changes.  Similarly, even if you change your font size, the locations of the QLabels and QLineEdits stay fixed: not what you want.  What you should do, is use a QFormLayout, then drop the QLabels and QLineEdits into its cells, and not define any sizes or locations in pixels.  You can control how the window stretches (based on content/font size, and when resized), and how added space is allocated to the different elements.

(Those old Visual Basic UIs only worked because they used a fixed font and font size.  That is no longer true, and placing UI elements just based on what they look like on your machine no longer cuts it, except for the cruddiest of throwaway single-use programs.)

Next, design a proper QMainWindow main window, and start exploring on what kind of signals (events) you can handle, and how.
Since they don't have the .result() method, you can then remove the entire if win.ui.result() block.

If we changed the RoGeorge class to be a subclass of QtWidgets.QMainWindow, we could use it as the base instance, and simplify things quite a bit.  If you create a QMainWindow .ui file, I can show how the Python code changes.  The main change is that instead of widgets hanging off self.ui, they'll hang off self, which makes things much nicer.  I like to call such a class simply MainWindow.  (In the Qt Designer, you'll still use QMainWindow, because MainWindow will be a derivative, and thus compatible).  It can also make sense to create a dict/tuple-based mapping between widget IDs and handlers, especially when you have many widgets with the same handler, instead of copy-pasting them en masse.  Another way to handle that is to create your own widget derivatives.

You may wish to look at the plain text XML .ui file, too.  It is not a complex file format at all.

[brucehoult]

They're [containers] also much more conducive to reproducibility elsewhere. Container images are well defined. VM images require the correct hypervisor, correct hardware profile etc.

Container images depend on the rather stable Linux syscall interface.

> and as long as they're built for the architecture they're running on, should 'just work'

docker uses the binfmt_misc facility to run non-native images. So, actually, you can run any ISA of images on any other ISA, at reduced performance.

When you install the "Docket Desktop" rather than just the base Docker Engine, it includes QEMU and automatically sets up binfmt_misc.

I regularly run my RISC-V docker images on my x86 laptop or M1 Mac Mini for development. Other than speed it's just transparent. The laptop, in particular, has 24 cores and 32 GB RAM while my largest RISC-V board at present [1] has only four cores and 16 GB.

[1] the 64 core, 128 GB, Milk-V Pioneer has bee shipping for a couple of months, but I don't have one.

[PlainName]

The main advantage of containers though is that they run in the host OS, so it is much easier to integrate them with a local workflow. Startup time is on the order of milliseconds not minutes, you can easily access local files without messy network mounting etc., a command can be passed into the container at startup.

OK, thanks. I can see that would be very useful to be using the normal tools and stuff. But it is dependent on the host OS. Let's say you upgrade to W10 then W11, then give up and move to a Mac before deciding Linux is he place to be... is your container going to survive that? The VM will regardless of what host it's sitting on, which I understood to be the problem RoGeorge mentioned some way up this thread.

[ve7xen]

OK, thanks. I can see that would be very useful to be using the normal tools and stuff. But it is dependent on the host OS. Let's say you upgrade to W10 then W11, then give up and move to a Mac before deciding Linux is he place to be... is your container going to survive that? The VM will regardless of what host it's sitting on, which I understood to be the problem RoGeorge mentioned some way up this thread.

There's no implicit abstraction between the container and the kernel; syscalls reach the kernel directly. So a container made to run on Linux (the vast majority of them) requires Linux syscalls be available at runtime. If you're using Docker as your container engine, it'll take care of running a Linux VM for this purpose transparently if you want to use macOS or Windows.

[Nominal Animal]

Services and command-line programs can trivially be run using only specific libraries provided with the binary, ignoring everything already on the system.  The simplest way to do this is to compile your program statically against a standard C library that does not rely on dynamically loaded modules (for e.g. resolver).

The problems arise when you wish the independent binary to interface with different services, like desktop environments and audio libraries.
Docker provides these interfaces in a standardized format.  It also uses Linux kernel features like cgroups to isolate what such processes can see of the host system.  "Container" is a very accurate description for this.

The intermediate model I've described, with symlinks to either system or application-provided dynamic libraries in an user-controlled directory, is not "containerized" at all.  It is just a way to control library versioning and dependencies in a straightforward manner in Linux.
The most common term for this is shims.

Python virtual environments (pyenv, Python venv) consist of environment variables and a shim directory for related executables inserted in PATH before standard command directories, so that for affected commands, the symlinks (or wrapper scripts) are used instead of the executables in standard directories.

Virtual machines are simply "containers" at the kernel level, limiting what hardware a kernel can access and when.

The most useful feature for myself for desktop virtual machines is snapshotting: creating a point in time, containing everything in the virtual machine at that point, that I can return to and continue as if forking a new timeline from that point.  An excellent example is creating a snapshot before installing a new application.  If I decide it was a wrong move, or it caused problems, I can simply erase that timeline completely by returning to the earlier snapshot.
When one creates installable software packages, having such a VM snapshot of the base install for testing makes it trivial to check if you have your package dependencies right.  If they are, the dependencies will drag in any missing libraries and services required, and everything will work.

[coppice]

Python seems to have become the new Basic - the build free language people use for their quick and dirty experiments. 3 times in the last year I wanted to interface to something, looked around for existing open source code to help get me started, and found implementations only in Python. In each case it looked like the author had used python expressly to allow quick experimentation as they reverse engineered an undocumented or poorly documented interface. Now, you can take the knowledge they gathered, and reimplement the interface in another language, or just live with the python code. I guess most people will just use the existing python code, and write more Python. Things can achieve a lot of viral growth along paths like this.

[Picuino]

That this is true does not mean that Python is like BASIC. The old BASIC was a language very given to spaghetti programming and quite unmaintainable. Python is much more maintainable and facilitates programming oriented to make simple to maintain programs.

Of course bad programmers program badly in any language.

[coppice]

That this is true does not mean that Python is like BASIC. The old BASIC was a language very given to spaghetti programming and quite unmaintainable. Python is much more maintainable and facilitates programming oriented to make simple to maintain programs.

Of course bad programmers program badly in any language.

Oooh, a zealot who can't resist stating the obvious. 

[Picuino]

Oooh, a zealot who can't resist stating the obvious. 

It's not that obvious. It will be obvious to you who know Python well, but that doesn't mean it is obvious to everyone else.

Many people who don't know the difference will think, from what you've written, that Python is a language whose zen is to write fast and badly. And nothing could be further from the truth: https://peps.python.org/pep-0020/

Just because Python attracts flies doesn't mean that's what it was designed for. When I learned Python, some 20 years ago, there was hardly anyone attracted to the language. It was other languages that attracted bad programmers.

If that's the price to pay for popularity, maybe I'm not so sure I like Python being popular.
I do like that it is popular because it has certain advantages as you said, even if it has disadvantages.

[coppice]

Oooh, a zealot who can't resist stating the obvious. 

It's not that obvious. It will be obvious to you who know Python well, but that doesn't mean it is obvious to everyone else.

Many people who don't know the difference will think, from what you've written, that Python is a language whose zen is to write fast and badly. And nothing could be further from the truth: https://peps.python.org/pep-0020/

Just because Python attracts flies doesn't mean that's what it was designed for. When I learned Python, some 20 years ago, there was hardly anyone attracted to the language. It was other languages that attracted bad programmers.

If that's the price to pay for popularity, maybe I'm not so sure I like Python being popular.
I do like that it is popular because it has certain advantages as you said, even if it has disadvantages.

I said nothing negative about Python. That's projection on your part. I do think a lot of the impulse to use it stems from it having the immediacy of BASIC without being utter garbage for writing anything longer than a few lines, as BASIC is.

[Picuino]

No, you didn't say anything bad about Python, you just said it to me (with a wink).
What you said about Python, which is true and I don't deny it, is only a part of the reality. Now the popularity and simplicity of Python attracts bad programmers and generates bad programs.

For my part I just wanted to emphasise that, being true, Python promotes much more good code writing than similar languages like Ruby or others like JavaScript. It has been in its Zen since 2004.

It may be obvious to you, but you haven't told us and it's important to know.

[Picuino]

I quite like AWK. That was the tool/language I used to make macros before I knew Python. It is very expressive and you can easily make fast programs even on a single line. But when it comes to making more complex programs, programming becomes slower and cumbersome. That's not to mention the large number of tools that Python has built in and AWK no.
In the end for me it is easier to create a program in Python, even if it takes me more lines, than to do the same in AWK.
I am not a professional programmer, I use macros from time to time, but I am not programming all day long. So deciding whether AWK or Python is better for a task makes no sense to me. I now do all scripting tasks with Python and it takes less overall effort.
This is not to say that I don't recognize the many advantages of AWK. It's just that, in my case, it's not worthwhile to maintain competition in the two tools.

[RoGeorge]

Code: [Select]

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
# SPDX-License-Identifier: CC0-1.0
import sys

try:
    # Prefer PyQt5,
    from PyQt5 import QtCore, QtGui, QtWidgets
    from PyQt5.uic import loadUi
except ImportError as err:
    # but fall back on PySide2.
    from PySide2 import QtCore, QtGui, QtWidgets, QtUiTools
    def loadUi(uifile):
        return QtUiTools.QUiLoader().load(uifile)

class RoGeorge(object):

    def __init__(self):
        super().__init__()

        self.ui = loadUi("rogeorge.ui")
        for slot in dir(self):
            if slot.startswith("on_") and slot.find("_", 3) > 3:
                method = getattr(self, slot)
                widgetName, signalName = slot[3:].rsplit("_", 1)
                source = self.ui.findChild(QtCore.QObject, widgetName)
                signal = getattr(source, signalName, None)
                if signal:
                    signal.connect(lambda *args, **kwargs: method(source, *args, **kwargs))

        self.show = self.ui.show

    def on_radioButton_3_USB_clicked(self, widget, clicked):
        print("clicked on %s" % widget.objectName())

if __name__ == '__main__':
    app = QtWidgets.QApplication(sys.argv)
    win = RoGeorge()
    win.show()
    status = app.exec_()

    if win.ui.result() == QtWidgets.QDialog.Accepted:
        if win.ui.findChild(QtWidgets.QRadioButton, "radioButton_1_LAN").isChecked():
            print("LAN: %s" % win.ui.findChild(QtWidgets.QLineEdit, "lineEdit_IP").text())
        elif win.ui.findChild(QtWidgets.QRadioButton, "radioButton_2_COM").isChecked():
            print("COM: %s" % win.ui.findChild(QtWidgets.QLineEdit, "lineEdit_IP_2").text())
        elif win.ui.findChild(QtWidgets.QRadioButton, "radioButton_3_USB").isChecked():
            print("USB: %s" % win.ui.findChild(QtWidgets.QLineEdit, "lineEdit_IP_3").text())
        else:
            print("None selected")
    else:
        print("Canceled")

    del win
    del app
    sys.exit(status)


It works, thanks! 
After replacing the filename, of course.  Was the change of the filename a suggestion to use single word naming as a better practice (instead of long names made from a few words and underscores), or it is just happen to be how you saved the .ui file?

Asking about the names because I've notice in some books (long ago, it was Fortran or Cobol, don't recall), example of names that were back then very confusing for me.  For example, a variable named variable, or an example of a text variable text = 'text', which was totally confusing while learning about variables for the first time.

Another strange naming I see sometimes in code example is foo and bar.  Bad choice.  They look and sound similar, easy to mix later in the code which was which.  Not to say when same words foo and bar are used both in the main code and as arguments when defining a function or a class.  Then some smarty decides to use uses foo, bar, foobar and barfoo, all in the same example.    Why not A B C D, or something else hard to confuse.

But foo/bar bambuzling is peanuts.  Just wait to hear the encryption guys, explaining with Alice and Bob. 
Worst choice ever.  I never read/watch explanations with Alice and Bob, because they never specify if Alice and Bob are together.  That detail alone will entirely change the dynamic of private keys exchanging, isn't that so? 


Back to GUI in Python, I've started to think what the main window should look like.  Trying to figure out what controls to keep in the main window, if the comm setings should be as a pop-up or as a tab or maybe all in a single form, I've open a spreadsheet to draft the location of each GUI element.

Then I've realized I could just use a spreadsheet (LibreOffice Calc) as a GUI.   

Calc is always installed on my Desktop, and it's probably the ideal tool for small experiments and draft calculations and in the lab.  Even charts are significantly easier to use/design than in Octave or Matplotlib.  My main need of a GUI is to control some instruments, or to talk with a microcontroller over a serial port, things like that.  I don't really need them to have a nice standalone program.

Unfortunately the default scripting language for spreadsheets is Basic (or VBA in MSOffice), but OpenOffice/LibreOffice (I don't use MS any more) can run Python scripts instead of Basic macros, and can assign Python functions to button events and such, just as if it were Basic functions (tried APSO - Alternative Script Organizer for Python, a LibreOffice Extension, can embed Python scripts into the .ods file itself just as if Python code were Basic macro).  Some extensions can even edit both Python and Basic sources inside the Office macro editor.  ALT+F12 from any office document, and start using the IDE meant for Basic. 


There is another possibility of remotely making use of the Libre/OpenOffice GUI, by using the UNO (Unified Network Objects) protocol over LAN.  UNO looks really complicated, but there are already some Python wrappers that makes UNO calls easy to make from Python (I've tried pyoo).  Can open a spreadsheet and write in it under your eyes like it were haunted, very funny to watch. 

Code: [Select]

#!/usr/bin/env python3

# before running the .py start an office instance that is listening on a UNO interface, either manually or from python
#
#   soffice --accept="socket,host=localhost,port=2002;urp;" --norestore --nologo --nodefault # --headless


import pyoo
import subprocess
import time

#subprocess.Popen(["python.exe", "second.py"], creationflags=subprocess.CREATE_NEW_CONSOLE)  # this will wait for the subprocess to finish

# subprocess.Popen(['soffice --accept="socket,host=localhost,port=2002;urp;" --norestore --nologo --nodefault'], creationflags=subprocess.CREATE_NEW_CONSOLE)  # windows only without waiting to finish

subprocess.Popen('soffice --accept="socket,host=localhost,port=2002;urp;" --norestore --nologo --nodefault', shell=True)
# time.sleep(0.5) # wait 0.5 seconds for soffice to start

desktop = pyoo.Desktop('localhost', 2002)
# pyoo.Desktop(pipe='hello') # <- not working ?

doc = desktop.create_spreadsheet()   # new untitled spreadsheet document
# doc = desktop.open_spreadsheet("./os_made_calc.ods")   # opens existing ods

sheet = doc.sheets[0]   # access sheets by index
sheet = doc.sheets['Sheet1']   # access sheets by name
doc.sheets.copy('Sheet1', 'Copied Sheet', 2)   # copy a sheet

# del doc.sheets[1]   # deletes a sheet by index
del doc.sheets['Copied sheet']   # deletes a sheet by name

adr_text = str(sheet[0,0].address)   # get cell [row, col] address ($A$1)
adr_text = str(sheet[0,1].address)   # get cell [row, col] address ($B$1)

sheet[0,0].value = 1   # set cell value
sheet[1,0].value = 2   # set cell value
sheet[3,0].formula = '=$A$1+$A$2'   # set cell formula

print(f'The value calculated by the spreadsheet is %i', sheet[3,0].value)


#########################
# Tabular (two dimensional) cell range:
sheet[1:3,0:2].values = [[3, 4], [5, 6]]

# Row (one dimensional) cell range:
sheet[3, 0:2].formulas = ['=$A$1+$A$2+$A$3', '=$B$1+$B$2+$B$3']
print('sheet[3, 0:2].values ', sheet[3, 0:2].values)


# Column (one dimensional) cell range:
sheet[1:4,2].formulas = ['=$A$2+$B$2', '=$A$3+$B3', '=$A$4+$B$4']
print('sheet[1:4,2].values ', sheet[1:4,2].values)


# Get cell range with all data
cells = sheet[:4,:3]

# Font and text properties:
cells.font_size = 20
cells[3, :].font_weight = pyoo.FONT_WEIGHT_BOLD
cells[:, 2].text_align = pyoo.TEXT_ALIGN_LEFT
cells[-1,-1].underline = pyoo.UNDERLINE_DOUBLE

# Colors:
cells[:3,:2].text_color = 0xFF0000                 # 0xRRGGBB
cells[:-1,:-1].background_color = 0x0000FF         # 0xRRGGBB

# Borders
cells[:,:].border_width = 100
cells[:,:].border_color = 0xFFFF00
cells[-4:-1,-3:-1].inner_border_width = 50

# Number format can be also set but it is locale dependent:
locale = doc.get_locale('en', 'us')
sheet.number_format = locale.format(pyoo.FORMAT_PERCENT_INT)

# Charts
chart = sheet.charts.create('My Chart', sheet[5:10, 0:5], sheet[:4,:3])

# Existing charts can be accessed either by an index or a name:
print('sheet.charts[0].name ', sheet.charts[0].name)
print('sheet.charts["My Chart"].name ', sheet.charts['My Chart'].name)

# Chart instances are generally only a container for diagrams which specify how are data rendered. Diagram can be replaced by another type while chart stays same.
print ('chart.diagram.__class__ ', chart.diagram.__class__)
diagram = chart.change_type(pyoo.LineDiagram)
print ('diagram.__class__ ', diagram.__class__)

# Diagram instance can be used for accessing and setting of miscellanous properties.

# Set axis label
diagram.y_axis.title = "Primary axis"

# Axis can use a logarithmic scale
diagram.y_axis.logarithmic = True

# Secondary axis can be shown.
diagram.secondary_y_axis.visible = True

# All axes have same attributes.
diagram.secondary_y_axis.title = "Secondary axis"

# Change color of one of series (lines, bars,...)
diagram.series[0].fill_color = 0x000000

# And bind it to secondary axis
diagram.series[0].axis = pyoo.AXIS_SECONDARY

# wait
print()
aaa=input('press ENTER to close...')

# Saving documents
doc.save('example.xlsx', pyoo.FILTER_EXCEL_2007)
# doc.save()

# And finally do not forget to close the document:
doc.close()


Mentioning Libre/OpenOffice as a GUI for Python because it was very fast to do the GUI with it (about 10 times faster for me).  Aside from productivity, a spreadsheet has already very well polished tools and features (for example data validation with a helping message and error treating, conditional formatting, text colors and sizes, charts, etc.).  Everything in a spreadsheet GUI is trivial to change, when compared with Qt designer.

A spreadsheet doesn't look as good as a Qt GUI, but for my use case that doesn't matter.  I don't write and distribute programs, only need python with a GUI to control things around the lab, talking about hobby level experiments and such.


Will continue with Qt, too, and do an average size program side by side, in Qt+Python and in LibreOffice+Python.  Want to see which one is easier for something more than just a hello world.  At this moment, taking advantage of the Office GUI seems a ton easier for my use case.

[SiliconWizard]

For my part I just wanted to emphasise that, being true, Python promotes much more good code writing than similar languages like Ruby or others like JavaScript.

With what kind of evidence can you back this up? Because that sounds like bullshit to me. So show us your evidence.
Had you said "than the BASIC of the 70s & 80s", sure, there would be no question.
But Ruby or JS? Are you serious?

[Nominal Animal]

Was the change of the filename a suggestion to use single word naming as a better practice (instead of long names made from a few words and underscores), or it is just happen to be how you saved the .ui file?

More about how I saved the .ui file.

If I had thought about it longer, I probably would have named it something like connectionmethod.ui.

Asking about the names because I've notice in some books (long ago, it was Fortran or Cobol, don't recall), example of names that were back then very confusing for me.  For example, a variable named variable, or an example of a text variable text = 'text', which was totally confusing while learning about variables for the first time.

Yes.  This is also true of the interactive widget ID's, because for maintainability, you'll want your on_widgetname_signal() to be descriptive and intuitive.

In particular, the way you used names, lineEdit_1 and similar, is counterproductive.  Something like LAN, LANSelected, Serial, SerialSelected, USB, USBSelected would lead to much more maintainable and intuitive code.

At the core, my advice is to name things according to their use and relevance, meaning, not their type.  (This means I seriously recommend against all variants of Hungarian notation.)
The way I do this is think about what name would be most illustrative/intuitive for someone looking at the code/UI for the first time, trying to solve a bug or issue in it.

Also note that for .findChild(), the object type does not need to be the exact target object type, it can be any ancestor type, up to QObject.  Instead of QtWidgets.QRadioButton, Qtwidgets.QAbstractButton would have been better, because it is the ancestor of all button types that provide a .isChecked() method.  QtWidgets.QLineEdit does not have a similar ancestor, it is a direct derivative of QtWidgets.QWidget, so that's fine.

Another strange naming I see sometimes in code example is foo and bar.  Bad choice.

Technically speaking, foo, bar, baz and so on are metasyntactic variables: not to be used as variables per se, but used as variable name placeholders to describe the syntax.

Single-letter names are applicable for variables of known meaning.  Consider e.g. Cartesian coordinates x, y, z; barycentric coordinates u, v, w; indexes i, j, k, m, n; and so on.

Alice and Bob arise from early cryptographic articles, where they described the two main communicating parties; nowadays there are many more names used for specific types of parties.  They are a similar convention as using x, y, z for Cartesian coordinates, or r and ϕ (or θ or φ) for polar coordinates; just using human names.


For simple dialogs, you can use Zenity (Gtk+) or KDialog from simple shell scripts.  The exit status will correspond to Ok/Cancel/Window closed, and any selections will be printed to standard output so you can safely capture it.

For desktop notifications (timed popups informing of e.g. network connection loss), use notify-send (from libnotify-bin package).  It uses DBus for the underlying mechanism, and should work in all desktop environments in Linux.

For the example case, I would create a simple single text entry dialog with a scheme prefix and help text, i.e.
    ip:192.168.1.1
    tty:/dev/ttyUSB1
    usb:/dev/usb/001/001
If you use Bash and response="$(zenity ...)" then
    scheme="${response%%:*}"
    value="${response#*:}"
will split the scheme and the value into separate Bash variables.  This way your Bash script can easily accept the same as a command-line parameter for those use cases where the scheme and value are already known at script execution time without prompting the user.