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.
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.
So I decided to got some steps back, make a fork and try a completely different approach.
I wanted to use Xamarin Forms as it is cross platform as Qt but allows full control over the native experience where needed.
It also uses the native controls in the back so for the OS it is not only a Canvas where the application draws something. This means easier integration in things like accessibility and uses the look&feel of the underlying OS (which is a good thing)
Using Xamarin.Forms also allows to remove that Console Host layer completely because Qt has been the only reason to do this (some weird C++ library in .Net issue that leads to a crash when using forkpty). So I got another step back and reworked the complete backend.
I ported the frontend part to Xamarin.Forms (with some problems like input handling) and got it working. I basically used SkiaSharp to draw the terminal content and Xamarin.Forms to host it.
This took some evenings to finally work on MacOS and Linux and then I started thinking about “how to create a package?”.
This is a no-brainer for MacOS. It is easy to create a MacOS app bundle with Xamarin. The problem is Linux and for a more detailed reasoning I have to go a step deeper:
Xamarin uses Mono as a Framework. With Qt I have used DotNet Core. Even if Microsoft managed to harmonize the API surface and we can have .Net Standard libraries that work in Mono and DotNet Core there are still extreme differences when it comes to building.
With Qt and DotNet Core I simply used the DotNet Core capabilities to cross compile for Linux and packaging everything together in one executable. This was copy-deployable to all my Ubuntu test instances and worked right away.
There is no such thing with Mono. I can’t switch to DotNet core because Xamarin only works with Mono. So I tried different ways to create a package that runs on any Linux (or at least Ubuntu) out there without any luck yet:
- I tried Snap packages but didn’t manage to create a snap package that also contains Mono and launches my application. I invested an huge amount of time searching through the internet and trying out different approaches - non of them worked.
- AppImage: There seems to be a way that works Someone in the internet managed to package a mono application with it but needs a deep dive there
- creating Debian packages. The “Linux” way. Yes but No. I will not create debian packages for all those distributions out there. This is not right 😁
Then I have read that Xamarin will be based on DotNet Core in the future (DotNet 6) wich could eliminate my pain completely. Besides the little fact that Microsoft doesn’t include Linux Support and is relying on the community to do that :/ Let’s see if and when we can see progress there.
Nevertheless it doesn’t feel like the right thing to now invest time to get that Mono thing running when there is a solution to all this already in sight!
This is why I put the Terminal project back in the drawer and I plan to pull it back out when DotNet 6 is here.