On 11/21/2017 03:31 AM, Alex Rössler wrote:
Hello everyone,

Hi Alex,


I have started a new VCP project approximately 4 years ago because I was
very dissatisfied with what was already available in LinuxCNC at the time.

 From a users perspective, the UIs were not usable for 3d printers and did
not even come close anything visually acceptable by the post-smartphone
era customers.

 From a developers perspective VCPs where completely outdated and not
even close to what modern UI toolkits offer. No developer really want's
to work with tk, we can argue about Gtk2.

More UIs and UI frameworks are always welcome.


 From an OEM perspective, there was no option to build a close-source UI
on top of LinuxCNC without a lot of effort. Additionally, if the OEM
decides to stay with Gtk2, it's not supported anymore and (almost) no
commercial help available.

I am not at all interested in closed source UIs, or closed source software in general.

The whole point of the LinuxCNC project as far as I'm concerned is to produce open source machine control software; anything that's not directly aligned with that goal is at best distraction to me.

I understand that not everyone agrees with my opinion on this topic, and I hope we can make progress on the technical aspects without getting bogged down in a political/philosophical conversation.


That's why I started a completely new approach for creating a VCP
development kit based on QtQuick - which is Qt's UI development
technology.

Awesome!


QtQuickVcp comes with 2 reference UIs:
- Cetus: designed as axis replacement: https://github.com/qtquickvcp/Cetus
- Machineface: a generic and full-blown 3D printer UI: https://github.com/qtquickvcp/Machineface

I agree both are not top notch when it comes to UI design. But with a
little effort you can create great stuff with QtQuickVcp
https://www.youtube.com/watch?v=uT-tAweP21U

All UIs run on Linux, Windows, OSX, Android and iOS (not in the app
store).

How does the UI reach from the machine it's running on to the machine running the motion controller? I understand that it's using some innovation from Machinekit, but does it still end up talking to Task using NML in the end? I haven't been following Machinekit at all so I dont know what architectural changes y'all have made. If it ends up being NML to Task we can probably support it in LinuxCNC.


To simplify remote deployment of the UIs one can simply download and run
the "MachinekitClient" (yes, it's Machinekit only right now) and connect
to the machine instance.

So MachinekitClient is some kind of generic UI-running application, sort of like a web browser, and the UIs are runtime-loadable front ends sort of like web pages?


To support LinuxCNC would be quite simple. The machine/server part is
based on Machinetalk - an open source middleware.

Basically, it would be a matter of "adapting" mkwrapper, mklauncher and
configserver (Python applications) over to LinuxCNC.

HAL Remote - which is useful for custom extensions would require more
effort, since it depends on the haltalk server - which goes deep into
Machinekit.

This to me seems like the bulk of the work.

Remote UIs need a way to talk to the motion controller, and I understand the interfaces available for this in Machinekit are far different from what we have in LinuxCNC. We have working NML-over-TCP, but no MDNS-SD auto-discovery and no remote HAL interface (halrmt doesn't count).


 From the user perspective, I think the split between LinuxCNC and
Machinekit makes absolutely not sense and is very confusing.

I agree with this statement, but it's another tangential topic that I will stay out of, because it threatens to distract from the productive technical conversation.


Requiring the Qt toolchain, which can be cumbersome to install, is not
an issue anymore thanks to live coding support:
https://www.youtube.com/watch?v=B5rYhq06wio

What Linux distros can you run an existing QT Quick UI on, by installing only software that's packaged for that distro (preferably from the normal distro maintainers rather than from the upstream QT folks)? I see that libqt5quick5 is available in Wheezy's backports and in the normal repos for Jessie and newer. Is that what's needed to run QT Quick UIs? What else is needed?

https://packages.debian.org/search?keywords=libqt5quick5&searchon=names&suite=all&section=all

What Linux distros can you *develop* a QT Quick UI on, again by installing only software that's packaged for that distro by the distro maintainers?


If there is enough interest, I will start porting the required tools.

I'm cautiously interested and I welcome your work, if we can make it fit. I think the UIs you've demoed look great, and I'd love to have modern QT-based UI framwork(s) for LinuxCNC.


--
Sebastian Kuzminsky

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to