Hi Team,

Please introduce a SignaturePad control to Telerik UI for Maui.

Manish

We have been developing our WPF app for some 4.5 years now and use the following controls from Telerik WPF UI control set:

• PropertyGrid
• GanttView
• TimeBar
• Diagrams
• Callout
• Transition
• Wizard
• TileList
• Docking
• Notify Icon
• Task Board

* Native User Authentication UI Control that leverages  CommunityToolkit/Graph-Controls

I don't see these UI Controls on the Roadmap for MAUI and that is okay; it just delays our timeline for MAUI adoption. As we aren't a UI Component Control software development company we are dependent on folks like Telerik. This is not a complaint as much as it is just a let you know what some of your customers are doing. We need to be to be on the macOS desktop but native macOS development is very expensive. As a start-up that company that builds native desktop apps this is big deal and our investor take note of such things.

MAUI could help to reduce our development cost but only if we can move to that platform with UI Function set we have in our WPF App and to leverage engineering IP artifacts and development resource.

Tavi

Hi Team,

I prefer C#, so I am looking for resources that are not using XAML. Can you please make a duplicate of all your demos and documentation mentions so that we can toggle between XAML and C#.

Thank you

Joesph

Changing the current culture of the application on the fly does not affect the UI components of the current page. Consider the following scenario: the user selects a preferred language from a list. The application changes the current culture dynamically on the fly:

CultureInfo.CurrentCulture = someCulture;
CultureInfo.CurrentUICulture = someCulture;

This does not update the UI of the current page in any way. All of the UI components are displayed with the language of the original culture. The only way to see them translated to the new language is to reload the entire page.

After updating our Maui application to Maui version 8.0.90, the Entry controls in the WinUI version stopped responding to WidthRequest, HorizontalOptions, or parent container sizes. I thought it was just a Maui problem, but in the relevant issue's notes, I saw that users were having trouble duplicating it unless Telerik UI for .NET Maui was installed (https://github.com/dotnet/maui/issues/24783).

So I created a test app that contains a few Entry controls in various containers:

<?xml version="1.0" encoding="utf-8"?>

<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             x:Class="WinUIEntryBug.MainPage">

    <ScrollView>
        <VerticalStackLayout
            Padding="30,0"
            Spacing="25">

            <Border>
                <Entry />
            </Border>

            <Grid>
                <Grid.ColumnDefinitions>
                    <ColumnDefinition Width="*" />
                </Grid.ColumnDefinitions>

                <Entry Grid.Column="0"></Entry>
            </Grid>

            <Frame>
                <Entry />
            </Frame>

            <Entry />
        </VerticalStackLayout>
    </ScrollView>

</ContentPage>

Without the Telerik components added to the project, the Entry boxes render correctly:

But, when I add a reference to Telerik UI for .NET Maui version 7.1.0 (latest at the time this was written), I get this:

Note: I didn't even add UseTelerik() to the Builder in the MauiProgram.cs, just added the Nuget package.

Changing the WidthRequest, HorizontalOptions, MinWidthRequest, etc. does not affect their size. They do render correctly in iOS and Android, though.

If I then remove the UI for .NET Maui Nuget package, they go back to working.

In our main application, we are heavily dependent on Telerik components and have a substantial number of customers using the Windows version of our application, so this heavily impacts our ability to ship. Particularly since the Maui 8.0.90 fixes other bugs that we needed addressed.

I've attached my sample project with the Telerik UI for .NET Maui package installed. You can remove it to see the normal operation of the Entry boxes.

Hi Team,

Currently, Telerik UI for MAUI works implicitly with the standard MSIX packaged WinUI 3 app. However, if I manually bypass that and use msbuild to build an unpackaged, self-contained exe, some of the resources are not embedded.

This feature request is for UI for MAUI to implicitly support unpackaged apps without the developer needing to do anything for the destination environment (fonts, etc.)

Hi Team,

Although UI for MAUI does not have a Calendar/Scheduler control... you're still forcing us to declare a NSCaldendarsUsage permission in info.plist because of some old code inside the native iOS static library inherited from UI for Xamarin.

I have some requests/comments for you:

• Please remove this from the native iOS static library, there is no use for it at the moment.
  
• If you plan on bringing the old Xamarin Calendar to the MAUI with the new handler architecture; please split up the iOS libraries so that the Calendar's use of this API can be linked out during compilation.
• If you are going to build a new calendar/scheduler using modern MAUI layers; please allow non-Calendar consumers to not require any permissions that Calendar may need.

I do understand that if I'm not using the Calendar in my app, the user will not be explicitly asked to approve permissions. However, this is unacceptable excuse because my org's application only uses the RadListView, but we still have to show that the calendar is a potential access point in the permissions manifest.  In the world of security conscious users and enterprise security audits, this explanation is tiresome to hold up.

We've known about this problem for many years, and hopefully .NET MAUI can be a fresh break away from the headaches of Xamarin.

Thank you for your time and consideration,

Gerard

Currently for all controls I have to have a separate control for the label of the control.  Its annoying.

It would be nice if each of your controls had a Header property and a Control Template property that allows automatic layout of the Header in relationship to the control

So

Enter Name

_______________

It would be one control not currently 2.

In addition if the control layout would allow for something like material layout that would be a huge bonus - see below how the Note in the input field moves to the top of the layout.

Hi,

Do you have on your roadmap to include a Shimmer View / Control as part of your .NET MAUI offerings to tidy up a screen loading indication.

From a UI/UX perspective, a shimmer sits better with our user community rather than a loading indicator.

Thank you,

Shane

This was a regression when I upgraded to 7.1.0. 

Before, when the editor was empty and had a height set, you could tap anywhere to start editing.  Now, I can only start editing by tapping the top of the editor.

I tested this only on Android.