-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
refactoring of QgsMapToolCapture to integrate shape map tools #46687
Conversation
I haven't looked at the code, but I fully support the design changes here. (I've wanted similar to allow the shape digitising for annotation items!). Great work @3nids! |
65aaad2
to
992e822
Compare
I can't review it this week, but it's a big +1 for this design. Thanks @3nids ! |
992e822
to
f1edb07
Compare
thanks @lbartoletti and @nyalldawson for the thumbs up I have gone a bit furthe:
|
b5c145f
to
df6d2e1
Compare
* Called when the geometry is captured | ||
* \since QGIS 3.24 | ||
*/ | ||
virtual void geometryCaptured( const QgsGeometry &geometry ) {Q_UNUSED( geometry )} SIP_FORCE |
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.
Shouldn't these be protected in order to allow python subclasses of the tool to function correctly?
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.
I thought it was ok with forcing them with SIP_FORCE. Am I wrong?
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.
I'm not sure either way -- it just looks problematic to me when a protected method is guaranteed to work correctly
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.
quoting https://stackoverflow.com/a/2170696/1548052
This lets the derived classes override the function to customize the behavior as needed, without further exposing the virtual functions directly by making them callable by derived classes (as would be possible if the functions were just protected). The point is that virtual functions exist to allow customization; unless they also need to be invoked directly from within derived classes' code, there's no need to ever make them anything
And if you consider the idea of the additional class to handle the avoidIntersections, we'll be dealing with the private handler on the geometry and it will be better to just not forward the specific handlers.
4703779
to
24ccf65
Compare
54ac82b
to
0ec45e8
Compare
Some progress have been made:
Remains:
I know this a big code change, but I would like if possible to merge it during this cycle. |
13b583b
to
7a8dbb9
Compare
Refactoring of existing shape tools is completed |
a7bfcc6
to
ed7f802
Compare
ac7b351
to
3cccf4f
Compare
Thanks a loooooot for the review @nyalldawson. |
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.
Except for a few details, it's good for me.
@@ -0,0 +1,85 @@ | |||
/*************************************************************************** | |||
qgmaptoolcircle2points.cpp - map tool for adding circle |
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.
qgmaptoolcircle2points.cpp - map tool for adding circle | |
qgsmaptoolshapecircle2points.cpp - map tool for adding circle |
Same for other files
{ | ||
if ( !mParentTool || mCircle.isEmpty() ) | ||
{ |
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.
IMHO braces should be always present around statements even for one line if.
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.
I personally like the readability when there is only one line.
The coding guidelines are not super explicit about this, but there is an example with it https://docs.qgis.org/3.16/en/docs/developers_guide/codingstandards.html#put-commands-on-separate-lines
@3nids |
This moves part of the code from
QgsMapToolDigitizeFeature
toQgsMapToolCapture
so the tool can actually capture point, line and polygons. It's mainly the 'cadCanvasReleaseEvent` which has been transfered.This is a preliminary work to support shape digitizing in more map tools (like add part, add ring, fill ring or anything else).
The idea is that
QgsMapToolCapture
should actually perform the digitization of point/line/polygon and let subclasses deal to what they want to do with it (create feature, add part, add ring, etc).Then,
QgsMapToolCapture
will be able to digitize shapes (by adding a new enum entryCaptureTechnique::ShapeDigitizing
). The idea is that the shape toolbar will be turned into a checkable choice so thatQgsMapToolCapture
will be able to perform any of the capture technique entries:I'd like to get opinions of the map tools experts @lbartoletti @nyalldawson. If you consider I should open a QEP for this discussion, let me know.