Proton Mail finally released a beta of its web application as a stand-alone application for the Linux desktop earlier this week. After being gently prompted by the website when I last opened web-based Proton Mail, I downloaded the stand-alone  deb file and installed it.

This is a beta release, so it’s not functionally complete. This means, for example, I can’t select a dark scheme for the application. I have done this on the web-based version. Being a beta there are other, minor (to me) missing features, but overall it works pretty much the same way as the web-based side of things, at least as far as I can tell.

The biggest issue for me is speed. The stand-alone Proton Mail is slower, and at times notably slower than the in-browser application, and I have to wonder if it’s because web browser Proton has the remote server doing most of the heavy lifting of mail processing. I’m also now wondering if Proton Mail is based on Google’s Flutter framework, and if the desktop version isn’t a recompile of the web-based version. I’ve dabbled with Google’s Flutter in the past and done something similar, i.e. built a web application using Flutter’s Visual Studio Code plugin and then flipped the switch to build a stand-alone version. I wasn’t all that impressed at the time. If this is how we got Proton Mail desktop then I’m still not all that impressed with Flutter.

This is the second mail desktop application I’ve installed and tried on the Linux desktop. The first is Thunderbird, the spin-off from Netscape Navigator’s web browser suite from back in the early 2000s.

As you can see with the Thunderbird example above, I like my dark themes. I also like with Thunderbord how I can compress folder listings into one mail entry per line, unlike Proton Mail (both web and application) that will only shrink down to two lines/entry, via what is called Density in the Settings panel. But that’s a minor nit, compared to other issues. While I still have Thunderbird installed and fire it up on occasion, my biggest complaint with Thunderbird and the reason I seldom use it is how much in resources it uses when it’s up and running on my system. I’m better off reading my Google mail in a browser than in Thunderbird, even though it means I have a browser with may open tabs being dragged along. My primary browser of choice on my Linux Mint desktop is Firefox (123.0.1), which in spite of the lies the many Firefox haters like to spew, runs quite efficiently and performant for me.

While I always recommend Proton Mail to whomever asks, I can’t recommend these newest Proton Mail desktop applications. In the third decade of the 21st century, working with mail in a browser tab is no longer the issue it was in the first decade of the 21st century. We have come a very long way in that regard. Going back to a stand-alone mail application wasn’t something I was asking for, and looks too much like a step backwards.

Note that I did not install support for Android (Android SDK and Android Studio) nor the Web (via Chrome). All I’m doing is writing Flutter desktop applications.

The Flutter plugin within VSCode automates quite a lot. Using the VSCode Command Palette, you can create an initial Flutter application (Flutter: New Project) that will create skeleton code and build files that compiles and runs the graphical equivalent of hello, world.

As you can see, the Flutter tools for both the framework and the VSCode plugin provide an effortless on-ramp to developing applications. Creating the start of an application is ridiculously easy, and it’s capable of building and executing from the get-go. One feature this has and I use quite a lot is hot reload. When I make changes to the code, when I save the changes they’re rebuilt and the running application restarted immediately showing those changes. That’s why I use this setup.

And here is the initial application’s extremely simple desktop window. When this works well, it’s a little like magic.

Unfortunately I ran into a problem where Clang, one of Flutter’s dependencies, could not link a C++ application that is part of the Flutter application. The error message reported by the Flutter tooling was (with much superfluous reporting snipped away):

.../usr/bin/ld: cannot find -lstdc++: No such file or directory...

This really annoyed me because I have this same setup on my other Linux Mint system, the UM250. With a bit of googling I discovered what was wrong, and how I’d accidentally side-stepped the issue on the UM250. I solved the problem on the Series 7 with sudo apt install libstdc++-12-dev. After that the Flutter tool chain just worked.

Why didn’t I see this issue on the UM250? Because I’d installed gcc/g++ version 12 to support another small project I was working on. On the UM250 I have both versions 11 and 12. Then when I later updated an older installation of Flutter and ran the same simple tests, everything worked there as well. I don’t intend to install gcc/g++ version 12 on the Series 7 as there is no need.

What I don’t understand is how Clang and GCC got out of sync on Linux Mint 22.1. The version of Clang installed is version 14, and requires libstdc++-12. Unfortunately Linux Mint 22.1 installs GCC version 11, which means that if you wanted to build with Clang you’re out of luck unless you know of Clang 14’s dependencies.

This came across my radar entirely by accident. Someone or a group of someones out there has added Python wrappers around Google’s Flutter ( https://flutter.dev ) and called it flet ( https://flet.dev ). If you have Flutter installed already (and I have version 3.3.10, which is current) you can install the Python Flutter module with pip install flet, and then start writing desktop applications with it. I came across this application example here: https://betterprogramming.pub/building-a-markdown-editor-previewer-with-flet-7d9b06d6dc4b . I typed it all in myself, and here is my copy of the original author’s listing.

#!/usr/bin/env pythonimport fletdef main(page: flet.Page):page.title = "Markdown Editor"page.theme_mode = "dark"def update_preview(event):markdown.value = text_field.valuepage.update()page.appbar = flet.AppBar(title = flet.Text("Markdown Editor", color=flet.colors.WHITE),center_title = True,bgcolor = flet.colors.BLUE,)text_field = flet.TextField(value = "# Hello from Markdown",multiline = True,expand = True,height = page.window_height,border_color = flet.colors.TRANSPARENT,on_change = update_preview)markdown = flet.Markdown(value = text_field.value,selectable = True,extension_set = "gitHubWeb",  on_tap_link = lambda event: page.launch_url(event.data),)page.add(flet.Row(controls=[text_field,flet.VerticalDivider(color=flet.colors.RED),flet.Container(flet.Column([markdown], scroll = "hidden",),expand = True,alignment = flet.alignment.top_left,)],expand = True,))flet.app(target = main)

For testing purposes I used this page for the examples on the left of the application: https://www.markdownguide.org/cheat-sheet/ . Although the author called this an editor, it’s missing quite a bit of functionality, such as the ability to open and save your work. Right now it’s just a proof of concept that shows how easy it is to write GUI applications in Python and Flutter, and a way to exercise flet’s built-in Markdown module (see lines 28 to 33). The only problem so far is that Flutter is spitting out a warning message when the Markdown demo application is closed, but other than that it appears to be a decent little demo.

Will I add more functionality? Who can say? Right now I’m working with Qt 6.2 and C++, but the fact this is written with Python is a very strong draw to me. I do think this is very cool.

I can assure you that if you do not have the latest tools, and you have a Java version later than Java 8, then a part of flutter doctor will fail when you try to use flutter to accept the Android SDK licenses. It’s confusing, but for whatever reason those licenses are not set when you install the Android SDK either from the command line or via Android Studio. The problem is that the older sdkmanager command line tool expects to work only with Java 8 (and why that is is to convoluted for this short post, but trust me, it will fail). So make sure you use Android Studio’s SDK Manager section to install those latest tools.

Once all the bits are in place, this is what you will see with a proper doctor report.

Of interest to me is how this will work developing tools for Ubuntu-based Linux distributions. There’s another feature that’s piqued my interest I want to try, and that’s developing on a Chromebook under Chrome OS. That adventure can wait until I get some time with Flutter 3 on Linux.

Even more good news. I’ve gotten the tutorial to operate in an Android emulator on my Mac. After all the updates, including an update to the Android emulator, I was able to launch the emulator as a Pixel 2 XL running Android 7.1 (API 25). Interestingly enough I couldn’t configure an emulator using any of the Pixel 3 smartphone’s; there were none in the AVD manager. The Apple emulator, by contrast, has the latest iPhone XS and XR variants. But at least it works and validates Flutter’s claim that the same application developed in Flutter will run on both iOS and Android.

One quirk getting this to run. When I opened the tutorial back up, VS Code flagged the import of english_words.dart package. I had to re-run ‘flutter packages get’ in the tutorial folder and then restart VS Code. After that it was satisfied.

Williams-MBP:~ wbeebe$ flutter upgradeUpgrading Flutter from /Users/wbeebe/Develop/flutter...From https://github.com/flutter/flutter   7a88fbc5f..985ccb6d1  dev   -> origin/dev * [new branch]  logo-tos  -> origin/logo-tos   faae8bde7..517f8dc27  master-> origin/master * [new branch]  mit-mit-patch-1   -> origin/mit-mit-patch-1 * [new branch]  revert-23424-dragfix2 -> origin/revert-23424-dragfix2 * [new branch]  revert-26090-switch_to_dev_finder -> origin/revert-26090-switch_to_dev_finder * [new tag] v1.1.5-> v1.1.5 * [new tag] v1.1.8-> v1.1.8 * [new tag] v1.1.6-> v1.1.6 * [new tag] v1.1.7-> v1.1.7Already up to date.Upgrading engine...Already up-to-date.Flutter 1.0.0 • channel stable • https://github.com/flutter/flutter.gitFramework • revision 5391447fae (6 weeks ago) • 2018-11-29 19:41:26 -0800Engine • revision 7375a0f414Tools • Dart 2.1.0 (build 2.1.0-dev.9.4 f9ebf21297)Running flutter doctor...Doctor summary (to see all details, run flutter doctor -v):[✓] Flutter (Channel stable, v1.0.0, on Mac OS X 10.14.1 18B75, locale en-US)[✓] Android toolchain - develop for Android devices (Android SDK 28.0.3)[✓] iOS toolchain - develop for iOS devices (Xcode 10.1)[✓] Android Studio (version 3.2)[✓] IntelliJ IDEA Ultimate Edition (version 2018.3.2)[!] Connected device! No devices available! Doctor found issues in 1 category.

You’ll note my biggest gripe is fixed now, the inability to apparently determine if the iOS (sub) toolchain was actually sane. Another minor but welcome fix was for the Android toolchain. The Android toolchain incorporates the Android SDK. In the past flutter doctor would complain that the Android licensing was inconsistent/incorrect. The workaround before this drop was to go and re-run sdkmanager (tools/bin/sdkmanager) and then re-run ‘flutter doctor’. That seemed to fix the Android toolchain issues. I’m not worried about the connected device because right now there is no connected device, and so this error message is correct. Again, these are welcome changes.

This morning I upgraded flutter again and got the following:

Williams-MBP:~ wbeebe$ flutter upgradeUpgrading Flutter from /Users/wbeebe/Develop/flutter...From https://github.com/flutter/flutter   985ccb6d1..1407091bf  dev-> origin/dev + af09490e1...40c4925a5 gallery-> origin/gallery  (forced update)   517f8dc27..6c7fb8805  master -> origin/master * [new tag] v1.1.9 -> v1.1.9Already up to date.Upgrading engine...Already up-to-date.Flutter 1.0.0 • channel stable • https://github.com/flutter/flutter.gitFramework • revision 5391447fae (6 weeks ago) • 2018-11-29 19:41:26 -0800Engine • revision 7375a0f414Tools • Dart 2.1.0 (build 2.1.0-dev.9.4 f9ebf21297)Running flutter doctor...Doctor summary (to see all details, run flutter doctor -v):[✓] Flutter (Channel stable, v1.0.0, on Mac OS X 10.14.1 18B75, locale en-US)[✓] Android toolchain - develop for Android devices (Android SDK 28.0.3)[✓] iOS toolchain - develop for iOS devices (Xcode 10.1)[✓] Android Studio (version 3.2)[✓] IntelliJ IDEA Ultimate Edition (version 2018.3.2)[!] VS Code (version 1.30.2)[!] Connected device! No devices available! Doctor found issues in 2 categories.

Now the complete toolset is tracking Visual Studio (VS) Code, the editor/minimal IDE. Thinking I needed to update VS Code, I checked my version of VS Code, and guess what?Yep, I’m running with the latest production release. A quick check showed that all the installed plugins were up to date as well. Then I re-ran ‘flutter doctor -v’ and got the verbose output. This is part of what I got on that run.

[!] VS Code (version 1.30.2)• VS Code at /Users/wbeebe/Applications/Visual Studio Code.app/Contents• Flutter extension not installed; install from  https://marketplace.visualstudio.com/items?itemName=Dart-Code.flutter

Sure enough I was missing the Flutter extension. Don’t ask me how, but re-installing the extension and then running ‘flutter doctor’ again produced the following cleaner output:

Williams-MBP:bin wbeebe$ flutter doctorDoctor summary (to see all details, run flutter doctor -v):[✓] Flutter (Channel stable, v1.0.0, on Mac OS X 10.14.1 18B75, locale en-US)[✓] Android toolchain - develop for Android devices (Android SDK 28.0.3)[✓] iOS toolchain - develop for iOS devices (Xcode 10.1)[✓] Android Studio (version 3.2)[✓] IntelliJ IDEA Ultimate Edition (version 2018.3.2)[✓] VS Code (version 1.30.2)[!] Connected device! No devices available! Doctor found issues in 1 category.

Which is what I would have expected. I’m glad that they’re checking VS Code and the Flutter extension, but if there is a problem with the Flutter extension (or any other extension that Flutter depends upon) then they should surface that directly, rather than the current cryptic “You’ve got a problem” error message. Like the connected device message directly below it.

I’m going back into using Flutter for app development instead of using it as an excuse to run tutorials. I’ve got at least two small projects in mind to use this tool on.

The definition of insanity is doing the same thing over and over and expecting different results.

I’m giving up on Flutter. After finally getting everything installed, configured, and mastering the basic tutorials (see here), I managed to get several demo apps running on the iPhone X simulator. And then, with the release of Flutter 0.11.13, it all went to hell in a handbasket. Flutter doctor is now producing the following:

Doctor summary (to see all details, run flutter doctor -v):[✓] Flutter (Channel beta, v0.11.13, on Mac OS X 10.14.1 18B75, locale en-US)[✓] Android toolchain - develop for Android devices (Android SDK 27.0.3)[!] iOS toolchain - develop for iOS devices (Xcode 10.1)✗ Verify that all connected devices have been paired with this computer in Xcode.  If all devices have been paired, libimobiledevice and ideviceinstaller may require updating.  To update with Brew, run:brew updatebrew uninstall --ignore-dependencies libimobiledevicebrew uninstall --ignore-dependencies usbmuxdbrew install --HEAD usbmuxdbrew unlink usbmuxdbrew link usbmuxdbrew install --HEAD libimobiledevicebrew install ideviceinstaller[✓] Android Studio (version 3.2)[✓] IntelliJ IDEA Ultimate Edition (version 2018.3)[✓] Connected device (3 available)

I followed the brew directions not once, but twice. I then went and deleted the entire flutter folder, downloaded the current zip file, unzipped it, and ran Flutter doctor again. Same issue.

I have neither the time nor the patience to go trolling through fora on the Internet trying to find the magic solution. I’ve got better things to do with my time. So, here’s what I’m going to do. I’m deleting Flutter again, and when it’s finally officially released, maybe I’ll try it again. But until then I’ll stick with XCode on my MBP.

Update 4 December

Google announced the release of Flutter 1.0 today. Downloaded it, unzipped it, same issues as with the beta. Deleted it again.

I’ve reached the end of the Flutter introduction, having produced an “app” that will supposedly work equally well on Android and iOS. Nothing out of the way to report, as part two of the exercise was clear and correct. I even went back and removed the code that produced the “Welcome to Flutter” header. Now the app is cleaner looking with only one header.

The good news is how so many different parts worked together to accomplish this: XCode (the Apple iPhone simulator), VS Code (Microsoft’s powerful open-source editor with plugins), and Flutter (Google’s development tools with additional support via Brew). If you dig a little deeper into how VS Code is built, you’ll see that it’s built on the Electron framework which is itself based on Node.js and Angular. So there’s a lot of integration of disparate languages and supporting tools into a non-trivial cohesive working whole. I’m suitably impressed.

Unfortunately for me, I couldn’t test how this looks on an Android device. I couldn’t get the Android emulator to work from the command line, even though I powered up Android Studio and used it to install SDK support for Android 9/Pie. Using Android Studio I also started the Android Virtual Device manager to create a Pixel 2 XL Android device to simulate, but unfortunately not the current top end, the Pixel 3 XL. This apparent lack of latest device support, along with the inability to launch the emulator from the command line (required if using VS Code to develop), almost makes the use of Flutter a pointless exercise, at least for me.

Yes, I was able to “develop” the app (or act as a code copying monkey from web page into the source code with the larger blocks of code). And it was interesting to see it run flawlessly on the iPhone XS Max emulator with the latest iOS version (12.1 as of 30 October). So there was that. I was also exposed to an alternative method for writing apps, which involved Javascript/Dart, so that was also a good thing. It really is good to try alternatives.

But being able to easily, seamlessly, develop for both Android and iOS on the same computer (running macOS in this case), that was a failure for me. And in order to do that kind of development you need to work on macOS, because you won’t run the Apple iPhone simulator on Windows 10. Or not that I’m aware of. And possibly solving the problem by developing within Android Studio instead of VS Code is a non-starter with me, unless I were being paid to do this, and then I would (might) begrudgingly switch. But on my own nickel, nope.

Prior Posts

getting started with flutter on macos mojave
getting started with flutter on macos mojave, part 2
getting started with flutter on macos mojave, part 3

I moved on to the next step in the Flutter getting started tutorial, managing to create a new app project with a bit more functionality.

While the directions were for the most part correct and complete, they were a bit murkier in some spots than in the earlier tutorial sections. In particular:

• Before you create a new project, close the prior project by closing VS Code. If you create a new project with the old project still open then VS Code will spawn a new window with the new project, detached from the simulator. Just close VS Code and reopen it, then create the new project for this step.
• In Step 1 you’re advised to “delete all the code from lib/main.dart”. That’s wrong. Do that and you pretty much cripple the entire project. Instead delete class MyApp’s build() method in the project and copy/past the build() method code in the tutorial into its place.
• In Step 2 you learn to add and reference an external package. The writer assumes you’re using Android Studio when you update pubspec.yaml. Since I’m in VS Code, when the instructions tell you to click “Packages get” in Android, press [Shift][Command][P] (remember I’m on a Mac) to bring up VS Code’s Command Palette (the menu View | Command Palette… does the same thing) and type “Flutter: Get Packages” to perform the same exact function.

The rest of the steps were uneventful and correct. At the end I had a working app that looked exactly like the view in the tutorial running in the simulator. Hurray for me.

It’s been a little while since getting all the Flutter bits installed, running, and working together. I finally found a few moments this Sunday morning to spin it up and go farther into the Flutter Getting Started demo on the Flutter website.

I’ve gotten into the habit of running ‘flutter doctor’ every time I open a shell because I’ve found that, for whatever reason, the Android SDK licensing check gives me an “Android license status unknown” for 26.0.2, even though I run tools/bin/sdkmanager from the shell. That seems to clear up any licensing issues, at least from the command line. Run ‘flutter doctor’ from within Visual Studio Code and it pops back up again.

Another problem is with libimobiledevice, a library that is a royal pain to get installed cleanly along with its dependencies. And you need that to talk to XCode and Apple mobile devices. The last time I had a problem with libimobiledevice I finally got it straightened out with ‘brew doctor’ and then installing libimobiledevice yet again. So far, right now (as you can see above), everything is OK.

My second set of initial impressions:

• I got this up and running without writing a single line of code so far. The app running on the iPhone simulator is equivalent to your “Hello world” examples everywhere else.
• It is interesting that I’m using Microsoft’s editor to debug an iOS application in an Apple simulator running on macOS. If I were really into cross-development I’d use the Android simulator as well, and I have no doubt it would work.
• Hot reload works a treat. Starting the simulator takes more than a few seconds, but hot reload is very fast and does not require a simulator restart.

My overall impression is that it is very much still a work in progress. It feels fragile, especially when the Flutter doctor keeps reporting Android licensing and imobiledevice issues at odd times, either at the shell or within Visual Studio Code.

Having said that, it’s remarkable to see all this major systems lashed together into a decently working development environment. There is great potential in Flutter. If I can write better iOS applications within Flutter and do so with less frustration and at a faster pace, then I’m all for this and want to see it succeed. In the past, app development has (and still is) heavily siloed, where you get the development environment unique to each platform (XCode for iOS, Android Studio/IntelliJ for Android) and dealt with cross-platform development as best as possible. Now we’ve got the emergence of Flutter with its largely open source underpinnings. As long as Google keeps serious Flutter development going to at least a solid 1.0 release, then I think it will succeed.

And I personally want to see it succeed.

A minor victory for me tonight. I got Google’s Flutter (version 0.9.4 beta) installed with all the bits on macOS Mojave. It would appear that everything is working and working together. The command ‘flutter doctor’ with the iPhone XS Max simulator running is happy, not having found any problems with all the bits and pieces that make up the totality of Flutter development. Back when Flutter was first announced as ready for prime time, around the version 0.5 beta release, I tried and failed to get everything to work. I let it go for a while as I had plenty to keep me busy IRL. Now, after following the directions at https://flutter.io/setup-macos/, it looks like the tools are more stable and robust and the directions actually work without having to go hunt down why some critical step failed.

Long term goal is to get back into developing applications across both iOS and Android, but without the crazy idea of having the application look the same on both devices. That just doesn’t work. Flutter developers seem to realize that a Flutter developed app should look like an iOS app on an iPhone and an Android app on an Android phone. And there appears to be a lot more for Flutter to offer an app developer, which I’m interested in investigating.

For the time being I’m happy to get this far. Note that I have an iPhone XS Max simulator running on my macOS desktop. This is about as close as I’ll get to the real thing.

Hopefully a bit more to come.