Why not use the browser for the Cura UI instead of the PyQt nightmare?

[burtoogle 513]

Over and over again, we see people having problems with OpenGL and graphics drivers, etc. On all platforms.

 

It occurs to me that Cura would be much improved by moving the entire UI into a browser and use the browser's native 3d graphics capabilities to do the heavy lifting. You could still keep all the python config stuff (or not, it would be a lot of work to replace it all). But all of the Qt and PyQt stuff could be replaced with web technology (HTML, Javascript, etc.) Solve a lot of problems and make remote access a doddle.

 

Discuss.

[Smithy 1,144]

And even one step further and slice completely in the cloud from everywhere.

 

Interesting approach, but I fear this progress will never come.

[johnse 31]

As a developer with almost 40 years experience, I’m not a fan of “web tech” for applications. (Nor am I a fan of Python...) JavaScript is a language that throws away several decades of industry learning about how to build robust software. Typescript fixes that to a small degree, but you still often have to break type safety to achieve your goals.

 

If one were going to rewrite, it would be better done using something like Xamarin...C# is an excellent, performative language with a lot of community support. It has Microsoft behind it who is doing a ton of cross platform and open source work these days. (Disclaimer, I work at Microsoft but not on these systems—my words are mine and I do not speak for the company.) and Xamarin appears to have support for Metal.

 

 

[ahoeben 1,948]

Cura is bound to Python in much more than just its GUI. Even profiles and printer definitions contain Python code to specify relations between settings.

 

If you want to handle these profiles and definitions in the browser, you would either need a Python interpreter in the browser, or accept that there will be no backwards compatibility.

[burtoogle 513]

4 hours ago, ahoeben said:

Cura is bound to Python in much more than just its GUI. Even profiles and printer definitions contain Python code to specify relations between settings.

 

If you want to handle these profiles and definitions in the browser, you would either need a Python interpreter in the browser, or accept that there will be no backwards compatibility.

 

No, I'm not suggesting that the profiles & definitions are handled in the browser. You could still have a python app like now except the UI would be browser based and use WebGL (or whatever it is called) for the 3d part. The app would be a web server that you just point a browser at.

[ahoeben 1,948]

Then you would have 3 parts written in 3 languages communicating with eachother. I don't think that would result in fewer edge-case issues. One of the major issues on windows is that CuraEngine sets up a server for communication with the frontend; some anti-virus applications either block CuraEngine for it, or at least the communication between the two parts.

 

I am not a fan of full rewrites, and much more in favor of incremental refactoring. If you remember legacy Cura (15.04 and older) and the painful releases of the first, totally rewritten 2.x versions, you know how much a rewrite can break or how much of your workflow can just vanish in a rewrite. There's a lot that does work in Cura, a total rewrite will mean that those parts also have to be redone.

 

I don't entirely agree with your sentiment about the "PyQt nightmare". I don't think PyQt is the problem. Trying to support a wide variety of systems and platforms is. There will always be systems that have issues running sufficiently complex software, and those users will complain. But you won't hear the masses of people for which the software does work. Handling massive polygon count objects in a browser engine doesn't magically solve issues it means that there is a harder cut-off of what computers will be supported.

[burtoogle 513]

TBH, I don't seriously expect Ultimaker to embark upon a(nother) major rewrite of Cura. But I still think that there's a case for creating a browser based UI that will reliably work across all platforms (that support WebGL). I'm gonna keep thinking about that...

[nallath 1,120]

I absolutely don't think that PyQt (or Qt) is the problem at all. Hell, I don't even think that Python is the issue. The main issue is simply cross platform issues and using OpenGL at all (which is something we kinda have to do, regardless of the choice that we made).

The native 3D graphics also means that we double the amount of configurations that we need to support. Now we just have to support 3 operating systems (which is a PITA enough as it is) but then we also need to do it for multiple operating systems and multiple browsers.

There is a case for it, sure. But the ugly truth is that we're already short staffed as it is. Essentially re-writing the GUI (which is 75-80% of the codebase) is simply not feasible (In general, in the current state it's just flat out impossible).

All that being said; Feel free so do some experimentation. Don't believe me on my word for things. I'd love to be proven wrong in this case.

[geert_2 557]

I am not really a fan of browser-based GUIs, because that leaves you with an additional variable that you are dependent on but have no control over: the browser. Here are a few examples.

 

Firefox was excellent until one day they changed the whole UI and concept, after which it broke all add-ons and became useless for 80% of its users. This broke a lot of people's workflow.

 

Advanced users - like most people here are - tend to install a lot of add-ons in their browser, which may create additional dependencies and trouble. Some people - or some of these add-ons - may disable java, javascript, flash, silverlight, active-x, cookies, external fonts, third-party images, right-click functions, pop-up functions, resize-functions, and whatever else.

 

If you have a good but not very common browser, like Pale Moon (=a Firefox derivation that has kept the old GUI-concept with menubar and statusbar), then this is often not recognised by the server. And then the server messes-up its webpages by *assuming* stupid things, for example that I have a micro-screen of 320x240 pixels instead of my real 1920x1080 pixels. So it sends me garbage instead of standard HTML: it sends fonts of 5cm high, so only a few lines fit on my huge screen. The bigger the organisation, and the more they are specialised in communication (e.g. news-sites and newspapers), the worse this gets, and the less they communicate.

 

A lot of modern browsers even mess-up perfectly valid and simple standard HTML, which by design should reflow automatically in the available window. The browser should take the default font-settings if not specified, without changing them. But they don't. For example Google Chrome Mobile rescales some paragraph's font-sizes (sometimes making it larger, sometimes smaller), but not other paragraphs. And some browsers refuse to reflow text, so it falls off the screen. So you can't even limit yourself to old-school 1995's HTML and forms, because even these break today.

 

You don't want that kind of trouble in a slicer GUI.

 

Cloud-based computing is even worse: then you become dependent on a very unstable variable: the internet/network, coming with all its interruptions and its hazards (virusses, spyware, interception, industrial espionage...). It is unusable while moving (train, plane) or in remote areas: even Germany has no internet in lots of its eastern rural areas. And the data going over their monthly limit, and you going over your budget. Also, this creates GDPR and similar legal problems.

 

So I prefer independent standalone applications installed on and running on the local computer. One application per function. Preferably with all user-settings stored in the same directory as the main program, or a subdirectory "user-settings". Not splattered all over the harddisk in unaccessible directories. So that it is portable. Although of course all programs should use generic and standard datafiles for smooth data-exchange.

 

I am aware that my view may not be "politically correct", but this has proven to work best (for me).