Split user interfaces from the Machinekit core packages

[ArcEye]

Issue by machinekoder
Mon Nov 3 09:24:09 2014
Originally opened as machinekit/machinekit#357

---

Most user interfaces have lots of package requirements. At the moment the Machinekit packages do not fetch all of these requirements which is good an bad. Good because it saves storage space if you do not use these user interfaces and bad if you want to use these user interfaces. It would be a good idea to split the user interfaces in different packages.

[ArcEye]

Comment by machinekoder
Mon Nov 3 09:31:49 2014

---

One approach would be to create pseudo packages that fetch the necessary dependencies for the specific user interfaces. But I see no reason why we shouldn't move the whole user interface into a extra package except as temporary fix.

[ArcEye]

Comment by RunningLight
Mon Nov 3 12:33:15 2014

---

Don't the major Linux desktop environments present the same dilemma to the Linux distros? The distros I know package Unity/Gnome/KDE/... the similarly and surely their pseudo packages were harder to create than ours would be. I think the question of split/don't split comes down to "who's going to make it so?" Once done, it should be easy to maintain.

[ArcEye]

Comment by ArcEye
Fri May 22 11:14:31 2015

---

With the release of Jessie, it is noticeable that Qt5 has still not been adopted.

The default libs are Qt4 and that is what the main Qt apps are built against.
Qt5 is available as a user option.

With @Strahlex 's work relying heavily upon Qt5 and future erradication of tcl etc. probably also being dependant upon some modern GUI programming system being available, do we need to start pushing Qt5 forward?

I already have a prototype pickconfig replacement, that uses just Qt5 and makes a lot of the tcl redundant.

A replacement for Axis, with a basic single instance, non-networked app is quite feasible and I have a prototype, albeit less advanced, for that too.
That would erradicate tcl / tk , bwidget etc at a stroke

Everything hangs however upon the adoption of Qt5 within Machinekit.
On x86 machines it is trivial, perhaps on ARM running on SD cards, not so.

The builds can be scripted with no more user awareness than present, but require the inclusion of headers, libs and tools, thus adding to the dependency chain.

How do those most involved in the packaging, image production etc feel about this?
@mhaberler
@zultron
@cdsteinkuehler
@Strahlex

Keep everything together, or spin off additional packages as Alex suggested

The latter is probably best in keeping with what I recall as an original aim, of making Machinekit a package independent of kernel and distro.

Users can take it up or not as they wish, when it has something they perceive that they want, they will do so.

What say you?

[ArcEye]

Comment by RunningLight
Fri May 22 12:54:21 2015

---

do we need to start pushing Qt5 forward?

Yes.

As for your further remarks, I'm not "most involved in the packaging" but I believe the suggestion of @Strahlex is worth pursuing. To a user, the result should be no more difficult conceptually than the current pseudo package approach to accommodating different desktop environments in Linux; to a developer, the result is more freedom to use the "kit" as intended.