DEV Community: Mitch Stanley

Desktop GUIs for Web Developers

Mitch Stanley — Thu, 20 Jan 2022 19:48:33 +0000

This is a cross-post from website - check the original here 😀
Over the past few years I’ve become more interested in making desktop applications. For some context, I’m a web developer with around 15 years of experience. I mostly work with Laravel and Vue.JS but I have dabbled in a whole heap of other languages and frameworks.

I love a good desktop app and where possible I’ll generally prefer having an app rather than visiting a website. I’ve also had to turn websites into desktop apps at my job so I’ve explored a fair few different technologies for this purpose.

I’ve written this blog to share the desktop technologies that I'm currently interested in. Bear in mind, some of these tools I’ve built full apps with and some I’ve only gone through briefly with tutorials. I’ll make this clear throughout the article.

I hope to have given you an idea of what to look for when choosing a desktop application framework. Hint: There is no golden ticket, each tool has pros and cons. All I can give you is my experience with each of them and when you should consider them for your projects.

The tools I'll be reviewing are:

Compose Multiplatform
egui
Electron
- Ember Electron
- Quasar
Flutter
React Native for Windows
Tauri

What to look for in a GUI tool

There are almost as many GUI tools as there are frontend Javascript frameworks. So how do you pick one for the project you’re working on?

If you use a Javascript framework for the web, a good place to start is to see if there is a desktop counterpart for that library. For example, Quasar for Vue developers, React Native for React developers, Ember Electron for Ember developers and so on.

Two of the three mentioned above are Electron based tools and I think it’s worth pointing out, if you want something built fast with access to a large community, ecosystem and is regularly updated then Electron is absolutely worth investigating. It gets a lot of gripe because release builds have a large file size, it’s not as fast as native, and generally most apps don’t feel quite right, but these downsides can often be forgiven.

As with all of the tools that I mention below, you have to weigh up various concerns.

Who your application is for?—do the users care about it being a wrapper for a web application? Can the tool provide the functionality that your users expect?
How complex is the project likely to be?—are there frequent updates that need to be kept up to date with web/mobile counter-parts?
The size of the team working on the project—single developer or a large team? Trying to keep two code bases up to date (e.g. a website and a desktop app) for a single developer could literally half their productivity. Not so much of an issue for a small team.
How fast does it need to be built? Exploring new technology takes time and some tools are easier to grok than others, have larger communities to help, and have plugins to solve various problems.
Accessibility. Unless your making a personal project, you should try to add some level of accessibility to your application. The more the better, but not every tool makes this easy.

With those key points in mind, there are a few additional things to think about

What platforms do you want to build for? Not all tools work on every platform. For example, React Native does not build for Linux but does work on iOS and Android. SwiftUI does not build for Linux or WIndows, but the code can be shared with all of the Apple Ecosystem.
Distribution and updates. Do you want to distribute via Apple's App Store, the Microsoft Store? Linux has various options for automatic updates including Snaps and AppImages. For MacOS and Windows there’s also options for updates via your own server, or you could let user base to update manually.
Support. Is the library actively maintained and how often is it updated?
Should you choose boring technology? Small side projects can be a fun excuse to try a new stack, but if you're building a product for a company with customers reliant on stable software then you should probably pick something that’s been battle-tested.
Level of native integration. Native isn’t necessarily boolean value. You can use web based technologies for the core application but still support native APIs for window management, menu/tray support, storage, notifications, widgets and more. Electron for example, has great options for all of those features. Some of the newer/smaller libraries tend to fall short in this regard.

Finally, if you’re not familiar with a front end javascript library—maybe because you’re a backend developer—You might also want to look into libraries for programming languages that you’re familiar with. There are often wrappers for existing technologies like GTK, FLTK, Qt. For example, FLTK-rs for Rust, or the GTK3 gem for Ruby.

So, what’s out there?

Here comes the fun stuff. Obviously I can’t go through every single option available, but I will show you what has piqued my interest

Compose Multiplatform

Not to be confused with Jetpack Compose, the modern toolkit for building Android apps, JetBrains’ Compose Multiplatform is based on the same technology but allows you to build for Windows/MacOS, Linux and the web.

Compose uses Kotlin and my opinion, this language feels great. So far I’ve run through the Ray Wenderlich tutorial by Roberto Orgiu and I enjoyed the experience. However, there is a lack of resources available for learning it. This tutorial and the official docs and examples are the only things I've come across.

fun main() = Window(
  title = "Sunny Desk",
  size = IntSize(800, 700),
) {
  val repository = Repository(API_KEY)

  MaterialTheme {
    WeatherScreen(repository)
  }
}

As mentioned on the website, it supports keyboard shortcuts, window manipulation, and notifications. It renders with Skia which means your apps will have native performance, however, you will need to build your own ‘Widgets’ or find an existing library if you want your app to actually look native to each platform.

Code sharing between Compose Multiplatform and the Jetpack Compose is possible, too, but I believe most of the UI elements have to be built separately. Still, this is a lot of platform support and I’m genuinely excited to see where this framework goes in the future.

Here’s some example code to get a feel of what it looks like

import androidx.compose.desktop.DesktopMaterialTheme
import androidx.compose.foundation.ContextMenuDataProvider
import androidx.compose.foundation.ContextMenuItem
import androidx.compose.foundation.layout.*
import androidx.compose.foundation.text.selection.SelectionContainer
import androidx.compose.material.Text
import androidx.compose.material.TextField
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import androidx.compose.ui.ExperimentalComposeUiApi
import androidx.compose.ui.Modifier
import androidx.compose.ui.unit.dp
import androidx.compose.ui.window.singleWindowApplication

@OptIn(ExperimentalComposeUiApi::class, androidx.compose.foundation.ExperimentalFoundationApi::class)
fun main() = singleWindowApplication(title = "Compose for Desktop") {
    DesktopMaterialTheme { //it is mandatory for Context Menu
        val text = remember {mutableStateOf("Hello!")}
        Column(modifier = Modifier.padding(all = 5.dp)) {
            ContextMenuDataProvider(  
                items = {
                    listOf(  
                        ContextMenuItem("User-defined Action") {/*do something here*/},
                    )  
                }
            ) {
                TextField(  
                    value = text.value,
                    onValueChange = { text.value = it },
                    label = { Text(text = "Input") },
                    modifier = Modifier.fillMaxWidth()  
                )

            Spacer(Modifier.height(16.dp))  

            SelectionContainer {  
                    Text(text.value)  
                }
            } 
        }
    }
}

Positives

Works on MacOS/WIndows/Linux and the web.
Support for sharing code on Android apps with Jetpack Compose
Uses Kotlin
Native performance
Built in Previews
Has tools for automated testing
Supported by Jetbrains
Actively developed

Negatives

Maturity - 1.0 only recently released
Small community
Only stand alone builds are currently supported (Although there is an Apple App Store PR), no sign of how to handle automatic updates.
Small ecosystem (plugins etc)
No native UI widgets or theming out of the box

egui

egui is a Rust library and builds natively with Glium (Or Glow) and WASM for the web. For native, It supports MacOS, Linux, Windows.

Out of the Rust GUI libraries available I think this one is my personal favourite. It’s self-described as easy to use and difficult to make mistakes. For someone like myself—who’s more of a visitor to the Rust language—it’s music to my ears.

It’s actively maintained, with a new release out literally an hour ago as of the creation of this sentence.

Here’s a snippet taken from one of the examples along with the newly added context menu support (Right clicking UI elements).

egui::CentralPanel::default().show(ctx, |ui| {
    // The central panel the region left after adding TopPanel's and SidePanel's

  ui.heading("eframe template");
  ui.hyperlink("https://github.com/emilk/eframe_template");
  ui.add(egui::github_link_file!(
      "https://github.com/emilk/eframe_template/blob/master/",
      "Source code."
  ));
  let response = ui.add(Label::new("Test Context Menu").sense(Sense::click()));
  response.context_menu(|ui| {
      if ui.button("Open").clicked() {
          ui.close_menu();
      }
      ui.separator();
      if ui.button("Cancel").clicked() {
          ui.close_menu();
      }
  });

  egui::warn_if_debug_build(ui);
});

Positives

Works on MacOS, WIndows and Linux and the web.
Built with Rust
Native performance
Actively developed
Support for multiple renderers

Negatives

Maturity - Not currently at a 1.0 release so the API is unstable and missing features
Small community
Only stand-alone builds are currently supported (Although there is an Apple App Store PR), no sign of how to handle automatic updates.
No ecosystem (plugins etc)
No native UI widgets or theming out of the box
No live preview

Electron

I’ve built two and a half apps with Electron so it’s fair to say I have experienced first hand the positives and negatives of the platform. Electron is a tool that puts web technologies on the desktop via Chrome. With Electron you’ll most likely be writing every part of the app with Javascript or Typescript, although it’s certainly possible to switch this up, for example, 1Password recently switched their desktop app to Electron with a Rust backend.

I’ve used Electron with Ember Electron and with Quasar (Vue.JS). I'll talk more about both individually below, but as a general overview, Electron is fantastic and easy to recommend so long as you can put up with its shortcomings

Positives

Works on MacOS, Windows, and Linux
Since it’s wrapping a web app, you can likely share most, of the code base with an web app if you have one
Large community and ecosystem
Support for many forms of distribution, including automatic updates and various app stores
Has Chrome’s accessibility features built in
Supports multiple windows, and some native components such as dialog boxes, notifications, etc

Negatives

Large file size due to bundling Chrome
Generally slower than the alternatives
Web wrapper—projects will look and feel out of place with the operating system
There are many security practices to follow to keep your app secure

Ember Electron

Ember is one of my favourite Javascript frameworks. I’ve built many web projects with it so it was natural for me to try a desktop app with it, too. My apps, Snipline 1 and 2, are both built with Ember Electron so I have a reasonable amount of experience with it.

All of the positives and negatives from the Electron section still apply here, so I’ll comment specifically of the Ember Electron add-on.

With Ember Electron 2, it was tricky to update the Electron dependency, but with the release of Ember Electron 3 the Electron Forge dependency was updated . This means that Electron can be kept up to date separately to Ember Electron. Since Electron gets updated quite regularly it's a much welcome update.

Activity is much slower now with Ember Electron, with the latest release of 3.1.0 back in May, and the community is very small compared to the other available choices. As much as I enjoy the stack, I could not recommend it unless you want to turn an existing Ember app into a desktop app, or are already very productive with Ember.

Quasar

Calling Quasar an Electron wrapper is selling it short. It provides many of the benefits of Ember JS, such as file directory conventions and a CLI, but it also adds support for mobile apps, SPAs and it’s own UI framework. Take a look at all of the reasons that make Quasar great on their Why Quasar? page.

I’ve built one desktop app with Quasar for an internal company project, and overall it was a pleasant experience. I much prefer Tailwind CSS to Quasar UI, and there’s nothing stopping you using both except for the additional dependency.

As with Ember Electron, you get all of the benefits of Electron with Quasar, and building the app is as simple as running a command

quasar build -m electron

One difference from Ember Electron is the build module. Ember Electron uses ‘Electron Forge’ whereas Quasar gives you two choices, Packager or Builder. Personally, I’ve used Builder and had no issues besides the teething problems of getting auto updating working on Windows.

Regarding activity, Quasar is very active, with an update to the main repo just for days ago as of writing and plenty recently before that. There are many contributors, and the documentation is great. I think that if you’re familiar with Vue.JS and Vuex then you’re in safe hands using Quasar.

Flutter

One of the most impressive things about Flutter is the breadth of devices it supports. From mobile, desktop, to embedded devices. Similar to Compose, it uses Skia to render the UI, so while you’re getting native performance you’re most likely not going to get a native look, at least not out of the box.

Unlike Compose, I was pleasantly surprised when I followed an Android tutorial to build a Windows app and it just worked. Of course, it looked like an Android app, with the default Material theme, but there's nothing to stop you tweaking the theme per device. Take a look at this blog post by Minas Giannekas on how he built Shortcut Keeper and how he themed it for each platform. Truly impressive.

There’s also a large community and ecosystem surrounding Flutter, so you’re unlikely to run out of learning resources.

But Flutter isn’t without it’s shortcomings. There’s a long list of issues in their Github repo, which also speaks for the popularity of the library. Much of the ecosystem is focused on mobile, which means if you wish to make an app work across mobile, desktop, and web, you may have to provide your own functionality for the latter two environments.

There are also complaints that the development of Flutter outpaces the plugins surrounding it. You may need to stay on an older version of Flutter because of plugin compatibility issues.

Positives

Native performance
Works on MacOS, Windows, Linux, iOS, Android, and Embedded devices
Large community and lots of plugins
Actively developed and backed by Google
Large pool of resources to learn from

Negatives

Most of the community and plugins are mobile focused
Fast pace of development may mean compatibility issues with plugins

Reactive Native for Windows

Since I’ve included a Vue.JS and an Ember JS library, I thought it would only be fair to include a library for React developers, too. React Native is a popular solution for building native apps for iOS and Android and uses Objective-C and Java under the hood for each platform respectively.

For Windows, it renders with Universal Windows Platform (Or UWP for short) which means you really are getting native controls rendered. I couldn’t find any information of how the React Native for MacOS renders, although I’d imagine it’s doing something similar to iOS.

Here’s a quick snippet that I tried starting from the base RNW project.

import React, { useState } from 'react';
import type {Node} from 'react';
import {
    SafeAreaView,
    ScrollView,
    StatusBar,
    StyleSheet,
    Text,
    useColorScheme,
    View,
    Alert,
    Modal,
    Pressable
} from 'react-native';
import {
    Colors,
    DebugInstructions,
    Header,
    LearnMoreLinks,
    ReloadInstructions,
} from 'react-native/Libraries/NewAppScreen';

const Section = ({children, title}): Node => {
    const isDarkMode = useColorScheme() === 'dark';
    return (
        {title} {children} 
    );
};
const App: () => Node = () => {
    const isDarkMode = useColorScheme() === 'dark';
    const [timesPressed, setTimesPressed] = useState(0);
    const backgroundStyle = {
        [backgroundcolor: isDarkMode ? Colors.darker : Colors.lighter,
    };
    const buttonStyle = {
        [padding: '20px',](padding: '20px',)
    }
    return (
        <SafeAreaView style={backgroundStyle}>
            <StatusBar barStyle={isDarkMode ? 'light-content' : 'dark-content'} />
            <ScrollView
            contentInsetAdjustmentBehavior="automatic"
            style={backgroundStyle}>
                <Section title="React Native for Windows"></Section>
                <Pressable
                    onPress={() => {
                        setTimesPressed((current) => current + 1);
                    }}
                style="{({pressed}) => [
                {
                backgroundColor: pressed ? 'rgb(210, 230, 255)'
                : 'black',
                padding: 10,
                textAlign: 'center'
                },
                styles.wrapperCustom
                ]}>
                {({ pressed }) => (
                    <Text style={() => [ { ...styles.text, textAlign: 'center' }]}>
                        {pressed ? 'Pressed!' : `Count: ${timesPressed}`}
                    </Text>
                )}
                </Pressable>
            </ScrollView>
        </SafeAreaView>
    );
};

const styles = StyleSheet.create({
    sectioncontainer: {
        margintop: 32,
        paddinghorizontal: 24
    },
    sectiontitle:
        fontsize: 24,
        fontweight: '600',
    },
    sectiondescription: {
        margintop: 8,
        fontsize: 18,
        fontweight: '400',
    },
    highlight: {
        fontweight: '700',
    },
});

export default App;

In terms of community, you have the foundation of the mobile RN community to work with, but as with other ecosystems in this article, you probably aren’t going to find much plugin support for desktop at the moment.

Positives

Renders natively
Share code with React Native mobile apps
Build with Javascript or Typescript
React developers will feel right at home

Negatives

RNW and MacOS are relatively new and not yet stable
Smaller community and ecosystem for desktop
No Linux support

SwiftUI

Having released 2 apps and another on the way, SwiftUI is another tool I have plenty of experience with.

SwiftUI has been designed by Apple to work well on each of their platforms. There are many 'Widgets' that can be shared across each platform so you can write code once and have it run on most devices. For example, context menu's on an iOS device are triggered from a long press, where as on a Mac it's triggered from a right click.

// Taken from the useful app, SwiftUI Companion   
struct ExampleView: View {
   var body: some View {
     Text("Press, hold and release")
       .foregroundColor(.white)
       .padding(15)
       .background(RoundedRectangle(cornerRadius: 8).fill(Color.blue))
       .contextMenu {
         Button("Open") {  print("open...") }
         Button("Delete")  {  print("delete...") }
         Button("More info...") {  print("more...") }
     }
   }
}

A personal favourite feature of mine, which I’ve yet to see in other GUI frameworks, is data binding between multiple windows. Using the @AppStorage property wrapper, you can update a value in one window and have it's value easily sync in another. This is really useful for preferences which are generally in their own window in MacOS apps.

Here’s a truncated example of the power and simplicity of SwiftUI for Mac apps.

import SwiftUI

@main
struct RsyncinatorApp: App {
  @AppStorage('showVisualHints') private var showVisualHints = true

  var body: some Scene {
    WindowGroup {
      ContentView()
    }

    #if os(macOS)
    Settings {
      SettingsView()
    }
    #endif
  }
}

struct SettingsView: View {
  private enum Tabs: Hashable {
    case general, advanced
  }
  var body: some View {
    TabView {
      GeneralSettingsView()
        .tabItem {
          Label("General", systemImage: "gear")
        }
      .tag(Tabs.general)
    }
    .padding(20)
      .frame(width: 375, height: 150)
  }
}

struct GeneralSettingsView: View {
  @AppStorage("showVisualHints") private var showVisualHints = true

  var body: some View {
    Form {
      Toggle("Show visual hints", isOn: $showVisualHints)
    }
    .padding(20)
      .frame(width: 350, height: 100)
  }
}

Here’s the Preferences window that’s generated. If you’re familiar with Mac apps, you should recognise the general layout with the tabbed sections at the top. All this is laid out for you.

One major show stopper for many people is that it doesn’t build for Windows and Linux. I also feel it’s only just becoming a real solution as of it's 3rd major release which adds much needed functionality. Functionality such as search and focus states weren't properly supported before so you'd have to write it yourself. There are also bugs that crop up and it's down to Apple's discretion as to when these get fixed.

The community and packages surrounding SwiftUI tend to focus on mobile, however, there are still a reasonable amount of resources for MacOS. If you're interested, take a look at this official tutorial for MacOS for getting started.

Positives

Easy to make native Mac apps that look like Mac apps
Lots of resources for learning that are applicable for iOS and MacOS
Share code between iOS, tvOS, watchOS

Negatives

No build for Windows or Linux
Bugs are fixed at the whim of Apple
Only one major release per year with new functionality
Closed source
Only fairly recent MacOS versions support it and each of the previous versions of MacOS support fewer features

Tauri

Tauri is another fairly new library. It’s a web wrapper and you can use whichever web framework you prefer. There’s an officially supported plugin for Vue.JS, but it is simple enough to add your own. I've had it working with both Ember JS and Svelte.

It’s first major difference from Electron is that it uses your Operating System’s web browser rather than bundling Chrome. This results in fairly tiny file sizes, but at the cost of having to debug issues on different platforms.

The second major difference is that Tauri uses Rust. With Electron you pass messages from main and renderer with Node and Javascript, whereas with Tauri you pass events from the frontend and backend with Javascript and Rust, respectively.

Here’s a snippet from the Tauri documentation of communicating between the two.

import { getCurrent, WebviewWindow } from '@tauri-apps/api/window'

// emit an event that are only visible to the current window
const current = getCurrent()
current.emit('event', { message: 'Tauri is awesome!' })

// create a new webview window and emit an event only to that window
const webview = new WebviewWindow('window')
webview.emit('event')

// the payload type must implement `Serialize`.
// for global events, it also must implement `Clone`.
#[derive(Clone, serde::Serialize)]
struct Payload {
  message: String,
}

fn main() {
  tauri::Builder::default()
    .setup(|app| {
      // listen to the `event-name` (emitted on any window)
      let id = app.listen_global("event-name", |event| {
        println!("got event-name with payload {:?}", event.payload());
      });
      // unlisten to the event using the `id` returned on the `listen_global` function
      // an `once_global` API is also exposed on the `App` struct
      app.unlisten(id);

      // emit the `event-name` event to all webview windows on the frontend
      app.emit_all("event-name", Payload { message: "Tauri is awesome!".into() }).unwrap();
      Ok(())
    })
    .run(tauri::generate_context!())
    .expect("failed to run app");
}

I’ve built and released one app with Tauri and it was fairly painless for a simple app. I used Svelte for the web framework and each installer came out at less than 5MB.

For larger apps, I would most likely struggle to implement certain functionality. The getting started guides are easy enough to follow, but once I started trying to add more functionality I found the overall documentation lacking. There’s also fewer features than Electron which is to be expected since the platform is not as mature and the community not as large.

It supports adding CLI’s to your app which I think is a very cool feature that’s not often built into GUI libraries. You can also embed external binaries which can be very useful if you need to use a command-line tool for functionality in your app. It also supports auto updating for each platform (With Linux supporting AppImage).

Positives

Supports auto updating on MacOS, Windows and Linux
Build your own companion CLI
Integrate external binaries
Small distribution file sizes
Use any frontend JS framework you prefer

Negatives

Fewer features than alternatives
Small community and ecosystem
Not yet at a stable release
Different OS browsers can (and will) behave differently - extra testing required

GUI Library Overview

I thought it would be beneficial to have a casual overview of the differences between platforms, including differences in community size and support.

Releases in the past 6 months gives some indication of activity on each project, and includes beta, dev, and RC releases. This information is taken from each project’s git repository and is checked between 1st July 2021 and 1st January 2022.

As SwiftUI is not open source and other than at WWDC where major changes are announced, we do not get a run-down of changes between Xcode versions, it’s difficult to compare. We do know however that SwiftUI is backed by Apple and appears to be the recommended way of making apps for the Apple ecosystem moving forward.

SwiftUI is also the only platform out of the list that does not support Windows/Linux. It does however have support for iOS, iPadOS, Apple Watch, and Apple TV. If you’re in the Apple ecosystem, it’s definitely something to consider.

Framework/Library	Language(s)	Native	Platform Support	Contributors	Releases in past 6 months	Initial release date	Stable release?
Compose	Kotlin	✅	💻🪟🐧🤖	64	51	2nd April 2021	✅
egui	Rust	✅	💻🪟🐧	89	4	30th May 2020	❌
Electron	Javascript	❌	💻🪟🐧	1081	113	12 Aug 2013	✅
React Native for Windows	Javascript/Typescript	✅	💻🪟🤖📱	180	49	23 Jun 2020	❌
Flutter	Dart	✅	💻🪟🐧🤖📱	957	28	27th Feb 2018	✅
Tauri	Rust + Javascript	❌	💻🪟🐧	114	4	18th December 2019	❌

Features

Not all frameworks have every feature. If you’re looking to make an application that relies on specific things such as webcam support then you’ll need to check if it works or you’ll have to code it yourself.

Note that, my Google-foo may fail. I have tried looking through documentation and various resources for each library but unfortunately it’s not always easy to find if a solution exists.

Additionally, these features may get added after this article is published, so do your own research, too!

Here’s a key for the tables below.

✅ - native/first party support
📦 - support via external plugin
🎓 - tutorial/community information available
❓- Unknown (Most likely unavailable)
❌ - unsupported/unavailable

For theming and light/dark mode I’ll be looking at native support for the Operating System’s features. Web wrappers also generally have features that you can use from the browser, e.g. webcam support via JS, which I mention in the table.

Automatic updates for Linux are only available for Electron and Tauri via AppImage. Unfortunately most libraries don’t support over the air updates or only partially support it, and in this case you’ll have to either implement it yourself, or simply prompt the user to install the next update manually by checking a web-hook that you set up and manage.

Framework/Library	Context Menus	Window Menus	Multiple Windows/Window Manipulation	Webcam/Microphone	Automatic updates	Theming, Light and Dark mode	Tray
Compose	✅	✅	✅	❌	❌ (issue)	🎓(link)	✅
egui	✅	✅ (basic)	❓(issue)	❌	❌	🎓(link)	❌
Electron	📦 (plugin)	✅	✅	✅ (Via JS)	💻🪟🐧	✅ (link)	✅
Flutter	📦 (1, 2)	📦 (plugin)	❌	❌	❌	❓	🎓(link)
React Native for Windows	❌	❓	❓	❓	Microsoft Store	✅	❌
SwiftUI	✅	✅	✅	✅ (Using AppKit)	Mac App Store, Sparkle	✅	✅
Tauri	❌ (JS library work around)	✅	✅	(Via JS)	💻🪟🐧	✅ (Via CSS)	✅

Accessibility

There’s many different levels of accessibility so I thought it would be worth investigating.

When looking at font size, I’m referring to ability to use the Operating System’s font scaling. Most tools are able to implement their own font scaling if they wanted to — or with a bit of additional code.

Interestingly, I tried testing this with Compose on Windows and the font refused to scale up. egui and Flutter worked fine, and browser based libraries will use the web browsers native font scaling.

Framework/Library	Voice over	Keyboard shortcuts	Tooltips	OS font size scaling	Tab focusing/cycling
Compose	✅ - Mac Only, Windows planned	✅	✅	❌	✅
egui	❌ (issue)	❌ (issue)	✅	✅	✅
Electron	✅	✅	🎓 (link)	✅ (Chromium handles this)	✅
Flutter	❓(link)	✅(link 1, 2)	✅	✅	🎓 (link)
React Native for Windows	❓	❌ (issue)	✅	✅	✅
SwiftUI	✅	✅	✅	✅	✅ (MacOS Montery+)
Tauri	❓	✅ (Via JS)	✅(Via JS)	✅	✅

Final Recommendations

When choosing a library for building a desktop app, I think you have to ask yourself which category your application falls into:

Personal project to solve your own issue
Small scope software with few updates or released as feature complete
Projects targeting developers
Product to be distributed and available to as many people as possible with frequent updates (E.g. a SaaS)
Enterprise - stability and maintainability at utmost importance

For personal and feature complete software, I’d suggest going for the one that appeals the most to you, assuming it has the features you need.

For most other projects, you're most likely going to want to have automatic updates available. That is, unless you want to respond to every support request with 'Can you update to the latest version please’.

It's a real shame that it removes many of the otherwise great libraries from the running. If you can get away with it, you could instead implement a prompt that tells users to download a newer version manually when it’s available. Still, OTA updates are almost a requirement for desktop software today.

There is also a niche for software that only targets Apple devices. Plenty of developers go this route, just take a look at Sketch, Panic, Craft docs, as a few examples. It certainly simplifies development, and if you're already in the Apple ecosystem it's great to scratch your own itch. If this sounds like your situation then SwiftUI is a great choice.

I really like all of these libraries, but Electron is the solution that's least likely to bite you with it's large community, ecosystem and feature set. That said, I'm eager to see the other solution grow in the future.

If you have any thoughts or suggestions for tools I should check out. Please feel free to comment! You can reach me on Mastadon, Twitter, Dev.to, Micro.blog, or comment directly on the original article.

Introducing Rsyncinator

Mitch Stanley — Wed, 23 Jun 2021 09:40:59 +0000

In March last year, I released a web tool for building rsync commands via a GUI. I've now further developed it into it's own Mac app which is named Rsyncinator.

The Mac app adds some niceties, such as being able to store and load commonly used rsync commands and using a convenient file picker for local paths. It also comes with all the goodness of a native Mac app: It's fast, small, and has multi window/tab support.

After I finished building it, I decided it needed a website of its own. So I've rewritten the old Rsync for Snipline website from the ground up. You can still use the web tool, although it's slightly different now (More inline with the Mac app).

You can see the new website here and if you like the look if it, you can get the Mac app on the App Store.

Snipline 2 Progress Report May 2021

Mitch Stanley — Wed, 26 May 2021 15:11:45 +0000

If you don’t know what Snipline is, here’s a brief run-down: Snipline started as a tool to scratch my own itch. I wanted an app that streamlined saving, searching and using shell commands.

If you’re interested in learning more, checkout the home page.

UI Refresh

The most obvious change is the UI. The structure is very similar and yet very different at the same time. I've moved from Tailwind 1 to Tailwind 2, and with that I'm also using Tailwind UI for some of the elements. There's also some other noticeable changes like no more settings button, and the moved 'New Snippet' button.

Farewell Command Bar, Hello Command Palette

In the UI Refresh screenshot, you may have noticed the command bar is no longer visible, and that's because it no longer exists. I want to move Snipline 2 to a command palette style workflow. Popularised by apps such as Sublime Text 2 where you hit a keybind and you select an action.

In v1 the flow was either

a) Search snippet and click run/copy.

b) Search and type the snippet number in the command bar (E.g. :1 to run, or :e 1 to edit etc ).

In v2 the flow is

a) Search snippet and click run/copy

b) Search snippet, press enter to open the command palette on the selected snippet, choose your action, e.g. run.

c) Ctrl/Command+enter to skip the palette and run the selected snippet.

It's a big change which makes using Snipline more visual and app-like.

Dedicated preference window

In Snipline 1 the settings were done within the main app window. This worked fine, but there were two issues that bugged me.

There needed to be a button to open the settings within the main app which took up space.
It's more difficult to scale out the settings within a potentially constrained size.

With Snipline 2 I'm pleased to show that the preferences are in their own window. This can be opened from the menu or by the Operating Systems conventional preference shortcut (e.g. in MacOS this is ⌘+,).

This means the icon is no longer required within the main app, which helps to make it look cleaner. More importantly, I can expand the preferences into different tabs like most applications do.

New Features

There are lots of small QoL improvements in this release, but here are some of the bigger ones.

Custom keybinds and Global shortcut!

Your browser does not support the video tag.

It's a common request for Snipline to have a global keybind and here it is. Personally, I have it set to hyper+s but this is configurable to your own taste.

Many of the navigational elements can be customised and support chording. What is chording? Those familiar with Vim will know, instead of using a single combination of keys, you can press multiple keys in succession. A common one for Vim would be g g to go to the bottom of the file.

And if you use command/ctrl keys in your shortcuts you can use these without leaving the search bar!

Offline mode

See the 'Internal Updates' and 'Pricing' sections later in this post for more details on why I'm adding this.

New syntaxes

I have not started implementing these yet so I can't make any promises, but there are three new syntaxes I'd like to add: One for replacing text with your current clipboard, some kind of confirm/if statement, and variable transforming (e.g. to camelCase, snake_case, etc).

Internal Updates

In the beginning, the main reason I labelled this as 'Snipline 2' was because of all the internal updates I wanted to do. Most importantly, it's using Ember Octane and Electron 12, which I hope will make the app more performant. And perhaps more noticeably, the switch to Tailwind 2 and TailwindUI components.

However, the biggest internal change is the fact it's storing snippets locally by default. This means no more signing in to your account or having an active internet connection.

Since Snipline 2 will be local by default it means that Snipline CLI and Snipbar will not be compatible with it - at least initially. I may do an update for these, or possibly new apps. Time will tell.

Pricing

One of the biggest complaints I received from Snipline 1 was the fact it was subscription based. I sort of addressed this by bringing in the 'Pay what you want' model, reducing the initial price down to $9/year. I can happily say this helped bring in more subscribers and as I've mentioned in previous blog posts, and I still get many people that go for the original price of $18/year which I really appreciate.

I completely understand subscription fatigue, and I wanted to address this from the start with Snipline 2. So I'm pleased to announce that the base app, which is usable offline and has 90% of the features, will be a one time cost. Buying this will give you a license key which you can use on your devices for as long as you want.

I plan to create two tiers of subscriptions: Pro and Team which have some additional server based features.

The Pro plan will include syncing between devices, Sharing Snippets via a web URL, and snippet revisions. A side effect of this plan is that you essentially have a back up of your snippets, too.

The Team plan will include the Pro features but allow you to share snippets between teammates.

The price of these are to be confirmed, but it's safe to say they're not going to be too different to the current price.

Upgrade plan

Chances are, if you're interested enough to read this far, you're probably a subscriber to Snipline 1.0, and you're wondering What about me?

My plan for active Snipline 1.0 users is to offer a free license for the app, and one year of the Pro plan. I'll also hopefully be giving beta invites for these users first!

I've said in a previous blog post that Snipline 1 and Snipline 2 can be run side by side. This is still true, but they will not be synced with each other. I would encourage Snipline 1 migrants to import their existing Snippets into Snipline 2 and when they are ready move over to the new subscription.

Thanks

You reached the end of the blog! Thanks for reading, feel free to reach out to me on Twitter if you have any questions.

Building small desktop apps with Ember.js and Tauri

Mitch Stanley — Mon, 24 May 2021 13:04:23 +0000

I recently played around with Tauri, a toolkit for development desktop apps with web technologies. Here's how I got it working with an Ember.js application.

What is Ember?

Ember.js is a frontend framework similar to React and Vue JS. I used it to build my app Snipline, and it's also used for websites like Intercom and LinkedIn. It has a 'convention over configuration' approach similar to Ruby on Rails.

What is Tauri?

Tauri is a library for making desktop applications with web technologies. Similar to Electron with a few key differences:

1) It's built in Rust rather than Javascript.

2) It uses your operating system's native web browser rather than bundling Chrome which resulting in quite tiny applications—at least compared to Electron!

Installation and development

Here are the commands I ran for a simple Ember app to test routing with Ember and Tauri. For reference, I'm using Node. 14.17.0.

Setting up Ember

npm install -g ember-cli

ember new tauri-test --lang en

ember g route index
ember g route from-ember

ember serve

I edited the two generated templates, app/templates/index.hbs and app/templates/from-ember.hbs.

{{page-title "Index"}}
<h1>Hello, Tauri 😄</h1>
<LinkTo @route="from-ember">Click here</LinkTo>

{{page-title "FromEmber"}}
<h1>From Ember 🧡</h1>
<LinkTo @route="index">Back</LinkTo>

That's enough to get started and test that routing works within the app. Now let's get to the good stuff.

Setting up Tauri

First, follow the set up guide for your OS in the Tauri documentation.

After this, it's a matter of adding it to your ember project - See the integration documentation.

This is what I did to get it working.

npm install @tauri-apps/cli

// Add the `tauri` command to your `package.json`
{
  // This content is just a sample
  "scripts": {
    "tauri": "tauri"
  }
}

Run through the initialisation process.

npm run tauri init

When prompted, make sure that you set the development server to http://localhost:4200 and the location of the files (relative to src-tauri) to ../dist.

Then it's just a matter of running the development subcommand (Make sure your Ember server is still up, too).

npm run tauri dev

And that's it! It works even with hot reloading!

Packaging

With development out of the way, here's how to package the app for distribution. I won't be looking at auto-updates in this guide, but Tauri does have support for this.

ember build --environment=production
npm run tauri build

On MacOS installer .dmg file came out at 5.4MB and the .app file 12.4MB.

For Windows, the generated MSI installer came to 4.9MB and the executable 8.9MB.

Communicating between Rust and Ember

Taking this one step further, I thought I'd test a simple ping/pong example of communicating between Ember and Rust. For more information check the Tauri docs.

The following code allows for Ember to pass a string to Rust, Rust checks the value and toggles between the text 'Ping' and 'Pong'. In Ember, I've added a button that displays the response text and updates it on click.

// src-tauri/src/main.rs
#![cfg_attr(
  all(not(debug_assertions), target_os = "windows"),
  windows_subsystem = "windows"
)]

// Add a new function that takes a string and returns a string
#[tauri::command]
fn my_custom_command(current_text: String) -> String {
    // Depending on what we receive from Ember we toggle the response
    if current_text == "Ping" {
        "Pong!".into()
    } else {
        "Ping".into()
    }
}

fn main() {
  // Add the custom command so that the frontend can invoke it
  tauri::Builder::default()
    .invoke_handler(tauri::generate_handler![my_custom_command])
    .run(tauri::generate_context!())
    .expect("error while running tauri application");
}

// app/controllers/index.js
import Controller from '@ember/controller'
import { action } from '@ember/object'
import { tracked } from '@glimmer/tracking'
import { invoke } from '@tauri-apps/api/tauri'

export default class IndexController extends Controller {
    // Set the default button text
    @tracked buttonText = 'Ping'
    // Create an action that will be attached to a button in the template
    @action
    checkRust() {
        // Invoke the Rust command and update the button text to the response
        invoke('my_custom_command', { currentText: this.buttonText }).then(resp => {
            console.log(resp)
            this.buttonText = resp
        })
    }
}

Here's the updated app/templates/index.hbs template file.

{{page-title "Index"}}
<h1>Hello, Tauri 😄</h1>
<LinkTo @route="from-ember">Click here</LinkTo>
<button {{ on 'click' this.checkRust }}>{{this.buttonText}}</button>

Pretty cool! I'm excited to see where Tauri goes, and to see its plugin ecosystem grow. Should I try building a full project in it or write some more tutorials using both technologies? Let me know in the comments!

Updated my blog to Zola and TailwindUI

Mitch Stanley — Fri, 21 May 2021 07:56:45 +0000

As is customary for web developer blogs, I spend more time building the website than I do blogging.

Link to the website

That said, there were a few issues with my previous site that made me want a refresh.

Comments weren't always loading.
No call to actions or even social links!
Formatting wasn't always quite right, especially with syntax highlighting.
Ability to link up series' of articles (Like dev.to).
Add warning disclaimer to old posts.

Anyway, I've rebuilt the site with Zola and TailwindUI and I'm pretty pleased with it.

I'm promoting my apps a bit more with it and my social media presence.

As a bonus, it has a native dark mode!

The old website

Just for kicks, here's what the old website looked like. It was made with a template and used Nuxt.js + CraftCMS for the headless CMS.

And here's the first website! This one was built with Middleman, a Ruby static site generator. Back in 2013.

Flutter vs Jetpack Compose for Desktop?

Mitch Stanley — Mon, 26 Apr 2021 13:53:25 +0000

I've recently been researching which of these technologies to use for making desktop apps for Windows, Linux, and as a bonus, possibly mobile apps for Android.

For context, I 'm primarily a web developer but very happy with using SwiftUI for iOS/iPadOS/MacOS for side projects. What I'm looking for is something to supplement this in other ecosystems.

So far I've installed both Flutter and Compose and tried some beginner tutorials. My first thoughts are:

Flutter Pros

Not restricted to a specific IDE.
You can use Flutter cli.
Getting Started guide was easy to follow. Even though it was for Android it worked well for Windows.
Great support for Linux - with Ubuntu using it for software going forward.
Lots of plugins, resources, and a big community.

Flutter Cons

IMO - Flutter seems less like SwiftUI than Compose - More verbose?
Will desktop apps look like Android apps wrapped in a window? I see there are 'Yaru' style widgets for Ubuntu, but can't see anything for Windows.
Desktop plugin ecosystem is more limited than Android.
Has some edge case issues which make it a non-starter for certain projects. E.g. #23913.

Compose Pros

I like the syntax - feels very similar to SwiftUI.
Convenient previews in the IDE.
Appears to a great, upcoming solution for Android.

Compose Cons

Currently has to use Android Studio Canary to make an Empty Compose for Desktop project.
Code appears to differ more for each Ecosystem (Desktop vs Android). I tried following the beginner tutorial for Android but targeting Windows (Like I did with Flutter) and could not get this to work.
Fewer resources - especially for Desktop development.

These lists look very unbalanced in Flutters favour, but as a newbie to both ecosystems I'm wondering if I'm missing something. Part of me is very tempted by Compose, but as someone not too familiar with Android Development I feel it would be more of an uphill battle.

I'm very keen to know what other people think about these two solutions, or if there is anything else out there that people are betting on!

Snipline: Year 2 in Review

Mitch Stanley — Wed, 10 Feb 2021 13:58:41 +0000

This is the second annual review of Snipline. The shell command bookmarker app.

If you don't know what Snipline is, here's a brief run-down: Snipline started as a tool to scratch my own itch. I wanted an app that streamlined saving, searching and using shell commands.

If you're interested in learning more, checkout the home page.

Notable Product Updates

Desktop

Since last February the desktop app has added:

The 'Show' view.
Improvements to the multi-choice syntax.
Various bug fixes.
1.0 release!

This seems small, but much of the desktop work is going on with the next big release of Snipline (version 2) which I'll speak about later in this post.

More importantly, the app finally hit 1.0! Personally, I think i kept it as 0.x for too long, giving the impression that the software was not production ready. In reality it's been pretty stable for quite some time.

Snipline CLI

The open source sidekick for Snipline has received a few updates this year, including support for building with Docker, allowing comma's in multi-choice parameters, and adding password authentication.

The search functionality in Snipline CLI had a major update just before last year's review, and included a fancy terminal UI which was very interesting to build as I had no prior experience with NCurses. It certainly was an eye-opener!

Snipbar

The MacOS menu bar app is in a great place as of right now. I recently updated it with fixes for multi-choice comma support, and allowing multi-choice parameters to be re-used, bringing it inline with the Desktop app.

Other items

There's been a lot of behind the scenes work going on. Including preparing for password based log-ins rather than token-based login.

Emails switched from Sendgrid to Postmark as there were a lot of deliverability issues with Sendgrid. So far there has been no complaints since switching.

I released Rsync Command Generator, a free tool for generating rsync commands. This tool receives a surprising amount of visits, to the point where I'm very tempted to make a standalone desktop app for it.

I also migrated the blog to Hugo. I was having a lot of issues with Middleman, my previous preferred static site generator, and Hugo seems to work well enough.

Looking back at last years review

Last year I wrote about getting the pricing right. Not every developer wanted to pay the $18/year subscription for Snipline. The pricing now has a 'Pay what you can' structure. I'm very happy to say that subscriptions are up significantly from last year. The majority of people have opted for the $9 plan, and I'm pleasantly surprised to see that there's been several $18 subscribers, too!

What's next for Snipline?

First on the agenda is adding the Snipline CLI multi-choice reusable parameter fix, as well as updating it for the latest Crystal-lang release.

I'm hoping that Snipbar will be the next app to support password based logins.

Finally, there's Snipline 2...

Snipline 2

I've mentioned in a previous blog post that I'm very much focused on Snipline 2 at the moment.

What is Snipline 2? Many of Snipline Desktop's dependencies are starting to show their age now, and although I could update them in Snipline 1, I want to make some changes to the design and functionality.

Most importantly, I don't want to force users to use version 2 if they prefer version 1.

My plan is to allow subscribers to continue using version 1 if they prefer it. Hopefully, they will see the benefits of version 2 and switch to it. There will be no additional cost.

Items that didn't make it in this year

A few things I wanted to achieve in the 2nd year of Snipline which didn't make the cut:

Client-side encryption
Publishing an API
iOS App

These are still very much on my mind. Client-side encryption is tricky for a few reasons, picking the right encryption, and having it available in Javascript/Crystal and Swift. More importantly, how to enable it (per snippet or per account?).

I want to hold off on releasing a public API until the password based auth is finalised.

The iOS app is a big task, and I feel I should focus on the new desktop app first. However, I recently released an app in SwiftUI which was a really pleasant experience. I would really like to do this for Snipline if there's interested in it.

Thank you

That's all for now. For all the Subscribers and trial users, thank you so much for using my little app. Many of you have reached out with bug reports and queries, and you've all honestly been so helpful and understanding. I hope that you will continue to use Snipline for the foreseeable future!

My first (and worst) Rust program

Mitch Stanley — Mon, 09 Nov 2020 15:46:02 +0000

I've been looking for an excuse to try out Rust for a while and decided to write a simple CLI to help split grocery costs between my partner and myself.

The Current Solution

We currently split grocery costs in 3 ways, she pays for her items, I pay for mine, and the food we share we split the cost fifty/fifty.

I receive an email receipt from our grocery store. I then enter the costs into Soulver to do some Maths and figure out how much we each owe.

The Problem

The current solution is slow and prone to human error (I get distracted). If I miss an item, add an item twice, or type in the wrong price, then one of us could end up owing too much or too little.

Although we share some food, one of us often eats more than the other of some products. In this situation the fifty fifty split is less fair.

Trying to split these items more further would make the calculation more tedious and error prone.

My Rust Solution

Since I receive an email with the receipt I can take the text and run it through a script quite easily.

The below Rust script, although terrible, seems to do the job just fine.

It takes a file and runs through each line. Splits the cost by looking for the £ sign on each line. Then asks who the item is for. Now with the added benefit of being able to do a 25/75 split for items that are used more by one person than the other. It also keeps a running total for each person which is a nice bonus.

Here's an example receipt. This is pasted directly from an email and very little is changed.

You ordered 1 X HECK 10 Meat-Free Magic 300g    £1.75
We sent 1 X HECK 10 Vegan Italia Chipolatas 300g    £1.75

Your order

Fridge  Quantity    Price
Curly Kale 150g 1   £0.50
Greek Style Yogurt 500g 1   £0.75
Soft Cheese 180g    1   £1.95
Fresh Whole Milk 1l 2   £2.80
Ready Rolled Filo Pastry 200g   1   £1.30
Extra Mature Cheddar Cheese 400g    1   £2.00
Fresh   Quantity    Price
Sweetclems 600g 1   £1.29
Freezer Quantity    Price
Frozen Strawberries 350g    1   £1.75
Vegetarian 2 Cheese & Spring Onion Crispbakes 280g  1   £1.50
Straight Cut Chips 1.5kg    1   £2.00
Groceries, Health & Beauty and Household Items  Quantity    Price
Green Beans 240g    1   £0.90
Thick Bleach Citrus Burst 750ml 2   £0.78
Corn Flakes 450g    1   £1.89
Wholewheat Penne 500g   1   £0.53
Maple Syrup 250g    1   £4.50

And here's the Rust code

use std::fs::File;
use std::io::{self, BufRead};
use std::path::Path;
use read_input::prelude::*;
use colored::*;
use currency::Currency;

fn main() {
    let mut one_pays = Currency::from_str("0.0").unwrap();
    let mut two_pays = Currency::from_str("0.0").unwrap();
    let file = std::env::args().nth(1).expect("no pattern given");
    if let Ok(lines) = read_lines(file) {
        // Consumes the iterator, returns an (Optional) String
        for line in lines {
            if let Ok(ip) = line {
                if ip.starts_with("You ordered") {
                    // do nothing
                } else if ip.starts_with("We sent") {
                    let item_text = ip.replace("We sent", "");
                    let split_row: Vec<&str> = item_text.trim().split("£").collect();
                    let length = split_row.len();
                    if length > 1 {
                        let name = &split_row[0].trim();
                        let cost = Currency::from_str(split_row[1].clone()).unwrap();
                        let (one_item_cost, two_item_cost) = ask(name, cost.clone());
                        one_pays = one_pays + one_item_cost;
                        two_pays = two_pays + two_item_cost;
                        running_total(&one_pays, &two_pays);
                    }
                } else if ip.ends_with("Price") {
                    // do nothing
                } else {
                    let split_row: Vec<&str> = ip.split("£").collect();
                    let length = split_row.len();
                    if length > 1 {
                        let name = &split_row[0].trim();
                        let cost = Currency::from_str(split_row[1].clone()).unwrap();
                        let one_item_cost, two_item_cost) = ask(name, cost);
                        one_pays = one_pays + one_item_cost;
                        two_pays = two_pays + two_item_cost;
                        running_total(&one_pays, &two_pays);
                    }
                }
            }
        }
    }
}
fn read_lines<P>(filename: P) -> io::Result<io::Lines<io::BufReader<File>>>
where P: AsRef<Path>, {
    let file = File::open(filename)?;
    Ok(io::BufReader::new(file).lines())
}

fn ask(item: &str, cost: Currency) -> (Currency, Currency) {
    let mut one_pays: Currency = Currency::from_str("0.0").unwrap();
    let mut two_pays: Currency = Currency::from_str("0.0").unwrap();
    println!("Who pays for {}? (£{})", item.bold(), cost);
    let answer: String = input().msg("m/k/b/m3/k3/ignore: ").get();
    println!("You said {}", answer.green());
    match answer.as_str() {
        "m" => {
            one_pays = one_pays + &cost;
            println!("one pays an additional £{}", &cost);
        },
        "k" => {
            two_pays = two_pays + &cost;
            println!("two pays an additional £{}", &cost);
        },
        "b" => {
            let split_cost = cost / 2;
            println!("Splitting cost: one pays £{}, two pays £{}", split_cost, split_cost);
            one_pays = one_pays + &split_cost;
            two_pays = two_pays + &split_cost;
        },
        "m3" => {
            let split_cost = cost / 4;
            println!("Splitting cost: one pays £{}, two pays £{}", &split_cost * 3, &split_cost);
            one_pays = one_pays + (&split_cost * 3);
            two_pays = two_pays + &split_cost;
        },
        "k3" => {
            let split_cost = cost / 4;
            println!("Splitting cost: one pays £{}, two pays £{}", &split_cost, &split_cost * 3);
            one_pays = one_pays + &split_cost;
            two_pays = two_pays + (&split_cost * 3);
        },
        _ => {
            println!("{}", "Invalid answer".red().bold());
            println!("{}", "Press 'i' to ignore".green());
            println!("");
            let (m, k) = ask(item, cost);
            one_pays = one_pays + m;
            two_pays = two_pays + k;
        }
    };
    (one_pays, two_pays)
}
fn running_total(one_pays: &Currency, two_pays: &Currency) -> () {
    println!("");
    println!("{}", "Running Total".bold());
    println!("-------------");
    println!("one: £{}", &one_pays);
    println!("two: £{}", &two_pays);
    println!("-------------");
    println!("");
}

Here's the Cargo.toml

[package]
name = "cost-splitter"
version = "0.1.0"
authors = ["Mitch"]
edition = "2018"

[dependencies]
read_input = "0.8"
colored = "2"
currency = "~0.4.0"

There you have it!

The Dependencies

I used three crates for this project.

Read Input

From what I can tell there's no easy way to read from stdin with Rust out of the box. This crate makes it really easy.

let answer: String = input().msg("m/k/b/m3/k3/ignore: ").get();

Colored

I added a bit of text formatting and colour with this crate.

println!("{} {} {}", "Text".green(), "Text 2".green().bold(), "Text 3".green());

Currency

I used this crate for handling the maths and formatting the output.

let cost = Currency::from_str(split_row[1].clone()).unwrap();

Overall experience with Rust so far

My experience developing this was pretty enjoyable. I was able to get a workable executable quite quickly with the help of the Rust compiler.

I did, however, struggle with a few items.

Using Color with the Currency crate. I gave up on this in the end.
Strings are quite confusing. Not so much ownership which is also a new concept to me, but the various types of strings and when to use them. I tried to create an array of ignored items/lines to output at the end of the execution but couldn't get it working. Hopefully, with experience I'll become more familiar with strings and how to handle this.

What next?

Aside from working on another Rust application I'm considering comparing this development experience with Go or Crystal. Go has piqued my interest—although I have no experience with it. I've used Crystal quite a lot and I suspect writing this application would be trivial in it.

Let me know if you'd be interested in hearing about me port the application to either of these two languages!

My experience being suspended on Twitter

Mitch Stanley — Mon, 22 Jun 2020 08:49:43 +0000

About two months ago I opened Twitter to find a modal message announcing to me that my account had been suspended. I initially thought, that's strange? Is this a bug? What could I possibly have done wrong? Twitter didn't feel it was necessary to give me any details. I was in the dark.

I waited a few weeks. Naively thinking this issue would resolve itself—that it was just a mistake. I could still view tweets from people—although depending on which Twitter client I used I sometimes only saw the last tweets before my suspension took place.

Here are some of other things I've noticed about being suspended:

You cannot download your data.
The suspension modal will popup almost randomly when browing the site.
Notifications will stick. If someone tags you in a tweet (which is still possible) you'll be stuck with this notification forever.
Follower and Following counts reset to zero.

Finally, I caved in and contacted Twitter support. According to their support website it would take 1-2 weeks for a response. I waited patiently. After three weeks I touched base as I thought my ticket was taking quite long to get a response. It was an additional 4 weeks before I finally received one.

Hello,

We’re writing to let you know that your account has been suspended—and will remain suspended—due to multiple or severe violations of our platform manipulation rules.

Please do not reply to this message as this email address is not monitored.

Thanks,
Twitter

My heart sank a little. will remain suspended. severe violations. I've had this account for close to 10 years and there's a lot of history and contacts that I no longer have access to.

After reading the platform manipulation rules I tried to put together what I had done wrong.

I believe because I retweet my side project's tweets this must count as platform manipulation. To be honest, the thought of retweeting my other account as being against the ToS had not occurred to me. I only have myself to blame for not knowing this so I'm not angry about it. I do wish there was a warning system in place rather than going straight to permanent suspension, though.

My social media moving forward

Reflecting on this experience I think it's more important than ever to control my data. Not just on Twitter but on all social media. Twitter, Facebook, Instagram, etc should be a tool to share thoughts and experiences but not the soul source of them.

I have created a new Twitter account (@mitchartemis_v2) but I plan to be more purposeful with this one—to link to my own platforms, be it this blog or others.

Then there's Mastodon which I want to use more of instead of Twitter. I currently have accounts on multiple Mastodon instances and to be honest, I'm not sure whether I should be focusing on using one account or sharing posts on individual nodes related to each of my interests. For example, posting my photography on photography.social, and my programming stuff on ruby.social. Unfortunately I feel this quandary is preventing me from posting anything at all.

That's it for now. Just remember social media platforms control what happens with your data. If that data is important to you then make sure to have a back-up.

Cross-posted from my blog.

How to deploy a Crystal Lucky application with Dokku on Ubuntu 18.04

Mitch Stanley — Wed, 20 May 2020 11:33:11 +0000

UPDATE: A slightly modified version of this article is now available on the official docs! Check them out here

This tutorial will show how to set up an app written in the Crystal web framework Lucky with Dokku on Ubuntu 18.04.

You can run this setup on most low-end boxes. E.g. a $5 Digital Ocean droplet, or in my case, a $2.50 Hetzner Cloud Server.

By the end of the tutorial you'll know how to deploy your own Lucky apps and be able to manage them easily all on one server.

What is Lucky?

Lucky is a web framework written in Crystal. Crystal is a programming language with syntax inspired by Ruby but with speeds similar to that of C.

What is Dokku?

Dokku is a small PaaS service powered by Docker that you can run on your own servers. Think of it as a self-hosted command-line Heroku.

Prerequisites

Crystal 0.34.0 installed locally
A fresh Lucky application installed and running locally.
Basic knowledge of Git.
A server with Dokku Installed using Ubuntu 18.04.
A domain or subdomain to point to the server.

You'll need a Lucky app to deploy. If you don't have one then no problem! A fresh Lucky app comes with several goodies out of the box, a home page and an authentication system linked to a database. This is more than enough to work with. See Getting Started and Starting a Lucky Project. Make sure you have the project commited to git and ready for the first deployment.

Step 1 - Setting up the Dokku configuration

SSH into your server to get it ready for deployment.

ssh root@ip

In the following commands replace app.example.com with your domain or subdomain. Replace exampledb with your preferred database name.

This will create the initial app container in Dokku, create the database, and link them both together. The last three lines set environment variables for the Lucky app. The first will tell Lucky to run the app in production mode, the second will tell Lucky what the app URL is, and the third will tell the app to run on port 5000 which Dokku will connect with Nginx to expose to the world.

dokku apps:create app.example.com
dokku postgres:create exampledb
dokku postgres:link exampledb app.example.com
dokku config:set app.example.com LUCKY_ENV=production
dokku config:set app.example.com APP_DOMAIN=app.example.com
dokku config:set app.example.com PORT=5000

There's a few more configuration details that need to be set. First, you'll need to tell Lucky the database details that are set in Dokku. Run the below command to get the database URL.

dokku postgres:info exampledb

Set the DATABASE_URL environment variable from the above output.

dokku config:set app.example.com DATABASE_URL=postgres://...

Next, Lucky needs a secret key environment variable. In your app directory on your local machine run the following command which will generate a secure key.

lucky gen.secret_key

Then, back on your remote Dokku server add it to the SECRET_KEY_BASE environment variable.

dokku config:set app.example.com SECRET_KEY_BASE=...

If you're planning to send emails through the app you'll also need to set SEND_GRID_KEY key, otherwise, change config/email.cr to use Carbon::DevAdapter.new in production (and make sure to commit!)

dokku config:set app.example.com SEND_GRID_KEY=...

Your server is almost ready for deployment. If you're using a server with 2GB of RAM or less, you'll need to set up a Swap. Without it the deployment process will most likely run into memory issues. Checkout this tutorial for setting up a Swap. A 1G Swap should be more than enough.

Step 2 - Ready the app for deployment

Back in your local app add a new file called .buildpacks with the following contents

https://github.com/heroku/heroku-buildpack-nodejs
https://github.com/luckyframework/heroku-buildpack-crystal

Step - 3 Deploy

Make a new commit. Finally you're ready to deploy. Run the following commands locally. The first will add your server as a remote origin for your git repo. The second will push the code to the server.

git remote add dokku dokku@ip:app.example.com
git push dokku master

Step 4 - Set up SSL

Dokku lets you easily set up a Lets Encrypt SSL certificate. Run the following commands to do so

dokku config:set --no-restart app.example.com DOKKU_LETSENCRYPT_EMAIL=your.email@example.com
dokku letsencrypt app.example.com

That's all there is to it! Each time you push to your Dokku server your app will update and migrations will be ran automatically.

From GhostCMS to Hugo - Snipline's New Blog

Mitch Stanley — Mon, 06 Apr 2020 10:22:44 +0000

I recently switched Snipline's blog from GhostCMS to Hugo. I thought I'd share why I did it, the benefits of GhostCMS and Hugo, and the alternatives that I explored.

You can see the new blog here

The blog looks mostly the same as it did before—using the delightful Casper theme, so why move systems?

Benefits of GhostCMS

GhostCMS is quite simply a fantastic blogging platform. I love the interface and it doesn't try to be something more than that (Looking at you, WordPress). The documentation is good, there are plenty of themes, and most importantly it's open source and self-hostable for free. This is ideal for Snipline, which is a small business that needs to save on costs.

Why Switch to Hugo from GhostCMS?

Faster

I'll be honest and say that speed is the least of my concerns. The blog was already fairly fast, but it's nice to see this minor speed increase.

Here's the Google Lighthouse statistics for the Ghost version of the blog.

And here's the same stats for the Hugo homepage.

Less Maintenance and Responsibility

Using self-hosted GhostCMS means keeping Ghost up to date and dealing with any server issues that crop up.

With Hugo I'm able to use Netlify for free (or any other static hosting service) and most importantly I don't have to worry about uptime or keeping dependencies up to date.

The alternatives that I explored

I've tried far too many static site builders recently. Here's the list:

Preember (Ember JS plugin).
Custom build my own static site generator in Crystal.
NuxtJS
Gridsome
Jekyll
Middleman
Publish

This naturally begs the question...

Why Hugo over <insert-static-site-generator>?

Hugo was my not first choice—I actually circled back to it. At first I found it confusing and overwhelming to work with.

But I've since started reading Hugo in Action which has helped my understanding greatly, and now I'm beginning to become more productive with it.

Preember

I'm a huge fan of EmberJS so I tried building a prototype with Preember. Although generating blog posts was easy enough I had to work against the system to get feeds and pagination in place. That along with the lack of community compared to other systems meant that I didn't think it was worth persuing.

Nuxt.JS

I have had success with NuxtJS on other sites. VueJS (What NuxtJS uses) is a pleasure to work with. I think if I had not chosen Hugo I would have chosen NuxtJS. My only issue with it is that to export to SSG requires extra steps (Telling NuxtJS where to fetch the data and generate dynamic routes). I also do not need the additional benefits and weight of Server Side Rendering and Single Page Applications which Nuxt provides. In Nuxt's defence, I'm not using Hugo as Headless, so using local markdown files may be easier, but I did not explore this option at the time.

Gridsome

Gridsome I tried and initially liked, but it seems to rely heavily on GraphQL—which isn't necessarily a bad thing—I just don't know the technology and so it's another thing to learn. Also, I had this issue where my blog posts would not order by publish date and I couldn't for the life of my figure out why. I gave up out of frustration.

Middleman / Jekyll

I have an extensive past with Middleman, and although I like it, I would rather not continue using it due to dealing with Bundler/nokogiri. Same goes for Jekyll, except I have way less experience with Jekyll!

Publish

John Sundell's Publish looks really promising, and I did get a mostly working prototype working with this. I kind of love the Plot HTML system which it uses. Apart from that, when I was using it, I had to dig into the internals of the code a lot to figure out how to do certain things. This was interesting but time consuming. I think I will keep my eye on this for the future and see how the project progresses.

EleventyJS

Another stack that's recently popped up on my radar is Eleventy.js. This looks promising but I found it a little too late!

Thanks for Reading

So there you have it! Overall I'm satisfied with my decision to use Hugo for this blog and I look forward to using it on future projects.

Perhaps I'll move the main Snipline website over to it sometime in the near future!

Replicating the MacOS Search TextField in SwiftUI

Mitch Stanley — Sun, 22 Mar 2020 15:32:11 +0000

I wanted to add a search text field to a MacOS app that I'm working on and soon discovered it's not available in SwiftUI (as off 5.1). I've put together a quick replication which mostly works, but unfortunately involves some hackiness.

Here's the code:

// This extension removes the focus ring entirely.
extension NSTextField {
    open override var focusRingType: NSFocusRingType {
        get { .none }
        set { }
    }
}

struct SearchTextField: View {
    @Binding var query: String
    @State var isFocused: Bool = false
    var placeholder: String = "Search..."
    var body: some View {
        ZStack {
            RoundedRectangle(cornerRadius: 5, style: .continuous)
            .fill(Color.white)
            .frame(width: 200, height: 22)
                .overlay(
                    RoundedRectangle(cornerRadius: 5, style: .continuous)
                        .stroke(isFocused ? Color.blue.opacity(0.7) : Color.gray.opacity(0.4), lineWidth: isFocused ? 3 : 1)
                        .frame(width: 200, height: 21)
            )

            HStack {
                Image("magnifyingglass").resizable().aspectRatio(contentMode: .fill)
                    .frame(width:12, height: 12)
                    .padding(.leading, 5)
                    .opacity(0.8)
                TextField(placeholder, text: $query, onEditingChanged: { (editingChanged) in
                    if editingChanged {
                        self.isFocused = true
                    } else {
                        self.isFocused = false
                    }
                })
                    .textFieldStyle(PlainTextFieldStyle())
                if query != "" {
                    Button(action: {
                            self.query = ""
                    }) {
                        Image("xmark.circle.fill")
                            .resizable()
                            .aspectRatio(contentMode: .fit)
                            .frame(width:14, height: 14)
                            .padding(.trailing, 3)
                            .opacity(0.5)
                    }
                    .buttonStyle(PlainButtonStyle())
                    .opacity(self.query == "" ? 0 : 0.5)
                }
            }

        }
    }
}

Here's how you use it:

SearchTextField(query: $searchQuery, placeholder: "Search...")
  .frame(minWidth: 60.0, idealWidth: 200.0, maxWidth: 200.0, minHeight: 24.0, idealHeight: 21.0, maxHeight: 21.0, alignment: .center)

Caveats

There are a few issues with this solution. Hopefully in a future version of SwiftUI this will be fixed.

Removing the Focus Ring from All TextFields

This code creates a pretend TextField which holds the magnifying glass, a real TextField, and the close icon inside of it. If you remove the NSTextField extension you'll see the real textfield when focused. It's currently not possible to disable a specific focus ring so you'll have to reimplement them if you need to show them.

Fake Focus Ring Doesn't Update on Focus

You'll notice in the GIF above that the focus ring does not show until you start typing. Not ideal but usable. If anyone has a suggestion for fixing this I'd be happy to know!

No SF Symbols in MacOS

Surprisingly, MacOS does not have native support for SF Symbols! I used this tool to convert them to PNG and import them into my assets catalog. The symbols used are xmark.circle.fill and magnifyingglass.