Feature proposal: Gauge Control

[ElectroAttacks]

Pull request type

Please check the type of change your PR introduces:

• Update
• Bugfix
• Feature
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Build related changes
• Documentation content changes

What is the current behavior?

Issue Number: N/A

What is the new behavior?

• Added a new control ('Gauge') for displaying values with a range
• Added a default style that's using theme colors for the bar, foreground and indicator color
• The arc and angle calculations are based on the arc control, with some small adjustments
• The control provides a content and header property within it's arc for customization
• Background (Bar) and Foreground (Indicator) arcs can be customized separately

Other information

[m0lDaViA]

@ElectroAttacks If you resize the control what does the gauge do? Does it resize correctly?

[ElectroAttacks]

@ElectroAttacks If you resize the control what does the gauge do? Does it resize correctly?

Well, the default template for the Gauge includes a Data binding that ensures symmetrical resizing.

If the control is resized it will be redrawn based on the new ___location and size, like a normal control will do.

The Arc control inherits from a shape, which can lead to weird behavior if you stack two of them and perform any resizing. That's one of the reasons the Gauge control is derived from the RangeBase class.

[m0lDaViA]

@ElectroAttacks Well the arc couldn't do that, at least in 2.1. That's why i'm asking.
@pomianowski What do you say?

[ElectroAttacks]

@ElectroAttacks Well the arc couldn't do that, at least in 2.1. That's why i'm asking.

@m0lDaViA This is exactly what I figured out. I reported that issue a few months ago and fixed it myself... I'm already working on splitting the logic of the Gauge control into a base class and two controls, so it will be structured like so:

• abstract class GaugeBase : RangeBase
• Gauge : GaugeBase
• Angular Gauge : GaugeBase

But that might take a while due to the complexity of the Angular Gauge. I want a kinda similar experience than the one in Livecharts 2...

For the Arc itself it might be easier to figure out why a size change does not affect render by default, maybe it would be enough to override it's MetaData to enable the redrawing...

[m0lDaViA]

@ElectroAttacks As i wanted to create a knob control myself i was thinking about fixing the arc.
So you fixed the arc but didn't commit? :D

[ElectroAttacks]

@ElectroAttacks As i wanted to create a knob control myself i was thinking about fixing the arc. So you fixed the arc but didn't commit? :D

@m0lDaViA Well, I had some ideas that might fix the issue where the arc is not being redrawn after a resize, if you are talking about that issue.
My Gauge control does not have any code that ensures a square shape, but it will always be redrawn completely when resizing.

[pomianowski]

I'm still not sure if these types of controls should be in the main package or if it would be better to create a new one, like Wpf.Ui.Diagrams or something like that

[ElectroAttacks]

I'm still not sure if these types of controls should be in the main package or if it would be better to create a new one, like Wpf.Ui.Diagrams or something like that

@pomianowski Well, yeah it would make maintenance a little bit easier... I would prefer Wpf.Ui.Graphs though.
There are quite a few controls missing for displaying data efficiently in WPF, for example Skiasharps Line diagrams are very dynamic and featurerich but are cpu bound. I wish I could make something like that using WPFs GPU Rendering, but that's a pretty large project and my coding skills will not meet the requirements to do so either...

[m0lDaViA]

@pomianowski
Doesn't it depend on what we want to achive? I mean basic controls like textboxes or shapes are clearly fine in Wpf.Ui but should we really add all kind of other controls to it? And if yes, in a seperated project?
And where does this control places? Or the arc control? Or should those controls be all outsourced to like Wpf.Ui.Controls?
Questions after questions.
For my part, I think Wpf.Ui.Controls is a good idea in itself but that's ultimately your decision.

[m0lDaViA]

@ElectroAttacks As i wanted to create a knob control myself i was thinking about fixing the arc. So you fixed the arc but didn't commit? :D

@m0lDaViA Well, I had some ideas that might fix the issue where the arc is not being redrawn after a resize, if you are talking about that issue. My Gauge control does not have any code that ensures a square shape, but it will always be redrawn completely when resizing.

For your information: the arc class does resize now correctly. Maybe you can work with that now?

[ElectroAttacks]

@m0lDaViA , @pomianowski The more controls I'm using the more bugs I find... For example if you're using the FontIcon control with a symbol font like Material Symbols (newer version of Material Icons) and try to set a font size, it won't be applied. You have to change it multiple times at runtime to change the font size.

The other bug I've found is that when you're actually using the attached property NavigationView.HeaderContent dynamically, it will not work as expected. Because by default the Header Content is updated without re - rendering. So you need to navigate back and forth multiple times to get the header content right, or, the way I fixed it for myself is using an IMessenger and bind to the VM.

It will be easier to maintain everything by removing controls like IconSource, FontIcon, FontIconSource etc., because you can simply use the default controls for that. Another thing that might save a lot of work would be changing the NavigationHeader/ Icon Properties to object type. This will make it more dynamic and user friendly...

[m0lDaViA]

The more controls I'm using the more bugs I find... For example if you're using the FontIcon control with a symbol font like Material Symbols (newer version of Material Icons) and try to set a font size, it won't be applied. You have to change it multiple times at runtime to change the font size.

You mean that?: #1067

The other bug I've found is that when you're actually using the attached property NavigationView.HeaderContent dynamically, it will not work as expected. Because by default the Header Content is updated without re - rendering. So you need to navigate back and forth multiple times to get the header content right, or, the way I fixed it for myself is using an IMessenger and bind to the VM.

In that case we need InvalidateVisual.

It will be easier to maintain everything by removing controls like IconSource, FontIcon, FontIconSource etc., because you can simply use the default controls for that. Another thing that might save a lot of work would be changing the NavigationHeader/ Icon Properties to object type. This will make it more dynamic and user friendly...

Well i don't know exactly why he wrote Icons the way he did. I mean FontIcon, SymbolIcon and ImageIcon are fine but why does it need like 20 separated classes for that all? It like the appearance part. There are way too many classes and methods spread across.
This only makes it harder. That's why i'm re-writing the theming right now. But that is a lot of stuff and need a long time.

[ElectroAttacks]

You mean that?: #1067
Actually no, I've not tested the markup extensions for the FontIcon yet. But if you would try changing the FontSize Property in Xaml you will realize what I mean. If you changed it at Design Time it will not be applied at runtime. If you change it at Runtime (either in XAML or Code behind) it will change.

For displaying a symbol font you can basically just use a Testblock or the ui:TextBlock. The only reason why the FontIcon exists is the constraints for the MenuItems... If we really need the constraint we could just add an common interface for SymbolIcon and TextBlock, otherwise I would change the MenuItems to have a Header and Footer Property of type object, so each user can decide himself.

The other bug I've found is that when you're actually using the attached property NavigationView.HeaderContent dynamically, it will not work as expected. Because by default the Header Content is updated without re - rendering. So you need to navigate back and forth multiple times to get the header content right, or, the way I fixed it for myself is using an IMessenger and bind to the VM.

In that case we need InvalidateVisual.

Actually I think it might be this part here:

public static readonly DependencyProperty FontSizeProperty = TextElement.FontSizeProperty.AddOwner(
    typeof(FontIcon),
    new FrameworkPropertyMetadata(
        SystemFonts.MessageFontSize,
        FrameworkPropertyMetadataOptions.Inherits,
        OnFontSizeChanged
    )
);

We are not inheriting from TextElement, so why are we adding an owner to it's FontSizeProperty? Doesn't make sense, right?
So the DP register call needs to be modified.

Well i don't know exactly why he wrote Icons the way he did. I mean FontIcon, SymbolIcon and ImageIcon are fine but why does it need like 20 separated classes for that all? It like the appearance part. There are way too many classes and methods spread across. This only makes it harder. That's why i'm re-writing the theming right now. But that is a lot of stuff and need a long time.

The SymbolIcon is fine, but ImageIcon and FontIcon are controls providing the same behavior as default XAML controls.
That's why I would prefer object type properties. It would make Styling way easier. Like the limited text size issues with navigationviewitems... Or am I missing something @m0lDaViA ?

[m0lDaViA]

@ElectroAttacks

The SymbolIcon is fine, but ImageIcon and FontIcon are controls providing the same behavior as default XAML controls.
That's why I would prefer object type properties.

I guess he did that so you can use SymbolIcons, FontIcons and Images as Icons.

Like the limited text size issues with navigationviewitems... Or am I missing something
I don't use navigationview, so i don't know what you mean. I would have to look into it.

Overall i think there are a lot of parts which need to be rewritten.
But at least the arc is working now :D
If you got discord and if you want, you can join his server and we can talk there more.

[ElectroAttacks]

@m0lDaViA

I guess he did that so you can use SymbolIcons, FontIcons and Images as Icons.

Yeah, that's basically what I was trying to say, but it will still be easier to use object and add an default style...

Overall i think there are a lot of parts which need to be rewritten. But at least the arc is working now :D If you got discord and if you want, you can join his server and we can talk there more.

Well, I would love to help you guys, there are some things I wanna fix myself, but I would discuss that first... Haha

[m0lDaViA]

@ElectroAttacks Then, hop on https://discord.gg/wrYuX59H