You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey again!
I've been working quite a bit with the .geom_hline function for limits and have noticed that for the lines created by this are always on top, even if the function is called after the main plotting function (like .stat_boxplot).
Is there a way to determine the ordering of the gramm plots so as to determine which would be in the foreground and which in the background? I'm painfully aware of how unintuitive this is to accomplish in MATLAB manually.
From looking at the code in .draw, I see that the hline/vline/etc. take place after the main plot (probably why they're on top) and that trying to mess around with the order of these parts for my own sake would probably end up in disaster, which leaves using uistack() for this purpose, this could probably be accomplished by using an array to decide the order of the graphical objects and then sending each one to the 'top'/'bottom' according to that order so they stack accordingly, but since this would require getting brand new input from the user, I'm not really sure how to implement it right now...
The text was updated successfully, but these errors were encountered:
The last update I pushed, along with the upcoming geom_polygon() update are paving the way for allowing just that (i.e. choosing whether your geom_Xline() are below or above the other graphical elements)... Stay tuned !
On the other hand, nothing is planned for changing the way the data-driven geom_ and stat_ layers are ordered: for these the call order is respected within subgroups. It's due to the way gramm loops through the subgroups. Do you think some additional granularity is needed there? (I don't).
That's great news! (geom_polygon sounds exciting 😬)
I agree that I don't see a great benefit from choosing ordering between subgroups (with perhaps the ability to draw geom_point on top of some stat_ just for distribution clarification, but this sounds like an fringe issue that can be resolved in other ways and should be specifically addressed at the moment.
Also, is the plan currently to have all the geom_Xline functions to be either on the top or at the bottom or will there be an option to determine this per-line? this could be relevant for cases where one line is used for displaying the set limits (where one would want it to be on top at all times) and another to show different steps along the way, such as 25%, 50%, 75%, etc. (where this might be better as an addition in the background).
Well if you call geom_point() after a stat_xx(), point of one color will already be above their own stat_ representation. The problem only arises if you have overlapping stat_ in different colors.
A per-line choice for the geom_Xline is not much harder to do, and since it's not programmed yet that is a possibility!
Hey again!
I've been working quite a bit with the .geom_hline function for limits and have noticed that for the lines created by this are always on top, even if the function is called after the main plotting function (like .stat_boxplot).
Is there a way to determine the ordering of the gramm plots so as to determine which would be in the foreground and which in the background? I'm painfully aware of how unintuitive this is to accomplish in MATLAB manually.
From looking at the code in .draw, I see that the hline/vline/etc. take place after the main plot (probably why they're on top) and that trying to mess around with the order of these parts for my own sake would probably end up in disaster, which leaves using uistack() for this purpose, this could probably be accomplished by using an array to decide the order of the graphical objects and then sending each one to the 'top'/'bottom' according to that order so they stack accordingly, but since this would require getting brand new input from the user, I'm not really sure how to implement it right now...
The text was updated successfully, but these errors were encountered: