MAUI horror

Henk wrote:

O wait you cannot run blazor on windows I suppose.

I could be wrong, but I would have thought you could.

TheSelfImprover wrote:

Henk wrote:

O wait you cannot run blazor on windows I suppose.

I could be wrong, but I would have thought you could.

I mean I don't like it if I have to use [slow] webbrowser with all kinds of features that are a burden for simple development.

Looks like it works. But only for windows. But currently I am only focussed on windows.

Code:

void OnDragOver(object sender, DragEventArgs e)
{
#if WINDOWS
    var dragUI = e.PlatformArgs.DragEventArgs.DragUIOverride;
    dragUI.IsCaptionVisible = false;
    dragUI.IsGlyphVisible = false;
#endif

No strange [copy] messages anymore when dragging the images

Hardly anybody using MAUI in Holland. But some use WPF XAML. Mostly they use Angular, VUE, React. I even don't know what that is.

I managed to add an evaluation bar to a chess board and an option to set multipv for stockfish. But still looking bit clumsy. Also need to simplify the code. Making it work is just one step. I can't click on a variation and letting it show on a chessboard and many more features still missing.

My database skills are still minimal. Even don't know how to make a database back-up without wasting gigabytes. Probably don't need a database at all. Only a file. Or store games in the database instead of files? Too much I think. Files is enough. Or maybe for looking up games. Better not use persistent memory at all but users are lazy.

Henk wrote:

Hardly anybody using MAUI in Holland. But some use WPF XAML. Mostly they use Angular, VUE, React. I even don't know what that is.

I managed to add an evaluation bar to a chess board and an option to set multipv for stockfish. But still looking bit clumsy. Also need to simplify the code. Making it work is just one step. I can't click on a variation and letting it show on a chessboard and many more features still missing.

My database skills are still minimal. Even don't know how to make a database back-up without wasting gigabytes. Probably don't need a database at all. Only a file. Or store games in the database instead of files? Too much I think. Files is enough. Or maybe for looking up games. Better not use persistent memory at all but users are lazy.

I clearly remember when Xamarin was launched in 2011, the team I was working with at the time was full of enthusiasm: finally - a good UI framework that could be used on any platform (Windows, Android, iOS, browser). Unfortunately, it proved to be a very poor framework that was difficult to develop in. Also, Microsoft made big changes between versions, which is always a pain for companies using it (to be fair, Google did the same thing with Angular). By the time it's replacement, MAUI, was launched, I think Microsoft had already missed the bus - there were already a lot of well-established alternatives by then.

Let's take a very quick look at some alternatives:

* Blazor. Build applications that use WASM (web assembly), and hence run programs close to native compiled code speed in a web browser. I think this is a really good way to make high speed browser applications, and you can program the whole thing  in good languages like C# - entirely without JavaScript. Yay!

Not sure how good it is for native apps (Windows, Linux, Android, iOS)

* Flutter. Build applications for any environment. Built applications are small and fast - yay! Programming language is Dart, and this probably makes it less popular than it really ought to be (but it's still big).

* Angular. Uses TypeScript, which is a superset of JavaScript, and gives JavaScript objects and classes. Good for employment - it's a popular choice. Despite generally being a supporter of Google, I personally strongly dislike Angular: I find the separation between the UI and the back end to be poor. Also, I know the kids (new developers fresh out of school) love it, but having been developing for a long time, I dislike the way projects have to be built - it feels really primitive to me. Also, as an experienced developer, the whole concept seems horrifically backward to me - Blazor and Flutter seem much more sensible in this regard. I acknowledge, though, that once you know what you're doing, you can build good web pages quickly with it.

* VUE.js and React.js . These are JavaScript frameworks for building web UIs with (you can build native apps with them as well). I personally think that this is a backward way of doing things, but it worked because there were a lot of web page developers around, and these two frameworks enabled them to use skills that they already had.  I am going to compare the two of them against each other:

- React is the better of the two for jobs: large number of companies using React

- VUE is the easier to learn and build your first app in

- React requires huge libraries, resulting in very large app sizes. Personally, this annoys me: large apps use a lot of your phone's available resources, for example. Facebook's apps are written in React (they're the company that developed the framework), and it explains why people complain that Facebook apps are a major resource hog on the phone. The reason for this is that React is, at heart, a framework that reproduces browser functionality inside your app (using a JavaScript library!), so that you can build your app as though you were building a web page

- React is easier than VUE to create a phone app with

- VUE and React have a lot of similarity, so one option is to learn VUE first, and then move on to React

Regarding the database question: if the amount of data you want to store isn't large, I would use a data format designed for text files like XML or Json: there are plenty of libraries around for these two data formats, and JavaScript can handle Json natively (though not as nicely as an object oriented language).

Blazor makes it dependent on a browser and browser doing too much. So not efficient compared to running it on windows.

I remember running a timer on a browser but when I clicked on the right mouse button timer was not displaying right information anymore etc. So you have to disable a lot to prevent user doing that. My knowledge of browsers very limited by the way.

So no browsers only windows. But then why not develop with WPF. I don't remember. Maybe go back to WPF and see what were the disadvantages but MAUI similar. XAML.

Maybe if you decide later to make it also run in a browser then that would be easier with MAUI. But you can't run stockfish on a browser. So that would be a webApp or microservices. Always the same problems no matter what direction you go.

As always one should keep it simple.

Henk wrote:

I remember running a timer on a browser but when I clicked on the right mouse button timer was not displaying right information anymore etc. So you have to disable a lot to prevent user doing that. My knowledge of browsers very limited by the way.

This is a complete guess, but maybe your clock was based on timeouts or promises? As well as those, you should also keep the actual time that the event was timing from, so that the clock can correct itself when it is triggered (and not just add a second to the previous time).

However, there was always a big problem with the "event-driven programming" paradigm: events could be triggered by other events, and you ended up with a chaotic "event spaghetti". I was a big supporter of MVC for this reason: clear that event spaghetti away. And of course, what did my fellow developers do when working in MVC? Wrote a load of event handling code in JavaScript instead of using what MVC offered.

Why?

Because of course they bloody well did!

This is a fundamental problem with developers: they work the way that they're used to instead of keeping to the philosophy of the framework that they're in.

Henk wrote:

So no browsers only windows. But then why not develop with WPF. I don't remember. Maybe go back to WPF and see what were the disadvantages but MAUI similar. XAML.

Maybe if you decide later to make it also run in a browser then that would be easier with MAUI. But you can't run stockfish on a browser. So that would be a webApp or microservices. Always the same problems no matter what direction you go.

As always one should keep it simple.

It's a strange world we live in in which writing GUI apps gets more difficult instead of easier.

Lotus Notes was the best tool for creating business applications I have ever used. Not by a small margin, but by an order of magnitude. When I tell you that it was 5 to 10 times faster to create an application in Notes, you will think that I am exaggerating.

I am not.

However, Notes dropped out of use: businesses saw web applications, and decided that they were no longer willing to pay for a Lotus Notes client on every user's PC (to be fair, the client was both expensive and a resource hog). But I cannot emphasise strongly enough how valuable it was to be able to produce business applications really quickly and easily.

The next easiest way I remember to build business applications was Windows Forms. Nowhere near as quick and easy as Notes - but reasonable. Windows forms applications, needless to say, run under Windows.

Now we live in a world in which business applications are expected to be in a browser. To this day, I still find it frustrating how much work has to be done to create a simple application.

In the early days, some of the pain was eased by PHP, and a .NET equivalent, in which server side code was inserted in among the HTML page. Changes to the web page were handled by managed callbacks to the server. Google ruined this by making all their web apps super responsive. They achieved this by handling as much as possible from JavaScript (which runs in the browser), and making callbacks to the server from JavaScript when needed. When businesses saw how responsive web apps could be, they all then expected their own developers to make their web apps this responsive.

Maybe LLMs are a solution? They'll hopefully be able to do a lot of the work that's needed to build the apps that people expect now.

btw, if you're not already doing so, you should try using Gemini or ChatGPT to help you with your development work.

Another remedy is to use low code or no code frameworks: this is most easily understood as making heavy use of pre-built templates - so you're not going to be making a chess engine this way (unless you take an existing open-source engine and modify it instead of writing it yourself).

TheSelfImprover wrote:

Henk wrote:

I remember running a timer on a browser but when I clicked on the right mouse button timer was not displaying right information anymore etc. So you have to disable a lot to prevent user doing that. My knowledge of browsers very limited by the way.

This is a complete guess, but maybe your clock was based on timeouts or promises? As well as those, you should also keep the actual time that the event was timing from, so that the clock can correct itself when it is triggered (and not just add a second to the previous time).

However, there was always a big problem with the "event-driven programming" paradigm: events could be triggered by other events, and you ended up with a chaotic "event spaghetti". I was a big supporter of MVC for this reason: clear that event spaghetti away. And of course, what did my fellow developers do when working in MVC? Wrote a load of event handling code in JavaScript instead of using what MVC offered.

Why?

Because of course they bloody well did!

This is a fundamental problem with developers: they work the way that they're used to instead of keeping to the philosophy of the framework that they're in.

Yes for instance I still think that if I write non-objectoriented functional code I am more productive. But not sure. They say classes give more stable structure. Maybe I have problems because I am not used to event-driven development. When things become to difficult I used to use dataflow charts. Never failed. But with classes you have to distribute the functions or dataflow over the classes as well. Adding extra complexity. O wait wait is the difference between classes and files. Yes the state of an object.

I even don't know the basics of MAUI or i forget too easily nowadays. Also not used to MVVM. I used MVC for some time but not for many years. Already console apllications without databases can be difficult when you use complicated mathematics.

Henk wrote:

Yes for instance I still think that if I write non-objectoriented functional code I am more productive. But not sure. They say classes give  more stable structure. Maybe I have problems because I am not used to event-driven development. When things become to difficult I used to use dataflow charts. Never failed. But with classes you have to distribute the functions or dataflow over the classes as well. Adding extra complexity. O wait wait is the difference between classes and files. Yes the state of an object.

For me personally, clarity and maintainability are everything, and I am an advocate of classes because they can make things clear and simple (good words to live by: "clear and simple").

Regarding dataflow charts, or any other type of diagram: there's a free ChatGPT extension (yes - ChatGPT now has extensions!) for drawing diagrams that I really like (screenshot below):



I include the screenshot because there are several diagram extensions - but I strongly recommend this one in particular. The other ones produce technically better quality diagrams, but this one is just ridiculously easy to use: you just describe the diagram you want using nothing but words, and it goes ahead and draws it for you. Just exactly what you'd want from a ChatGPT diagram extension!!!

Of course, if you prefer to draw the diagram yourself, then this probably isn't for you.

Henk wrote:

I even don't know the basics of MAUI or i forget too easily nowadays. Also not used to MVVM. I used MVC for some time but not for many years. Already console applications without databases can be difficult when you use complicated mathematics.

The purpose of MAUI is to give you multi-platform development using a single .NET framework. IMO, if MS had brought it out sooner (instead of Xamarin - which was supposed to do this job, but which was just awful), it would have been a huge success. I still think that .NET is a really good development environment - but our numbers are dwindling now. The impression I get is that the kids see Microsoft-world development the same way that we saw IBM mainframe development when we were kids.

Another thing everyone (except myself, of course!) does with MVC: instead of building a structured class for the view model, they just throw all the data for the view into the viewbag in a haphazard fashion. I understand why Microsoft added the viewbag to the framework - but, of course, once it's there, good MVC practice gets abandoned in a heartbeat. Seeing how humans behave, it's a wonder that it's even possible for us to communicate!

Probably nobody knows what data flow charts are. It is different from flow charts (only or mainly) focussing on data.

By the way I don't feel comfortable with multi-threading. One thread already complicated enough. In c# you use lock(object). I stupidly copy the pattern without thinking.

Looks like everything has to run asynchronously in user interfaces. Also adding complexity.

Maui uses dictionary. Same as viewbag perhaps. Don't even know how to add multiple viewmodels to a page. Probably making no sense. I go to chatgpt. to ask more stupid questions.

A dataflow chart, also known as a Data Flow Diagram (DFD), is a graphical representation that depicts the flow of data within a system, illustrating how input data is transformed into output data through a series of processes. It is a tool commonly used in systems analysis and design to visualize how data moves through an information system.

In .NET MAUI, the typical approach is to use a single ViewModel for a page, following the MVVM (Model-View-ViewModel) design pattern. However, there are scenarios where you might want to use multiple ViewModels for a single page. This can be achieved by either creating a composite ViewModel that contains multiple sub-ViewModels or by setting multiple BindingContexts for different parts of the page.

Henk wrote:

Probably nobody knows what data flow charts are. It is different from flow charts (only or mainly) focussing on data.

By the way I don't feel comfortable with multi-threading. One thread already complicated enough. In c# you use lock(object). I stupidly copy the pattern without thinking.

Looks like everything has to run asynchronously in user interfaces. Also adding complexity.

I understand your reticence with multi-threading: if you're not careful, everything goes wrong!

If you're aspiring to write a chess engine that competes with the best, though, you will need multi-threading unfortunately.

Henk wrote:

Maui uses dictionary. Same as viewbag perhaps. Don't even know how to add multiple viewmodels to a page. Probably making no sense. I go to chatgpt. to ask more stupid questions.

I cannot speak for MAUI, but in MVC there is only one ViewModel per view. However, you could have multiple classes within that ViewModel - if only by having a ViewModel class that contains instances of multiple classes! There may be other ways, but I'm not going to search that one right now.

Henk wrote:

...In .NET MAUI, the typical approach is to use a single ViewModel for a page, following the MVVM (Model-View-ViewModel) design pattern. However, there are scenarios where you might want to use multiple ViewModels for a single page. This can be achieved by either creating a composite ViewModel that contains multiple sub-ViewModels or by setting multiple BindingContexts for different parts of the page.

Yes - that's more or less what I said in the previous post (but you said it first, of course!).

I think you'd be able to do data flows using the ChatGPT extension I suggested. It comes down to preference - whether you like to draw it yourself or describe it and have ChatGPT draw it. I am in the second group.

TheSelfImprover wrote:

Henk wrote:

Probably nobody knows what data flow charts are. It is different from flow charts (only or mainly) focussing on data.

By the way I don't feel comfortable with multi-threading. One thread already complicated enough. In c# you use lock(object). I stupidly copy the pattern without thinking.

Looks like everything has to run asynchronously in user interfaces. Also adding complexity.

I understand your reticence with multi-threading: if you're not careful, everything goes wrong!

If you're aspiring to write a chess engine that competes with the best, though, you will need multi-threading unfortunately.

In the past my computer got overheated.  So of course I want to prevent that:

"To prevent overheating: Reduce the Number of Threads: If your application supports it, reduce the number of threads it uses. This can lower the workload on the CPU."

O wait I called stockfish asyncronously so thats why multipv option went wrong. Not sure. So that is why I had to create a thread safe singleton to make it work. Probably this trap will cause more bugs. Ugly solution.

Code:

   public void StartAnalysisAsync()
   {

      Task.Run(StartAnalysis);
   }

   public void StartAnalysis()
   {
      StockfishOutput = "";
      OnPropertyChanged(nameof(StockfishOutput));
      var position = Game.ChessBoard;
      string fen = position.ConvertToFen(Game.MoveNumber);
      stockfishAnalyzer.StartAnalysis(fen, OptionsViewModel.Instance.MultiPV);
           cancellationTokenSource = new CancellationTokenSource();
      try
      {
         while (!cancellationTokenSource.Token.IsCancellationRequested)
         {
            var nextLine = stockfishAnalyzer.NextLine();
            if (nextLine == null) break;

            var analysisLine = ParseStockFishLine(nextLine);
            if (analysisLine != null)
            {
               ProgressBarValue = 0.5 + analysisLine.Value / 1000;
               OnPropertyChanged(nameof(ProgressBarValue));

               PV = analysisLine.PV;
               Value = analysisLine.Value;
               StockfishOutput = analysisLine + "\n" + StockfishOutput;
               OnPropertyChanged(nameof(StockfishOutput));
            }
         }
      }
      catch (OperationCanceledException)
      {
      
         // Handle the cancellation
      }
   }

Better re-start talking to chatgpt. When available.

Using html is no option for it only runs in a complex browser. Best to use (webapp or webservices or microservices) but no browser. Or browser must be minimal. Unless you know everything about browsers and you have a fast computer as well.

So what is left over is XAML or what did we use in the past.

This all fails when users don't want to download applications but only want to visit websites with their browsers.

Henk wrote:

Using html is no option for it only runs in a complex browser. Best to use (webapp or webservices or microservices) but no browser. Or browser must be minimal. Unless you know everything about browsers and you have a fast computer as well.

So what is left over is XAML or what did we use in the past.

This all fails when users don't want to download applications but only want to visit websites with their browsers.

Good discussion about MAUI here. Summary: not good at all.


Blazor would be a good option for a chess app in the Browser, because it uses WASM (web assembly), which runs almost as quickly as native code. Chess.com use WASM for their chess analysis and bots (they might not use Blazor though). Developers seem to like Blazor - in contrast to Xamarin and everything derived from it (MAUI). When I used Blazor, I liked it a lot.

It's a shame MS have failed to create a good framework for the multi-platform world.

You can run Blazor only in a Browser. I had problems with developing software in Browsers in the past and will still have. Best to run applications disconnected as much as possible.