[3dprinter-general] Printrun dependencies issue

[Rock Storm]

Hi Gregor,

On Mon, 2023-08-21 at 13:13 +0200, Gregor Riepl wrote:
> I started working on porting printrun to pyglet 2 / modern OpenGL.
> As you might have guessed, it's a pretty large task due to the=20
> fundamental differences between OpenGL fixed function and programmable
> pipelines.

Can't thank you enough. Much appreciated. And yes, I had a quick look at
it and it wasn't something easily fix by just changing a couple of lines
of code here and there.

> pyglet 2 has a built-in render pipeline that can be used as-is,=20
> customized or completely overridden. Each approach has different=20
> advantages and limitations. The current pipeline in printrun is mostly
> custom (with respect to pyglet), so I think a hybrid approach would be
> most appropriate.
>=20
> Other options:
> * Completely refactor printrun and rely on pyglet 2 features only. It=20
> would simplify the code greatly, but reduce flexibility, and I'm not=20
> sure if it's possible at all.
> * Use an OpenGL compatibility profile and rely on the emulated fixed=20
> function pipeline. This would require the least amount of changes on
> the=20
> existing render code, but I'm not sure if it will play well with
> pyglet=20
> 2. Also, the required functionality is only available up to OpenGL
> 3.0,=20
> and was completely left out of OpenGL ES 2+. I'd only take this
> approach=20
> as a temporary workaround until printrun is completely ported.

In my personal opinion, printrun's code needs a big refactoring effort.
Current code was made by hundreds of little patches which, in the end,
turn into a hard to maintain, not very coherent code base. So I'm all
for a "complete refactor".

In my mind (and here is where I'm hit with limited knowledge), pyglet is
used only on certain areas of pronterface and plater to draw 3D scenes.
I would think a full re-write of those sections should be possible (and
desirable) without breaking the core program functionality. Better do a
proper future-proof job than keep on patching and old code base.

However, this is something that needs to be agreed upstream and the
solution needs to play well on all platforms.

> > A manual removal from testing solves a) and an RC bug would solve b)
> > but
> > feels a bit over the top to me because the package is still usable
> > just
> > some features don't work.
>=20
> What about removing the features in printrun that require pyglet 1?
> As far as I can see, this only affects pronterface. printcore and=20
> pronsole would still be usable, so how about just not installing=20
> pronterface and removing the pyglet 1 dependency from the Debian
> package?

That is a good point. I would've said a big part of the user base uses
mainly pronterface (which seems to be confirmed by printrun's popcon
statistics [1]?). So I think shipping the Printrun suite without
pronterface would not be welcomed by most users. I think even shipping
it as it is today, usable but with no 3D features, would be a better
scenario.

My purist self wants to either ship it good or remove it entirely. But
I'm open to suggestions.

[1]: https://qa.debian.org/popcon.php?package=3Dprintrun



Regards,

--=20
=E2=A2=A0=E2=A3=A4=E2=A3=BC=E2=A3=A7=E2=A3=A4=E2=A1=84 Rock Storm
=E2=A3=B6=E2=A3=BF=E2=A0=8B=E2=A0=99=E2=A3=BF=E2=A3=B6=E2=A0=80https://gith=
ub.com/rockstorm101
=E2=A2=A8=E2=A0=BF=E2=A0=83=E2=A0=98=E2=A2=BF=E2=A1=85 C304 34B3 632C 464C =
2FAF C741 0439 CF52 C968 32FD