carlopav wrote: ↑Thu May 20, 2021 8:11 pm
A nicer way to handle this would, IMHO, be to have obj_gui_tools.get_edit_point_context_menu return e.g. tuples of (label, action), where the label is shown in the menu, and if it is selected, the function/lambda inside action is called (removing the need for a separate evoluate_context_menuj_action).
Can you provider a code example for that? I'm in favour of improving It if possibile.
Sure, here's some quick code:
https://github.com/matthijskooijman/Fre ... 353e7347e2
It still works for wire delete point, add point and invert arc, other draft editing will raise exceptions now. I changed get_edit_point_context_menu to return a dictionary of label: callback, so that when get_edit_point_context_menu defines which actions there are, it immediately also defines how to handle them (note that my previous proposal of returning a list of tuples might actually be better, since that is ordered and a dict is not in earlier version of Python).
Note that I used a lambda as the callback in get_edit_point_context_menu, which *captures* the value of any variables that are referenced by the lambda body at the time the lambda is created (i.e. when get_edit_point_context_menu is executed and returns the dict). An alternative to a lambda is to define a local function, which I did for add point and invert arc. Like the lambda, it captures any variables it uses. I'm not sure which of these are the best approach, depends a bit on the context I guess. Also, the handle_delete_point I added now is a bit messy, maybe it should be a local function (like add_point/invert_arc) or maybe the resetTrackers should move elsewhere (so the callback could just call self.delete_point directly).
Note that this means that the pos, obj, etc. is no longer recomputed when the action is executed (but the values are captures inside the callback), and also there is no longer a need to store the event in self.event (I just realized I removed the "del self.event" line, but I'm not sure if this explicit deletion is still needed maybe in display_tracker_menu now?)
Furthermore, I also changed the way the QMenu is handled: Instead of matching using the selected item's label, it now attaches the callback directly to the menu action using setData, meaning that handling the menu action is now just a matter of getting the callback out and calling it.
Let me know how this looks to you :-)
carlopav wrote: ↑Thu May 20, 2021 8:11 pm
edit: by the way, i really appreciate the way you write your posts, I find them written with care. May I ask you what is your background? It looks like you are interested in Arch, but it also looks like you are quite comfortable with software development :)
Thanks, I do my best :-) My background is embedded software engineering (by education and by trade), but I've also done a *lot* of more high level programming (mostly on open-source projects, somehow I almost never manage to use a bit of software without ending up submitting patches :-p). Since open-source communication is often text-based, I've had quite some practice with technical writing to make a point clear. Also, I've experienced that writing down observations in a clear way is helpful, if not for others, than at least for my future self :-p And my experience with a lot of different open-source projects has made me proficient in understanding code written by others quickly (though admittedly, FreeCAD is offering a whole new level of challenge in this area :-p).
As for Arch: I have no background or experience in that at all, but I am involved with a volunteer organization that has recently acquired ownership of a building for their activities, and now there is a lot of stuff going on there that need us to draw proper annotated floorplans for various purposes (construction work, fire safety, documenting piping and wiring, etc.).