Re: [PyCAM-devel] Gtk3 Update

[Lars K. <li...@su...>]

Hi Reuben,


Am Fri, 3 Mar 2017 22:55:13 -0500
schrieb Reuben Rissler <si...@em...>:

> I decided to give gtkglext for Gtk3 a whirl.

thank you very much for tackling this topic! These two dependencies (GTK2 +
gtkglext) are the main obstacles on the way to a brighter (python3) future of
PyCAM's code.


> After doing some workarounds, since autotools has changed since 2012 (the
> last commit to gtkglext3), I ended up with some cryptic errors I have no idea
> what mean.

Could you maybe share your attempt with us by opening a merge request on github
or sharing a patch or the URL of your git repository?
(I understand that this state is completely unusable - but it could be
inspiring anyway)


> Can somebody tell me what the gtkglext thing is supposed to do? Just a 
> visual presentation of the loaded file? There gotta be something 
> somewhere that works with Gtk...

gtkglext provides a GTK2-compatible viewport. Thus it can be treated like a
GTK2 widget from the outside.
From the inside you can use OpenGL for visualizing things.
(which is a hell to maintain and develop - we surely want something more
high-level instead of the really low-level OpenGL details)
The visualization currently includes the following details:
* 2D and 3D models
* support grids (i.e. more 3D models)
* the processing "boundary" (just a transparent cube)
* the resulting toolpaths
* a simple toolpath simulation (e.g. toolpath + simple tool shape)
* the xyz axes
* the ability to zoom/shift/rotate with keys and the mouse
(we surely do not need all of the above features at once)


My personal migration theory would be the following:
* find a nice high-level visualization engine that works with gtk2 and gtk3
  (maybe some game engine or something used by scientific applications)
* throw away or replace the old opengl code and try to get really basic
  functionality with the new engine
  The OpenGL-related code is contained in some plugins - see pycam/Plugins. The
  names should help to identify them quickly.
* afterwards we can think about switching to GTK3
(you may replace "GTK3" with "QT" or something else - this is left to the
implementor)

Personally I could also live (in the short term) without a visualization. Thus
it would also be acceptable to just move all opengl-related code aside and only
work on the GTK2/GTK3 migration.

Cheers,
Lars