Enums in Dart are worth an extension

Note! Time has moved on and in the meantime Dart has capabilities that make this post obsolete. You can read about the new features here

Dart is a relatively simple programming language.
In general this is a good thing as the number of possibilities and patterns you have to know in order to develop something with it or when reading code is lower.
On the other hand you will miss certain features that other programming languages have that can lead to quite elegant solutions for certain problems.

Enums int Dart are such a case.

Enums are very simple in Dart. In general, they are classes / objects like everything else, but you can’t do neat tricks with them like for example with C#.

Let’s assume we have a byte value and want to read some bits of it. Those bits should have names (mapped to an enum) for better understandability.

Enums in C#

In C# there is a language feature for exactly that. You can use any enum to represent bits in a bit field.

[Flags]
public enum FlagValues : byte
{
    None    = 0x00,
    Flag1 = 0x01 << 0,
    Flag2 = 0x01 << 1,
    Flag3 = 0x01 << 2,
    Flag4 = 0x01 << 3,
    Option4 = 0x01 << 4,
    All = 0xFF
};

// later in the code

byte val = 0x05; //00000101

var flags = (FlagValues) val;
flags.HasFlag(FlagValues.Flag1); // true
flags.HasFlag(FlagValues.Flag2); // false
flags.HasFlag(FlagValues.Flag3); // true
flags.HasFlag(FlagValues.Flag4); // false

You can even do bitwise operations directly with the enum like

Dart Isolates and huge amounts of data

Why?

I’m currently experimenting with Dart and Flutter to take another shot at the terminal emulation application. This time not using C# but something completely new.
For this I decided to take a look at Flutter and Dart and try to implement the terminal application using that technology.
Gladly there is already a person in the internet that is working on implementing the xterm protocol for Dart and also has a working Flutter UI that renders the terminal.
https://github.com/TerminalStudio/xterm.dart
This implementation is not yet finished and has a couple of problems but is a really good starting point to dig into a Dart and Flutter based development of a terminal application.
One “problem” of the solution is that the whole terminal logic happens in the UI thread. So I wanted to move that logic into a separate thread and only copy the UI state to the UI thread for the UI to show it.
I did this for the C# based approaches and it speeded up the performance (especially reflow) a lot.

Current state

I know, I know. I planned to do this much more frequently as it then happened. I will do my best to keep you updated with anything of interest here.
There has not been so much going on in terms of development or side projects mostly because the Terminal application project got stale and there no all-focus new side project yet.

I started reviewing my small Smart Home setup I have here and see where I can improve things. When this gets more concrete it might also be worth on or two blog posts.

Current state of the Terminal application

The Terminal application got a bit stale due to several reasons.
Starting point of all that was me starting to think about the UI for the additional features. Things like managing different profiles as a starting point.
I played around with a couple of ideas and did some prototypes and I didn’t like anyone of them. Not so much because of the UX they used but the design.
I basically faced the standard problem of cross platform UI development. Qt can have styles - yes - but you will never reach a state where the application feels “natural” on any platform. I think this is especially visible on MacOS as a MacOS user is not very used to seeing all different kind of visual approaches between different applications.
This topic blocked me from continuing because I can not see how I will end up with a Qt/Qml based solution that looks like a nice MacOS application. Even small things like using some blur effect that modern MacOs apps have would be a pain if at all possible.

Creating a terminal application - Frontend take 2

Recap

We remember that the current state of building the terminal application was creating the user interface. I tried to use HTML to do the formatting of the text which turned out to be way too slow.

So I had to find a different approach as I wanted to stick with QML and .Net (for the already mentioned reasons)

QML alternatives

In QML there are a few alternatives for getting a formatted text to the screen. We already had a look at the HTML approach.
Another approach is to create a QQuickPaintedItem. You can imagine that control to be a drawing surface inside your QML layout that then can use a QPainter and its drawing API to draw whatever it wants.

This works by deriving a class from QQuickPaintedItem, implement the paint method and use the passed QPainter instance to draw.
The paint method is called whenever the content has to be redrawn.
This new class then has to be registered as a QuickItem with the QmlEngine and can then be used like any other QuickItem in your layout.

At some point in time you have to let it go

Minimalistic Text is almost 10 years old. The first commit to the repository happened on 7^th of November 2010.

How it began

I did not expect to create something that will reach the number of people Minimalistic Text did. It was basically just a try to create something for my new Smartphone (a Samsung Galaxy S). I was inspired by an application that already existed and was able to show the time as spoken text as a widget.

Recreating that widget and extending it by a first level of customization was basically the starting point. I started a thread over at Xda-Developers and immediately received great feedback. That encouraged me to extend the app step by step till it was a really feature packed text widget creator.

Creating a terminal application - Frontend take 1

Intro

The last post has been a while back. Sorry for that. I was busy with daily business and also the implementation of the terminal got a bit stuck. Now I’m back on track and can feed you with the latest development news.

The backend is only half way towards a complete terminal application. In fact it’s more 1/5 of the way.
The reason to use a terminal application other than the built in one is only its user interface. At least for normal operating systems where the built in terminal works as expected.

So it’s all about user interface and functionality.

As already mentioned I want to take the C# + QML route as it is a good way to dog food Qml.Net and also gain some more QML / Qt insights that help me with my day job. Win-Win 😁

QML might not be the first choice when you need a UI that basically renders its main content all the time and also needs to be fairly fast in doing so. We don’t want to hold back the process we control with having it waiting for our UI to render.

Creating a terminal application - Backend

How Terminals work

Maybe not all of you know what goes on behind the scenes when you launch your Terminal.
The term “terminal” is from the 1970s (or even earlier) Wikipedia: Computer terminal. At this time you had a real terminal device that was built in a way so that the input/output part was separated from the computing part. There were different protocols used for those two parts to talk to each other.
A well known terminal has been the VT100 that introduces special escape codes to control e.g. the cursor or status lights.
The protocol used there is still what drives the Terminal of your operating system (at least the Unix based ones).

So given the history a terminal application today is still controlled using the same protocol by the process it talks to.
The terminal application is “only” handling user input and output. It connects to the underlying process (most of the time the default shell of your OS) via special pseudo terminal connections where it sends the user input to the shell process and receives the UI data from the shell process (using the protocol from the old days).

Creating a terminal application - Intro

History

From time to time I have to maintain servers, connect to Raspberries or access my Synology Diskstation. All this is done via SSH connections.
On Windows I loved to use an app called MobaXTerm for this. It has some really convenient features. From getting a glimpse into the system parameters of the remote machine (CPU load, RAM, storage, …) to having a X Server running and getting the SSH connection configured so that X-forwarding works flawlessly.
But the best feature is getting a parallel SCP connection that can follow your current directory and provides the possibility to edit files using local applications by managing copying it locally and re-uploading it after it changed under the hood.

MacOS situation

For MacOS I can’t find a terminal client that provides the same functionality. Of course, there are plenty of terminal applications and there are also programs that allow SCP connections but not everything in one package. Not the all in one SSH toolbox.

Why even consider switching from C++ for embedded UI SW development?

History

In the past, when the hardware was much more limited than today, the software for that hardware was a monolithic binary containing everything. The (embedded) OS, the drivers and the application itself.
The embedded operating systems evolved and introduced things like multi threading or something in the middle of threads and processes.
At that stage hardware resources were the biggest constraint so that switching from C to C++ was considered a crazy step. All those virtual tables that eat up RAM and ROM!
At that time the applications were rather simple. No complex UI flows or things like content that can be downloaded by the user.

Selecting the right MacBook

As the decision to buy a MacBook has settled the next step was to select what MacBook to buy.
Normally I like to have a notebook in the 13” range as it is portable and when used at home I always connect an external monitor to it.
My previous device was a Microsoft Surface Pro 6 so I was quite used to such a screen size and didn’t need to change it.

The keyboard

There is one problem with the MacBooks that was very prominent in the media: The butterfly keyboard seemed not to be the best decision Apple made. So it was clear to me: I don’t want to get a MacBook with a butterfly keyboard.
This ruled out all 13” Models before 2020 and all 15” models. So the available options were: 13” 2020 or 16” 2019.
The 2019 MacBook is roughly half a year old so it can be bought at some discount. The situation for a i7-10, 16GB RAM and 512GB storage device was that the 16” costs 100€ more than the 13”. I also noticed that the reviewers mentioned that the 16” has a redesigned cooling system that works much better than the old one and that the 13” sadly doesn’t have this improvement. Another thing that I’ve seen in the news is that the 13” has some USB 2.0 problems.
So I decided to go with the bigger device because it promised more power. Having a dedicated GPU can’t hurt, right?