From: Lars K. <li...@su...> - 2017-03-04 14:29:41
|
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 |