New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft: Edit improvements to context menu and code organization #4811
Conversation
@matthijskooijman thanks for the code example :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for picking this up! I really like where this is going.
Overall, the code looks great as-is. I left a bunch of inline comments on where I think things could be made a bit better.
I also left some comments about splitting this PR into more smaller commits, which would greatly help the reviewability of it. One additional commit that you could maybe split off is a commit where the contents of addPoints
is spread around the various GuiTools
base classes, but without all the menu generalization yet. Instead, as an interim approach, you could just have evaluate_menu_action
call obj_gui_tools.add_point()
instead of self.addPoint()
. By itself, that's not very pretty, but as a temporary situations to be improved in a following commit, it would be fine. Combined with the other commit-splitting suggestions I made, I think that the main "generalize actions" commit would then be significantly smaller, making it a lot easier to see what's going on.
Ok, here goes. I can't really comment on gitkraken (I always use the commandline since there it is, to me, clearest what happens under the hood and you can always use all features, rather than the subset exposed by the GUI), but I'll try to also explain the concept so you can find the same thing in gitkraken. First off: I think it would be good to first further update the code to look like you want it to look (e.g. generalizing the getObjectInfo stuff), since you'd otherwise need to make those changes twice later. Intended commit history
Basic approach
Note that especially the Additional work for commit 4 and 5 Verifying commits work Interactive rebase and fixup commits Even more, you can tell git to squash some commits together in the process, which means it becomes very easy to fix mistakes later: If you already committed something, but spot a mistake in it, you just make a new commit with just the fix, and then use an interactive rebase to move that "fixup" commit backwards in history to be right after the original commit, and then ask git to squash them together into one commit, as if the mistake never happened. Git even automates a part of this process using Force pushing Commit messages Final words On another note: given you're still working on this PR, maybe you should mark it as a draft for now. Then once everything is cleaned up and we're happy, it can be marked as done, maybe marking a more clear point for the maintainers to have a look at the PR. |
73c1e53
to
46a893a
Compare
As a general note, GIT mastery is never a formal requirement here... We all try to learn and make things better, PR after PR.. In that regard, @matthijskooijman 's comments are precious (I learned a couple of things too), it's time more than well spent to help us making things better ;) But I don't think we would refuse a PR or anything because of not optimal GIT formatting (unless things are very, very bad of course :D ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@carlopav Nice, restructured commits look good!
I left some small remarks on the code inline.
As for commit structure: I saw you added the getSpecificObjectInfo and resetTracker-wrapper as two additional commits at the end, rather than folding them back into the history. This is of course fine (as Yorik also emphasized, no need for commit structure to be perfect), but let me at least suggest some advantages of reordering those changes:
- If you introduce getSpecificObjectInfo in
addPoint
before splitting it out, then that commit becomes a lot smaller (only one place to change) and easier to review and understand the behavior changes it makes (only working on oneobj
, rather than allself.selected_objects
and/or all hovered objects as before). Similarly, theadd_point
split commit becomes smaller too. - If you make those changes to
addPoint
first, then theadd_point
split commit really just moves around code, without changing any behavior, which is again easier to review than a commit that moves around a lot of code and also makes some subtle changes in behavior. - If you introduce the
resetTracker
-wrapper right away in the "restructure" commit, then you can leave out theresetTracker
calls from thehande_foo
methods, and even more, leave out thehandle_foo
methods entirely, making that commit again smaller and simpler. Note that I just realized you could maybe even split this further: first move all theresetTracker
calls into a single call inevaluate_menu_action
, and then do the "rewriting" commit after that, which can then be a little shorter.
Responding to @yorikvanhavre:
As a general note, GIT mastery is never a formal requirement here...
Thanks for confirming that. I do have a tendency to sometimes go a bit overboard with git history perfectionism (both as a contributor and a maintainer for other projects) sometimes, but as a contributor, I think it is important to do it properly because it helps making reviews easier, which allows more people to participate in the review process and takes load off the maintainers, allowing more changes to be merged. Looking at this project, I have the feeling that maintainer time and energy is indeed a more limiting factor than contributor time and energy, so IMHO it would be worth it for me, as a contributor, to spend, say, an hour extra on my commit history, if that shaves of 10 minutes of maintainer review time.
From the maintainer point of view, there is another argument to want a clean git history: It makes reading the history easier too. When figuring out how a piece of code works, the git history is often an invaluable tool for me, to see when and why a surprising bit of code is introduced. A small commit with a isolated change, ideally with a clear message that explains why a change is needed and/or links to a bug report comes a long way to understanding the origins and evolution of a bit of code and often helps to figure out which of many ways to fix a bug is the most appropriate.
Having said all that, there is of course a balance between a which for a clean history, and being open and having a low bar for new contributors. Git by itself can be tricky enough to scare away potential contributors, even without the fancy history editing stuff, especially when the contributors are not experience programmers, which seems to be often the case due to the specific domain that Freecad is in. So it's probably good to not be too picky about git structure, but here's my attempt to maybe raise the git-level of contributions a bit without raising the bar too much :-p
Remove unused functions. Since GuiTools objects inherit from the GuiTools class, they do not need those placeholders.
This enable to start editing also without an user click event, by just calling the method and specifying the object and the edit point index. It is used for alternative edit mode (alt_edit_mode) by arc context menu
Now Draft_Wire, Draft_BSpline, Draft_Bezcurve have their own methods to add points.
get_edit_point_context_menu(self, edit_command, obj, node_idx) get_edit_obj_context_menu(self, edit_command, obj, position) that are called depending if the user is over an editpoint or over another part of the object.
Now Draft Edit can reverse the order of the points of a Draft_Wire
The wrapper allows to call resetTrackers in the main module after the callback to the GuiTools is executed. This is the last commit, many thanks to @matthijskooijman for having menthored me :) I think it's helpful to have @matthijskooijman explanation on this use of the wrapper: This defines a new wrapper function, that calls the original callback and then calls resetTrackers. Note that this creates a new function for every loop iteration, so each of these wrapper functions captures potentially different callback, self and obj values so things work as expected. Note I did something weird with the callback value there: Since functions like these capture a variable, not its value at the time of function definition, and loop variables like label and callback are a single variable shared between all loop iterations, capturing callback directly ends up with all wrappers calling the last callback (i.e. they all capture the same variable and by the time the wrappers are called, that variable will contain the last of the callbacks). This is commonly solved by using a default value in the function definition, since such a default value uses the value of the (in this case) callback variable, not capturing the variable.
In new splitted addPoint methods, getObjectsInfo and the consequent checks have been removed and moved to main DraftEdit module in a new get_specific_object_info method. This method returns the info for the selected object at a given position and the 3d Vector of the point clicked on the object.
62b8819
to
2672915
Compare
@matthijskooijman thanks, what I learned from the first command line approach:
|
@matthijskooijman can we unmark the PR as Draft? what do you think? |
If you have no further changes you want to make, then yes :-) |
@yorikvanhavre when you have some time the PR is ready to be reviewed/merged! |
So be it ;) |
thanks! |
FreeCAD/FreeCAD#4811 Updated experimental wall to work with Draft Edit after refactoring its context menu system.
Reference to post by @matthijskooijman: https://forum.freecadweb.org/viewtopic.php?f=23&t=58643&start=10#p505619
Thank you for creating a pull request to contribute to FreeCAD! To ease integration, we ask you to conform to the following items. Pull requests which don't satisfy all the items below might be rejected. If you are in doubt with any of the items below, don't hesitate to ask for help in the FreeCAD forum!
App
,Base
,Gui
or one of theMod
subfolders. If you need to make changes in several locations, make several pull requests and wait for the first one to be merged before submitting the next onesgit pull --rebase upstream master
./bin/FreeCAD --run-test 0
Fixes typo in Draft Move command text
Draft: Fixed typos
issue #<id>
orfixes #<id>
where<id>
is the FreeCAD bug tracker issue number in case a particular commit solves or is related to an existing issue on the tracker. Ex:Draft: fix typos - fixes #0004805
And please remember to update the Wiki with the features added or changed once this PR is merged.
Note: If you don't have wiki access, then please mention your contribution on the 0.20 Changelog Forum Thread.