RadHorizontalGauge - Axis/Indicators and padding

[Ofer]

Hi

I'm trying to use a RadHorizontalGauge with indicators that have some extra width (like a shape indicator which is a large circle or a text indicator containing some words) and i'm unable to display those properly when they are displaying near the Axis' edge values (they are being clipped). I've tried using the Gauge's Padding property (with and without IsClippedToBounds) and unable to get it working properly. The text/shape are being clipped at the edge of the axis and on occasions they are even displayed at an incorrect position (using both Left and Right padding seems to cause a mismatch between the axis tick/label position and the actual value they represent).

How do I get the Gauge to add "padding" to the canvas so the axis/indcators will have room to display longer text values? (like adding Margin to the Axes and Indicators but allow them to display on the entire canvas without being clipped to the axis bounds... the same effect as setting Minimum and Maximum to large values that cause the axis to draw itself farther than the edges, but without actually changing the Minimum/Maximum)

<ContentView.Resources>
    <ResourceDictionary>
        <telerikCommon:RadPathGeometry x:Key="TickGeometry">
            <telerikCommon:RadPathFigure StartPoint="0.5, 0.5" >
                <telerikCommon:RadArcSegment Center = "0.5, 0.5"
                                     Size = "1, 1"
                                     SweepAngle = "360" />
            </telerikCommon:RadPathFigure>
        </telerikCommon:RadPathGeometry>
    </ResourceDictionary>
</ContentView.Resources>

<ContentView.Content>
    <telerikGauges:RadHorizontalGauge x:Name="gauge1" IsClippedToBounds="False" Padding="30,0,30,0">
        <telerikGauges:RadGaugeBase.Indicators>
            <telerikGauges:GaugeShapeIndicator Value="5"
                        Shape="{StaticResource TickGeometry}"
                        Fill="Green"
                        Position="Center"
                        Offset="15"
                        Size="30"
                        PropertyChanged="GaugeShapeIndicator_PropertyChanged"/>
            <telerikGauges:GaugeTextIndicator
                                  HorizontalTextPlacement="Center"
                                  StrokeThickness="0"
                                  Text="Text of Indicator"
                                  Value="0"
                                  TextColor="Green"
                                  TextMargin="4"
                                  Position="Start"
                                  VerticalTextPlacement="Top"
                                  Offset="20" />

        </telerikGauges:RadGaugeBase.Indicators>
        <telerikGauges:RadGaugeBase.Axis>
            <telerikGauges:GaugeLinearAxis Minimum="0" Maximum="10" Step="1" LabelPosition="End" LabelOffset="20" TickOffset="10"/>
        </telerikGauges:RadGaugeBase.Axis>
    </telerikGauges:RadHorizontalGauge>
</ContentView.Content>

[Petar Marchev]

Hello Ofer,

Thank you for the provided code, I was able to run it without a problem and observe the issues at hand. It seems that you have stumbled upon one bug and one missing functionality.

The bug is related to the Padding of the control - the gauge incorrectly takes into account the padding in some of the calculations it does, and as a result the indicator is being misplaced. I have logged this in our feedback portal where you can track its status, and I have also awarded you with some Telerik points as a thank you for letting us know of this issue. For the moment I can suggest that you remove the Padding and IsClippedToBounds setters as they will not get you the results you are after.

The missing functionality is related to the positioning of elements when dealing with large indicators. In essence, the gauge does not take into account that the indicator will be drawn outside its bounds and get clipped. It is difficult to explain in a few words, but this is somewhat intentional.

I will skip detailed explanations for now, and if you are interested let me know, but in short - there are a number of possibilities to arrange the elements, so different layout-modes can be implemented and we chose to code the simplest reasonable one.You are the first to report hitting a problem with this.

At the moment I can suggest that you change the horizontal positioning of the text indicator. I can see that you have explicitly set the HorizontalTextPlacement to Center, and I suggest you set it to Right. This way, the text will get drawn to the right of the 0 value position. You can complement the text indicator with an arrow indicator of the same color to make it obvious to the reader what exactly is the value indicates. I am attaching a modified version of the code for your reference.

This suggestion is strongly based on the presumption that you do not require specifically Center alignment. If that is the case, can you please explain to us a little bit about the scenario, what is the final result you are after and why you need this output?

Let us know how it goes.

Regards,
Petar Marchev
Progress Telerik

[Ofer]

Hi Peter

Thank you for the detailed response. I've actually already gone the way of your suggestion to prevent issues with displaying text when positioned at the edges (Right align when near the left most value, Left aligned when near the right most). Fixes the issue mostly, but I also use a Shape indicator (a circle) and it gets clipped either way. A fix to the Padding (that will reduce the size of the axis but won't clip the Indicator) will fix the issue since i'll just figure out how much padding I need according to the indicators i'll use.

Regarding the scenario i'm implementing... I'm using the HorizontalGauge as an interactive Slider (Since Xamarin's Slider does not display Labels, Ticks or Ranges and does not look and behave exactly the same across iOS/Android/UWP when it comes to tapping and dragging the thumb/indicator). 

Got it working almost flawlessly (Tap axis to animate to a new value, drag indicator support + snap to ticks after release), only some minor issues with calculating the precise location of the Indicator (due to the Axis being resized if labels with long text are used, and I don't have access to the axis width or to the Indicator's actual X position inside the control) but I was able to mostly work around it by estimating those values.

By the way, any plans to implement support for MultiPath shape indicators? maybe even Image indicators? 

 

[Petar Marchev]

Hi Ofer,

1. A fix to the Padding (that will reduce the size of the axis but won't clip the Indicator) will fix the issue

I regret to say that it will not. The meaning of Padding is such that it shouldn't allow for content to be rendered in the padded area. I made a simple image to try and explain why the Padding will start to work properly, but gauge elements may still get clipped. Check out the padding_explained.png

Here you can see that the control is quite large (black bounds). The Padding is marked with green arrows. The intention of the padding is for this area to be empty, with no things in it, so that items on screen can be presented clearly. The padding is intended to be on the inside of the control as opposed to the Margin which is empty space outside of the bounds of the control. The blue rectangle denotes where the skia canvas is. The skia canvas is what we use to draw the gauge elements in. It is a SkiaSharp element and it is not possible to draw outside of its bounds. So if you were to add a large annotation at the 0 value, it will get clipped just as before.

The fix about the Padding is related only to the position of the annotation, where you had noticed that it goes misplaced.

2. any plans to implement support for MultiPath shape indicators? maybe even Image indicators?

I am a little unsure what the question here is. The gauge has a shape indicator which uses a geometry, and not a RadPath. Do you mean that you could use an indicator that somehow uses a RadMultiPath?

Note that the gauge does not work with a RadPath directly, because there would be incompatibilities and the gauge wouldn't be able to respect all path's settings. Similar situation with MultiPath I suppose. However, perhaps a templated indicator can help? This way you can put anything in the template. If this is what you need, then we can log a feature request for this.

Back to the Padding - what you describe to need is not a padding feature, but some indentation feature that would allow you to override the gauge's desired indentations and set your custom ones (left and right). However, this is a feature we do not have at the moment and what we can do right now is to create a feature request for this, and you can wait for it to get planned and then implemented. But this may take some time.

Perhaps you are struggling with implementing a slider as we did not intend for the gauge to be used in such a way. Have you considered implementing the slider via SkiaSharp directly? This way you will have full control of what is drawn and you will not have to approximate positions. You can also directly handle touch events thus preventing any touch issues that may arise by using our gauge, because again, we did not intend for the gauge to be used in such a way.

Let me know if you need more information.

Regards,
Petar Marchev
Progress Telerik

[Ofer]

Hi Petar

1) I was hopping the Padding is implemented as part of the drawing logic (inside the canvas), not just a way decrease the size of the canvas in relation to the control, but I understand the constraints you mentioned.

2) Yeah I meant RadMultiPath. Wanted to give the shape indicator multiple fill colors, I don't see how it is possible in the current implementation. Not sure what you mean by templated indicator? 

"Indentation" of the axis (to free up space around it for indicators) is a good solution, please add a feature request for that.

 

Regarding implementing a slider - Well, the documentation for RadGauge actually specifically mentions "Interactivity" - "The Gauges for Xamarin do not only display values to the end-user, but also allow for controlling these values by a swipe gesture" (Documentation) though the icon below indicates only iOS so not implemented for the Xamarin.Forms control. Obviously I can create a Slider for scratch, but using RadGauge already supplied me with a big base of features (various axis, rangers, ticks and animations) and I already got it working as a Slider in iOS, Android and UWP so i'm actually quite happy with the result. The clipping at the ends is not critical, just wanted to make sure if there is a way for me to fix that... Still, it would be nice if eventually Interactivity will be added to all implementations of the control.

 

[Petar Marchev]

Hello,

1. give the shape indicator multiple fill colors

At the moment you can achieve this by using multiple indicators - one indicator for each color you need. Unless only fill and stroke are required, in which case the shape indicator will do.

2. Not sure what you mean by templated indicator?

By a templated indicator I mean an indicator that has a Template property of type DataTemplate. This way one can plug anything in the data template and the gauge will just create a view from this template and use it.

3. "Indentation" of the axis (to free up space around it for indicators) is a good solution, please add a feature request for that.

I just logged this in the public portal where you can vote and track its status. I have also updated your Telerik points as a thank you for your suggestion on how to make our products better.

4. RadGauge actually specifically mentions "Interactivity"

I have to admit that this is confusing. We actually have 3 separate implementations of gauges in the 3 platforms we support (ios, android, uwp). These may support touch interactions but the Xamarin.Forms gauge that you use does not use the native implementations. Instead, we use a 4th implementation where we use SkiaSharp for rendering. So the XF gauges are implemented in XF via skia sharp.This does not necessarily mean that touch interactions are impossible, but rather that they do not come with built-in support. So you may need to implement some things on your own and may have to tackle by yourself any issues that arise.

So this page you mention needs fixing and I already reported it.

I hope I was able to address all of your questions and concerns. Let me know if I missed something or if you need any other information.

Regards,
Petar Marchev
Progress Telerik

[Ofer]

Thanks Petar for all the information.

2) That would be a nice feature to have as I also plan on using images as indicators.

4) Odd. I'll continue using the XF gauge since the documentation for the iOS/Android native wrappers does not even mention interactivity (also both implementations seem to be feature poor compared to the XF one) and the UWP documentation for native wrappers is missing altogether. 

 

[Petar Marchev]

Hello,

I just created a feature request on your behalf in the public feedback portal where you can vote and track its status. Let us know if you have other questions.

Regards,
Petar Marchev
Progress Telerik