Re: [PyCAM-devel] Porting Pycam to Gtk3

[Reuben R. <si...@em...>]

On 05/22/2017 11:51 PM, Lars Kruse wrote:
> Hi Reuben,
>
>
> Am Sun, 21 May 2017 19:27:17 -0400
> schrieb Reuben Rissler <si...@em...>:
>
>> [..]
>> As you can see, the comboboxtext is a lot more suited for a simple units
>> selector. There will be some other gotchas involved when using a
>> comboboxtext which I will not go into here. This leads me to my primary
>> question. Why, excuse me, is the plugin manager so hideously complex?
> after the v0.5.1 release I started to become increasingly unhappy with the
> intertwined pile of code that accumulated around the GUI related code (e.g. the
> pycam.Gui.Project module contained more than 2000 lines of code).
> Thus I went into the other direction: separate and decouple features from each
> other.
> In hindsight I am sure now, that I went way too far with this approch.
> Most trivial plugins are quite easy to understand - but a few are really barely
> comprehensible (e.g. collecting task-related settings before toolpath
> calculation). This surely deserves a better structure.
>
>
>> Does Pycam require this because of Gtk2? Or maybe nobody ever bothered
>> to clean it up and code just kept being tacked on to cover up previous
>> cruft? Or am I ignorant / naive to plugin methods?
> Probably your impression is correct - the modularization turned out to be quite
> excessive.
>
>
>> I don't see that we can even port Pycam to Gtk3 if some of the methods
>> that are being used are really required.
> >From my point of view many parts of pycam's GUI tried to be a little bit too
> convenient (instant visualization updates, triggered changes of other fields,
> visual conflict signalling). This is surely not necessary and may be cut back
> without worries, since its development and maintainance consumes way to much
> time. A simple (less responsive) GUI is surely acceptable for most users and
> would free more time for improved toolpathing algorithms.
>
>
>> To get Pycam to this error I disabled and converted a bit of Gtk2 code. If
>> somebody knew what widgets / plugins are being loaded dynamically, this would
>> simplify porting to Gtk3. Or should I ask if it is necessary to load so many
>> plugins? Looking at Pycam>View>Plugins, it looks like some of the plugins can
>> not even be disabled.
> The plugins that cannot be disabled are required by other plugins. This is
> subtly visualized with the "enbaled" checkboxes: loose leafs of the dependency
> tree are "active" - lower level plugins (being required by others) are
> "disabled/inactive".
>
>
>> So why would all these plugins not just be hardcoded into the .ui file/.py
>> file where applicable?
>
> You are kindly invited to change this approach.
> The previous situation included a single ui file with close to 10000 lines of
> code. Even with graphical tools (e.g. glade) this was barely managable from my
> point of view. A good balance is hard to find.
> Anyway: I am really not attached to the current structure.
I understand. Now, were you putting each 'set' of widgets in place 
(frames, boxes, panes, etc)? Lately I have started to put everything 
together if at all possible. In other words, not taking a standalone box 
and giving it a parent at runtime. Rather, put the box in it's parent 
window or whatever, but set it insensitive or even invisible and then 
change it to visible / sensitive as needed.

I know a lot of people used to edit the .ui files by hand back in Gtk2 
because of the shortcomings. In Gtk3 this is no longer necessary. So if 
this is properly done, a 10,000 line .ui file is not a problem.

My products.ui for my accounting system has 1800 lines and it is fairly 
easy to navigate IMO.
>
>
>> In the end, one of my greatest drawbacks is that I have no CNC
>> machinery, and cannot really test Pycam. Maybe someone that understands
>> CAM can tell me why all this is necessary. Especially the feature to
>> turn off plugins. Is plugin disabling used to cover all the different
>> CAM cases?
> No, it was just an excessive approach in order to get rid of the previously
> excessive monolithic code pile. A shift to a more balanced middle ground would
> be great.
>
>
>> Not to borrow trouble, but Gtk is very fast paced and dynamic. This
>> means Gtk has one of the most full fledged toolkits. It also means Gtk
>> is bleeding edge at times. Say for instance, in Gtk4 it is planned to
>> replace the current combobox with a new design that covers a lot of the
>> limitations of the current designs of comboboxes (great! IMHO). So if
>> Pycam stays Gtk, some thought needs to be taken to make Pycam
>> upgradeable in the future.
> Maybe you want to take a look at pycam.Gui.ControlsGTK?
> This module provides most controls used within pycam, I think. This module was
> supposed to make it easier to switch to another toolkit, by providing one
> specific place, where most toolkit-related code is located. Hopefully it is
> rather helpful instead of being an obstacle.
Actually I am acquainted with that file :)

Reuben