GUI with gauges in python

[Zero999]

Yes then I need a licence or at least whoever I write the code for does

Can't you confine the Qt/GUI code to one module/processor and make that open source, leaving the control algorithms proprietary? Would that be acceptable under the free Qt licence and from your employer's perspective? A competitor won't be able to copy your product, just with the code to display the graphics.

[Simon]

All the UI will do is display stuff so it's already a complete product with the GUI stuff plus the comms code.

[Marco]

I don't quite see how they can restrict it like that with LGPL. Google gave me a page which suggest they can not, though there are hoops to jump.

https://www.lenewt.com/en/blog/qt-open-source-embedded-systems/

This is probably why Slint went GPLv3 as their only true open source license, with some proprietary licenses on the side.

[Simon]

So looks like I may have to look at GTK, I don't have a problem paying for software but this is a big ongoing cost that needs guaranteed sales behind it. If they want 5k that is £$E 50 per unit if we sell 100 in a year and that is being optimistic.

[Marco]

Can't run that straight to opengl/vulkan though.

Qt and Slint embedded can.

[JPortici]

It looks like you are intending to make a device with an application embedded into it and dont want to provide the source.
Take a look at the FAQ https://www.qt.io/faq/qt-commercial-licensing

Do I need to have a distribution license to distribute my application with a hardware device?
To provide or distribute a Qt-based application on devices under Qt commercial license, distribution licenses are also required. This means if your device incorporates or integrates parts of the Qt software libraries or if the main functionality of the device depends on Qt’s products regardless of whether Qt’s products are distributed or not, then you need a distribution license.

Please don't FUD (or don't submit to FUD)
Qt is LGPL, my application is not. So what? 
I'm not modifying Qt, i'm aknowledging Qt, I'm dynamically linking Qt.

From their own terms, in LGPL Obligations: "In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library"

I guess the ambiguity they prey on is in specifying the word "depends". My applications are GUIs to configure my products, they definetly do not depend on Qt for their main function, but they could argue that without Qt i have no GUI to configure my products? Ah, fucking lawyers
(Note that our software is not publicized, and given away for free to select customers, as not many are required to configure our products. (Phone) Apps intended for the general public are *not* built with Qt. If only they had a more permissive license, though, it would be a dream, to use only a single framework... But Qt for Android/iOS has a completely different license, and is still slow to adapt to the requirements and changes that happen every few months from Google/Apple)

[JPortici]

Can't run that straight to opengl/vulkan though.

Qt and Slint embedded can.

usecase for that?
* insert ebussy photo *
i do not want to touch GTK with a ten foot pole

[radiolistener]

Probably? so what can it do that TKinter can't?

ImGui makes sense here — it’s lightweight, hardware-accelerated, and great for dynamic UIs like gauges or live data on SBCs. Tkinter is fine for simple static layouts, but once you need smooth graphics or real-time updates, it becomes quite limiting.

Qt is very powerful for desktop apps, but it’s quite bloated for small SBCs — it pulls in large libraries, may use more memory and CPU, and hardware acceleration support can be limited. ImGui stays lean, lightweight, and very responsive for embedded interfaces, and its code is usually much simpler, easier to read, and easier to customize.

Some examples what it can do:

[Simon]

Please don't FUD (or don't submit to FUD)
Qt is LGPL, my application is not. So what? 
I'm not modifying Qt, i'm aknowledging Qt, I'm dynamically linking Qt.

From their own terms, in LGPL Obligations: "In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library"

I guess the ambiguity they prey on is in specifying the word "depends". My applications are GUIs to configure my products, they definetly do not depend on Qt for their main function, but they could argue that without Qt i have no GUI to configure my products? Ah, fucking lawyers
(Note that our software is not publicized, and given away for free to select customers, as not many are required to configure our products. (Phone) Apps intended for the general public are *not* built with Qt. If only they had a more permissive license, though, it would be a dream, to use only a single framework... But Qt for Android/iOS has a completely different license, and is still slow to adapt to the requirements and changes that happen every few months from Google/Apple)

I seem to remember coming to this conclusion as well which is why I was looking at adopting it. My understanding was that providing my program can run on a machine that has Qt installed without my program containing any code it was fine.

The UI on it's own is useless, if I was to sell a spare?

[radiolistener]

Some more examples of GUI with imgui:

[jfiresto]

... Tkinter is fine for simple static layouts, but once you need smooth graphics or real-time updates, it becomes quite limiting....

The client did not need smooth graphics for the one big tkinter project I worked on, but after I figured out how to hide tkinter's callbacks, real-time-ish updates were no big deal. At times there were half a dozen updates running 100 times a second on a RPi 3. It what ways do you find it becomes quite limiting?

[radiolistener]

The client did not need smooth graphics for the one big tkinter project I worked on, but after I figured out how to hide tkinter's callbacks, real-time-ish updates were no big deal. At times there were half a dozen updates running 100 times a second on a RPi 3. It what ways do you find it becomes quite limiting?

Tkinter can handle moderate update rates if carefully managed. What I meant is that it starts to hit limits once you need complex visuals, many custom widgets, or smooth animated rendering. ImGui immediate-mode design and GPU-backed drawing make that much easier to scale without fighting the framework.

It also allows running the application with different backends — for example, on Linux directly from the text console without a desktop environment, using SDL in KMS/DRM mode with hardware acceleration, or within a graphical session via SDL under Wayland or X11. In addition to SDL, other backends like GLUT, GLFW, SDL3, DirectX, Metal, or Vulkan are also available. All you need to do is include the corresponding backend source file. Can you achieve the same level of portability and real-time performance that easily with your GUI framework?

For example, here’s a GUI with an interactive map showing online radio servers all around the world and a real-time computed solar terminator that I put together in just one evening. The screenshot was taken while running on a Raspberry Pi 4, and the code isn’t even optimized — it just renders everything directly on every frame 75 times per second. It doesn’t use a quad tree or even basic culling checks for rendering optimization — it simply redraws the entire map every frame. The window contains over 65k primitives, rendered 75 times per second on a Raspberry Pi 4 without any noticeable frame rate drop. Would you be able to prototype something similar using Tkinter? 

[SiliconWizard]

ImGui and similar libraries are a pretty good, lightweight option for embedded devices. They sure won't look anything like "native" on desktop OSs, but when designing embedded GUIs, that's usually not the goal.

[Simon]

Yes, the last thing I actually want is something that looks like a computer OS, I do like the look and feel of what radiolistner has posted. Looks modern but without trying to mimic real life which is what lvgl does.

[JPortici]

ImGui and similar libraries are a pretty good, lightweight option for embedded devices. They sure won't look anything like "native" on desktop OSs, but when designing embedded GUIs, that's usually not the goal.

Anything that lets you ovverride its paint event then 
Qt does that. LVGL does that. Some of my software mimics the appereance of the related App even though it's Qt and not react (or other crap web framework bastardized to make pc software and apps)
I'd argue it's even simpler to do that, than in ImGUI (though i have no experience, only briefly touched and it seemed more difficult to me) as for example in Qt if i want to use images to style buttons i just do that in the stylesheet, set the dimensions with the appropriate ratio and the framework does everything from scaling to handling the events and displaying, and me having to write zero code for that

(not telling that you *should* use Qt over ImGUI, just that it is possible if you want)

[jfiresto]

... For example, here’s a GUI with an interactive map showing online radio servers all around the world and a real-time computed solar terminator that I put together in just one evening. The screenshot was taken while running on a Raspberry Pi 4, and the code isn’t even optimized — it just renders everything directly on every frame 75 times per second. It doesn’t use a quad tree or even basic culling checks for rendering optimization — it simply redraws the entire map every frame. The window contains over 65k primitives, rendered 75 times per second on a Raspberry Pi 4 without any noticeable frame rate drop. Would you be able to prototype something similar using Tkinter? 

Why would I want to? Had I proposed such an interface on the embedded systems I have worked on, it would have been considered a frivolous waste of money. Like putting a (curved?) graphics display on an electric toothbrush.

When I read about a framework hitting limits, I ask: does it make the job impossible or just very tedious? Usually it is the latter. FWIW, I found that tkinter had a simple, low level programming model that I could build on. That may not be what you would want if you need to whip up something in an afternoon or evening.

[Simon]

My main issue now is working out how to do IO (CAN bus) alongside the GUI. The way the CAN module does it is with asyncio but tkinter will apparently not work properly like this so I would have to jump a level above and put tkinter in one thread and the CAN module stuff in another. I also really don't need to have this look like a desktop program, it need to look like a control panel.

[jfiresto]

My main issue now is working out how to do IO (CAN bus) alongside the GUI. The way the CAN module does it is with asyncio but tkinter will apparently not work properly like this so I would have to jump a level above and put tkinter in one thread and the CAN module stuff in another. I also really don't need to have this look like a desktop program, it need to look like a control panel.

IIRC, I ran the programs  that read and write the CAN bus, canplayer and candump, as/in a subprocess.PIPE, and just let Raspbian assign it to an idle processor core.

[Simon]

IIRC, I ran the programs  that read and write the CAN bus, canplayer and candump, as/in a subprocess.PIPE, and just let Raspbian assign it to an idle processor core.

Are you talking about in python along with a user interface?

[voltsandjolts]

Another option maybe:
https://kivy.org/
MIT license free to use.
I've never used it but quite a few examples out there for rpi.

[jfiresto]

Yes, and all in Python. I could not find off-the-shelf solutions at the time and ended up writing quite a bit of library code to hide details from the application code. As I wrote, tkinter is pretty low level – but it did not fail me. Here are the first bits of the functions that open the CAN interface.

Code: [Select]

def start_receiving(self, for_executor=False):
        """Start receiving frames from the CAN interface.                       
                                                                               
        Start receiving for the CAN executor if 'for_executor' is true, or     
        for a CANClient if 'for_executor' is false.                             
        """
        if self._dumper:
            return
        #                                                                       
        # Start candump as a subprocess, and its daemonic line-taker thread     
        # that will receive candump's log lines and quickly pass each to the   
        # corresponding message identifier's saver functions. Stop all its     
        # message i.d.'s from calling a saver function if it received all its   
        # lines or vanished. If a saver suffers an exception, print it and     
        # stop calling the saver. If the thread suffers an exception, print it 
        # and kill the candump process.                                         
        # HACKS: Include a do-nothing '-ta' candump option to tell a simulated 
        #          candump it is feeding a CANClient rather than a CAN         
        #          executor.                                                   
        #        After the thread has died or exited, add to the _Receiver     
        #          subclass, a <result> property that will raise a RuntimeError
        #          if a caller gets or sets the work in progress data           
        #          (_self.result or self.result). Don't raise an exception,     
        #          just now, as Python may be exiting and may have killed this 
        #          thread.                                                     
        #                                                                       
        command = (['candump', '-L', self._interface] if for_executor else
                   ['candump', '-ta', '-L', self._interface])
        self._dumper = subprocess.Popen(command, stdout=subprocess.PIPE,
                                        bufsize=1)
    ...


Code: [Select]

    def play_bytes(self, s):
        """Play the string of ASCII byte, candump log lines to the CAN bus.     
                                                                               
        If 's' starts with a time and interface, pipe the line(s) to           
        canplayer. If 's' does not, pass the current CAN interface and 's'     
        to cansend -- 's' must consist of a candump line's <message             
        id>#<data bytes> characters.                                           
                                                                               
        Wait for canplayer or cansend to exit. Raise an OSError if it exits     
        with a non-zero status or if a signal kills it.                         
                                                                               
        BUGS: If it gives one, 's' must give the desired CAN interface.         
              The bytes are buffered in memory: do not use this method if       
                the string of bytes is very long.                               
        """
        if not s:
            return
        if s[:1] == b'(':
            p = subprocess.Popen(['canplayer'], stdin=subprocess.PIPE,
                                 stderr=subprocess.PIPE, bufsize=-1)
            error = p.communicate(s)[1]
        else:
            p = subprocess.Popen(['cansend', self._interface, s],
                                 stderr=subprocess.PIPE)
            error = p.communicate()[1]
        ...


[Nominal Animal]

I seem to remember coming to this conclusion as well which is why I was looking at adopting it. My understanding was that providing my program can run on a machine that has Qt installed without my program containing any code it was fine.

That is one valid way of abiding under the LGPL, yes.

Like I keep telling the ones who have not had a lawyer explain how these licenses work to them: Qt depends on an open source community, and they (except for the marketing people in charge of the sales and web pages) know that if they kill LGPL-relying projects, they will kill their own community.  All one needs to do to keep both the Qt developer community happy, and the Qt Group (the company) happy, is to strictly abide by the LGPL license as outlined by the GNU Foundation, the original authors of that license, and celebrate the use of Qt in your product.

To repeat: the main goal of the LGPL license is to enforce end user freedom while ensuring derivatives stay under LGPL or compatible license.  A proprietary closed-source project cannot derive from LGPL:d code, but it can dynamically — at run time — link to it.  Hell, the LGPL license was literally created for this purpose, the L originally referring to library.  The author of the proprietary closed-source code must allow the end users to replace those LGPL:d libraries, and not just refuse to work.  That's the copyright/legal part.  For goodwill, you celebrate the use of such community projects, and that LGPL is and will be strictly followed because copyright is important.  (Goodwill also helps immensely if you ever get targeted by a litigation-happy nutjob (they're usually lawyers).  It is way cheaper to quash such frivolous suits when you have the authors and copyright owners on your side.)

A Python application running on Linux with the GUI using standard OS-installed Qt, is well within LGPL.
In fact, any application running on Linux using standard OS-installed LGPL libraries, without requiring specific binaries for those, is well within LGPL.
You do not need a commercial Qt license for that.

If you disagree, talk to a local lawyer experienced in software licensing and LGPL in particular, or start at what the original authors of the LGPL license, The GNU Foundation, says about this.

It is an excellent idea in Python to support different bindings, too, as that maximizes end user freedom (and shows the author cares about LGPL and end user freedom, instead of dictating a fixed set of libraries that are "required" and everything else leaves the end user hanging).  I tend to support PySide2 and PyQt5 for my own Python3 + Qt5 code (because the UIBuilder is the only difference between them that matters to me), but you could also use the qtpy package instead.  In binary-only applications, this corresponds to having a mechanism to let the end users easier manage which dynamic libraries are used, for example by making sure that a dedicated library folder, say /usr/share/app/libs/ or ~/app/libs/ is preferred (searched first) when looking for dynamic libraries, so that users and admins can easily control which exact binaries and versions it link to by placing symlinks there.  If one uses a launcher script, then setting LD_LIBRARY_PATH in it before exec'ing the actual binaries is the simplest way to achieve this.

Outside Linux, Qt does have some dedicated embedded development modules that are not licensed under LGPL.  I have not used them myself, but if one wants to, then getting a commercial license from the Qt Group is an excellent idea.  That is the one case where I fully agree that one must get a commercial Qt license.

[Nominal Animal]

IIRC, I ran the programs  that read and write the CAN bus, canplayer and candump, as/in a subprocess.PIPE, and just let Raspbian assign it to an idle processor core.

For external programs with well defined and documented interfaces (command-line parameters and data structures conveyed), this is also understood to be a copyright law boundary: that doing this does not create a combined or derivative work.  (See e.g. what the GNU Foundation says about such mere aggregation.)

Simply put, proprietary closed-source applications are allowed to execute (even GPL-licensed!) commonly available command line tools and utilities thus, without fouling copyright law or the licenses.

It is very commonly used for import, export, preprocessing, and postprocessing filters, too.  I recommend using a dedicated directory for wrapper scripts, instead of hard-coding OS paths, so that admins and end users can easily fine-tune the behaviour (select which exact binaries get executed).

In this case, using shared memory, and not publicly disclosed interfaces, is where one gets into the murky fuzzy territory.  Pipes and sockets with well-defined interfaces are considered an API-like boundary.

In practice, it is quite efficient, too, other than bulk/high-bandwidth I/O being Python well-known weakness due to the text/Unicode abstraction it uses.  You can claw back some of it using bytes instead of str, though.  The Linux kernel is pretty darn good at assigning tasks to CPU cores, and there are tools like cpuset, nice, and ionice that you can easily use (by using a wrapper script in an application-specific directory that executes the target binary) to fine-tune things, although it is something we normally expect end-users and admins to do themselves, not the application authors.

[Simon]

But, but, I did like the look of InGUI. I suppose Qt can do similar.

[Nominal Animal]

You could draw the UI in Inkscape, and implement that (using SVG elements as widgets) via QtSVG.  You can of course use a PNG/JPEG image as the ultimate background, too.  As I see it, your own imagination (and time and effort) is the limit.  Did you do like I suggested, and draw your optimal UI first?  You'll find that what you thought what you wanted isn't exactly what you want, so none of that is wasted time, and will get you closer to a better UI.  Just sayin'.