Add circular coordinate system display - #333
Conversation
| return matrix_deg( 0, 0, rZ, cX, cY ); | ||
| } | ||
| }; | ||
|
|
There was a problem hiding this comment.
State is just a helper class for reoccuring calculations
| gradient.setLinearDirection( Qt::Vertical ); | ||
| gradient.setStops( { { 0.0, gradient.startColor() }, { pY, gradient.startColor() }, | ||
| { pY, gradient.endColor() }, { 1.0, gradient.endColor() } } ); | ||
|
|
There was a problem hiding this comment.
Creating a gradient with stops at 0%, 50%, 50% and 100% to achieve hard line
There was a problem hiding this comment.
When not having a stop at 0.0 the renderer takes the color of the first step and fills from 0.0 to the first position. Similar, when you do not have a stop at 1.0. So in this particular case it would be enough to have the 2 stops at pY.
| auto* const transform = static_cast< QSGTransformNode* >( clipping->firstChild() ); | ||
| auto* const tickmarks = static_cast< LinearTickmarksNode* >( transform->firstChild() ); | ||
|
|
||
| auto size = qvariant_cast< QVector3D >( sensor->effectiveSkinHint( subControl ) ) * r3; |
There was a problem hiding this comment.
@uwerat this is somewhat hacky to allow styling of tickmarks heights/width for major, medium and minor ticks
There was a problem hiding this comment.
My fist idea would be to use QskAspect::Variation, where you have Tiny/Small/Large/Huge. However this would block using other variations like Vertical/Horizontal. So maybe it is not a bad idea to introduce a class for a tuple of increasing sizes - in the best case something that works for other situations as well.
Of course QVector3D works out of the box, but the QVectorXD classes are float ( not qreal ) based and have primarily been made for OpenGL APIs.
peter-ha
left a comment
peter-ha
left a comment
There was a problem hiding this comment.
Just voicing my thoughts; Uwe might have a different idea on how this should be structured, or whether this should be a Qsk* class now etc.
| QskHashValue m_tickmarksHash{ 0 }; | ||
| }; | ||
|
|
||
| class LinearTickmarksNode final : public QSGGeometryNode |
There was a problem hiding this comment.
use QskTickmarksNode here? Or is there something missing? I guess in the long run it would be good to have one global tickmarks node class that covers all use cases...
There was a problem hiding this comment.
Please note that there are some pending changes around the axes/scales in this branch: https://github.com/uwerat/qskinny/tree/features/plots I did not merge them to master, because I'm not 100% happy with everything ( f.e aligning the lines to avoid the unwanted OpenGL antialiasing of vertical/horizontal lines ).
There is another branch https://github.com/uwerat/qskinny/tree/features/geometrynode, where I'm trying to introduce a QskGeometryNode to simplify the implementation of geometry nodes in combination with QSGFlatColorMaterial/QSGVertexColorMaterial.
I was distracted by the ongoing changes because of the Fluent2 skin - however it might be worth to check if there is something of value for your work in these branches.
| int m_count = 360; | ||
| }; | ||
|
|
||
| template<typename CRTP> |
There was a problem hiding this comment.
What does CRTP mean? Doesn't sound easy to understand...
There was a problem hiding this comment.
Curiously Recurring Template Pattern
https://en.wikipedia.org/wiki/Curiously_recurring_template_pattern
| const QskLevelingSensor* const sensor, const QRectF& contentsRect ) const = delete; | ||
|
|
||
| template<> | ||
| Q_REQUIRED_RESULT QRectF QskLevelingSensorSkinlet::subControlRect< R::OuterDisk >( |
There was a problem hiding this comment.
I wonder if this template specialization is needed here
There was a problem hiding this comment.
not needed, but subjectively nice to look at ;) + you don't need a function declaration for each role...
| Sequential, | ||
| Recursive | ||
| }; | ||
|
|
There was a problem hiding this comment.
@uwerat This function is a candidate for public API and could be moved to QskSGNode.h next to ensureNode
There was a problem hiding this comment.
Wouldn't its be clearer to have one template for creating siblings and another for creating a hierarchy:
- QskSGNode::ensureSiblings
- QskSgNode::ensureHierarchy ( maybe there is a better name ? )
|
Not trying to bring pressure or so, but @uwerat do you know whether this will be a Qsk* class, or rather a class in an example or so? We are wondering how we should use/name this internally... |
3 participants
Uh oh!
There was an error while loading. Please reload this page.