5 ms·

When I was using it, all documentation samples (and nearly all other resources) were for XAML which made it unnecessarily hard to use API in pure C#. IMO, UI d

When I was using it, all documentation samples (and nearly all other resources) were for XAML which made it unnecessarily hard to use API in pure C#. IMO, UI development tools are often not good for anybody. Designers are much more productive using specialized UI design applications like Sketch, Figma, Adobe XD etc. Who is responsible implementing the design depends on the company/workflow. > XAML is just a tool to allow you to describe UI API calls using XML in a way that flows well for both humans and external tooling. Not in my experience. XML feels very unnatural to me. XML being natural for humans was a hype from twenty years ago that was never particularly true in practice. XML feels less natural (to me) than using a normal programming language to make same API calls. XML based UI development tools are also often very unreliable and clumsy.

croes 5y ago
>specialized UI design applications Like Blend?
nyanpasu64 5y ago
Not the biggest fan of XML either. My primary objections against "simple" XML is repeating element names in open and close tags, the noise of <>, and (in the context of a UI tree) confusion over whether to put element modifiers as XML attributes (strings only) or nested elements (verbose, looks like an object rather than an attribute). And when you bring in namespaces, it gets more verbose and unreadable. I've actually managed to make "UI in code" somewhat manageable by laying out my UI code in a tree mirroring the widget tree. One issue is waiting for rebuilds, another is difficulty navigating the "big picture" of my code, mapping between on-screen UI and code mentally or through an Inspect Element equivalent. What do you think about QML?
- zigzag312 5y ago
  To manage mental mapping of what is being drawn, I keep methods that create widget trees short. My rule of thumb is that whole method has to comfortably fit the screen at once. For each section of the main tree I create a static function that returns a branch of the tree. These functions have descriptive names that help you visualize what element each function builds. If a tree inside a function is long, it is broken down in the same way. There are some fluent extensions (for Xamarin.Forms and probably future MAUI) that help you build UI in declarative fashion with C#. Same extensions could be created for other frameworks. https://devblogs.microsoft.com/xamarin/c-sharp-markup-for-xamarin-forms/ https://devblogs.microsoft.com/xamarin/c-sharp-markup-for-xa... https://github.com/VincentH-Net/CSharpForMarkup https://github.com/VincentH-Net/CSharpForMarkup For reusable custom widgets that can't be done with a static function, I create new classes with their own widget trees. Try to keep widgets composable and avoid inheritance if possible. Hot reload is coming in .NET 6, so waiting for rebuild will soon be history. I have no experience with QML so I can't really comment on that.

croes 5y ago

>specialized UI design applications Like Blend?

nyanpasu64 5y ago

Not the biggest fan of XML either. My primary objections against "simple" XML is repeating element names in open and close tags, the noise of <>, and (in the context of a UI tree) confusion over whether to put element modifiers as XML attributes (strings only) or nested elements (verbose, looks like an object rather than an attribute). And when you bring in namespaces, it gets more verbose and unreadable. I've actually managed to make "UI in code" somewhat manageable by laying out my UI code in a tree mirroring the widget tree. One issue is waiting for rebuilds, another is difficulty navigating the "big picture" of my code, mapping between on-screen UI and code mentally or through an Inspect Element equivalent. What do you think about QML?

zigzag312 5y ago
To manage mental mapping of what is being drawn, I keep methods that create widget trees short. My rule of thumb is that whole method has to comfortably fit the screen at once. For each section of the main tree I create a static function that returns a branch of the tree. These functions have descriptive names that help you visualize what element each function builds. If a tree inside a function is long, it is broken down in the same way. There are some fluent extensions (for Xamarin.Forms and probably future MAUI) that help you build UI in declarative fashion with C#. Same extensions could be created for other frameworks. https://devblogs.microsoft.com/xamarin/c-sharp-markup-for-xamarin-forms/ https://devblogs.microsoft.com/xamarin/c-sharp-markup-for-xa... https://github.com/VincentH-Net/CSharpForMarkup https://github.com/VincentH-Net/CSharpForMarkup For reusable custom widgets that can't be done with a static function, I create new classes with their own widget trees. Try to keep widgets composable and avoid inheritance if possible. Hot reload is coming in .NET 6, so waiting for rebuild will soon be history. I have no experience with QML so I can't really comment on that.