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.
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.
Minimalistic Text is almost 10 years old. The first commit to the repository happened on 7th 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.
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.
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).
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.
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?
Having the perfect machine for development and also for stuff I’m doing besides development (Web browsing, online banking, Netflix, …) is always a thing I strive for. As most of you will do. A special thing about the “dev machine” (and also about my mobile phone) is something that is very hard to explain, but I will try nevertheless.
The social factor
I always try to have a setup that is achievable by “normal” people. Being gifted with a hobby that I’m quite good at that I can do as a full time job and is also payed very well I can afford almost any setup (dev machine, mobile phone, infrastructure) that I want to have. But I always try to find the best setup that is not dependent on having much money to spare still considering things that are important to me like privacy and robustness.
This is my nth attempt to start something like a blog. The last attempts all ended with me not writing anything. This time I try to force myself to do so every week.
Regarding topics here I think you can expect mainly software development related stuff. Embedded SW development (If this can be called like that nowadays), .NET stuff, Android development and whatever is engaging me currently.
My name is Michael Lamers (also known as Devmil in the internets) and I work for B/S/H/, a Bosch company creating household appliances of different brands. The most known ones are Bosch, Siemens, Neff, Thermador and Gaggenau. My job is defining the SW architecture of the UI software in those appliances. I also work in the UI Framework team providing all those UI projects a basis to create their UI software on. As a technology stack we use C++ and Qt but even after 10 years of doing C++ I still don’t like that language. It is messy, error prone and leads to very long development cycles (change - build - test - repeat takes really long) So a hobby of mine is to look out for alternatives that we might be able to use at work.
We recently moved to Linux as operating system which opened a huge door for alternative technology stacks. At our current stage we are still very limited in hardware resources so currently most of the alternatives have no chance because of the size of the compiled binary + the framework needed to run it.
