Motivation

If we’ve got an excellent web application development tool, why do we need desktop applications at all?  It’s a
good question.  And the answer, quite often, is that we don’t.  This is what has made the web such an important
platform, after all.  And also what makes products like Chrome notebooks as popular as they are.  You can
accomplish quite a lot using just web applications, and for many people, it is now possible to get by exclusively
with web applications alone.  Products like TMS WEB Core are making this easier all the time by being able to
develop substantially better applications with access to more data and more systems than ever before.  And without
question, web technologies have come quite a long way in a relatively short period of time.  However, there are
still many situations that come up where the browser sandbox is too restrictive to accomplish certain tasks. And
I’m sure we’re all well aware that the browser sandbox and its rules are in place for very good reasons.  So while
web technologies will continue to evolve, there are some places it just isn’t going to be going anytime soon, and
that’s where desktop apps come in.  Here are a few examples where a desktop application solution might win out
over a web application solution.

• An application needs access to directly read and write to a local filesystem.
• Application data is not permitted to leave a location (IE, saving to ‘the cloud’ poses unacceptable security
  risks).
• An application needs access to hardware that does not have an equivalent (or performant enough) web
  interface.
• Access to the application needs to be more strictly controlled.
• Application changes need to be more strictly controlled (i.e., SOX, ISO9000-type stuff).
• Users work in an environment where web browsers aren’t well-supported.
• Users work in an environment where desktops are strictly locked down in terms of application access.
• An application needs access to OS-level functionality that a browser does not have access to.
• Desire to standardize the application interface (avoiding non-standard browser ‘chrome’ or plugins that
  might interfere).

Granted, there are many kinds of complexity at work here, and no doubt there are just as many ways to address
certain problems.  For example, a web application could be served up within a local network that has no external
access at all, ensuring that data doesn’t leave that location.  And there’s even an evolving web standard for
accessing serial ports.  Crazy, really.  But in any event, there may be solid reasons for having a desktop
version of a web application (or even a mobile version beyond what can be accomplished with a PWA-compliant
application).  Whatever the rationale, Miletus is here to help address it.

Getting Started

For our example application, we’re just going to carry on with the Leaflet
example that we covered a couple of days ago, an almost minimalist interactive mapping web application. 
It has been updated slightly to fix a few minor internal errors, to be more ‘responsive’ and resize to fit its
container, and also to have a slightly improved geofence data entry interface, where you can cancel the
entry, see the points as a polyline while you’re entering them, change the color of the geofence created, as
well as delete geofences.  To get this all working, we start by creating a new TMS WEB Core Miletus project from
the regular list of templates. 

TMS WEB Core Project Templates

This creates a new blank project as expected. The first thing that is noticeably different is that there are a
few more Build Configurations available.  Note that this project was created using TMS WEB Core v2.0.0.2 and
that the list of available Build Configurations is likely to change over time.

Miletus Build Configurations

For today, we’ll be focusing just on the Win64, Linux64, and MacOS64-Intel variants.  We can test it out right
away by just adding a TWebButton to the form and running the project.  By
default, it creates a Win32 executable that launches and displays the button.  Here’s what it looks like.

Basic Miletus App

This was created in ‘debug’ mode, so there are some extra menu items available.  One small curiosity is that it
takes a bit of time for the button to appear, presumably because some kind of browser library is being loaded in
the background. These processes can be seen in Task Manager.  Restarting the app shows the button almost
immediately, so perhaps not a big issue, either way, just a curiosity.

The compiled binary file is a Win32 executable that is about 9.6 MB in size.  Being a Win32 app also means that
it can be compressed with tools like UPX,
something I’ve used when deploying my regular Delphi projects for as long as I can remember. There are various
tradeoffs to such tools, with a big one being that it tends to make antivirus and antimalware software throw
fits.  Whether that is a good or a bad side effect is perhaps an interesting debate.  In any event, running UPX
against this binary shrinks it down to a more palatable 3.6 MB without any discernible difference.

We’ve Got Options

If you had a chance to read the last article in this series about TMS
WEB Core PWA applications, you’ll recall that there wasn’t much difference visible in the project until we
got a look at the project options.  Same deal here, where things look sort of the same, but with an updated list
of options where we can set things like icons for the various platforms.  Much like the PWA scenario.

Miletus Project Options

These should be mostly familiar by now, with nothing for us to change at the moment, but be sure to keep these
in mind when deploying apps with proper icons and so on. There is an option to ‘Start Miletus with developer
tools’ which will launch another window automatically.  This same window can be launched from within the app. 
This is where the usual browser console can be found, for example.

Converting An Existing Project to Miletus

It is a relatively trivial project in this case, but to move our Leaflet example into the Miletus project, it, unfortunately, wasn’t as simple as just copying the unit over.  Fortunately, this is a very small project, so
recreating it inside a Miletus project was not difficult. It seems a Miletus form is different from a regular
form, but perhaps that can be adjusted just by changing the form definition. Something to try another day. For
now, we can just create the handful of controls and be on our way.  A few FontAwesome icons were added to the
mix, and the layout was upgraded a little.  We also have to remember to copy over the changes that we made to
the Project.html file and because this wasn’t created as a Bootstrap project, we’ll have to add that in as well.

With those in place, we can just run the app and get our updated Win32 Project1.exe file. 

Leaflet Example as a Miletus Win32 App

This works pretty well. Debugging via the console is available, just be aware that the underlying browser is
now Edge instead of whatever other browser you might have been using.  It is functionally equivalent to Google
Chrome, though, so not something to be terribly concerned with.  The generated Project1.exe clocks in at about
the same 9.6 MB as one might expect, given that the project is so very small.

Building Win64

To get a Win64 version, not much effort is required.  Double-clicking on the Build-Win64 entry (or Debug-Win64
if you prefer) in the Build Configurations list is about all that is needed here.  In the TMSWebBuild-Win64
directory, there is now a Project1.exe and its support DLL, WebView2Loader_x64.dll.  It of course looks
identical to the Win32 version but is now around 13.8 MB instead of 9.6 MB.  Running it through UPX also works,
resulting in a compressed EXE that comes in at around 4.1 MB.

How do you tell a Win32 executable from a Win64 executable? There are a few ways.  One is to add ‘Platform’ as
a column in Task Manager, making it easy to tell which version is running.  Note that for some reason, running
both Project1.exe versions simultaneously didn’t work, but if one was renamed it worked fine.  In this case, the
Win64 version was also put through UPX.  

Another way is to right-click on the executable in Windows Explorer, select Properties, and then have a look at
what Compatibility options are available.  Win64 executables will only offer Windows 7 and later options,
whereas Win32 executables will offer options going all the way back to Windows 95.

Building Linux64

The same approach is used here.  Double-clicking on the Build-Linux64 entry (or Debug-Linux64) in the Build
Configurations list and then running the project creates the expected executable file in the
TMSWebBuild-Linux64 directory. This comes in at around 25.6 MB.  UPX also works here, compressing it down to
about 7.2 MB. The Linux system I have currently is Fedora 33 running KDE, so not the most current or the most
popular anything, really.  There are some Linux prerequisites to get this to work.  GTK and WebKit are likely
the biggest ones. Also, it required an SSL connection to the mapping provider and doesn’t even prompt (or allow)
the local location to be looked up.  Likely something that could be resolved, but wasn’t working immediately.
Other Linux distributions will have their own systems for updating libraries and dependencies, but for Fedora, they
look like this.

sudo dnf install gtk3-devel
sudo dnf install webkit2gtk3-devel

With those in place, launching the executable works pretty well.  Here’s a screenshot of what it looks like. I
think something is amiss with the rounded corners of the actual map.  A little fiddling didn’t seem to produce
any changes in the output, so another item for the to-do list.  It otherwise works
fine. 

Leaflet Example as a Linux64 app

Determining whether a Linux executable is 32-bit or 64-bit can be accomplished just using the ‘file’ command. The
first is what is produced directly, the second is after it has been run through UPX.

# file Project1
Project1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e64a7f5c4dd2dfb5cbc38487c60f5bf5e1cd9695, stripped

# file Project1-Linux64
Project1-Linux64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, no section header

Beyond that, the browser developer tools also work and are embedded within the window rather than displayed in
a separate window as is done under Windows.

Miletus Linux64 with Developer Tools

Overall this works pretty well, all things considered.  No need for anything outside of Delphi to create the
executables and once created, nothing really to do when it comes to deploying them.  There’s even an icon
created for the Linux desktop. 

Building macOS

Same deal here, and naturally no dependencies or other issues when deploying to the Mac.  In this example, it is
running on macOS Mojave.  I don’t know if there is a UPX equivalent for MacOS, but the app bundle in this case
(for the Debug version) came in at around 41.7 MB.  It seems to have the same issues with rounding as the Linux
version, but that could be related to the fact that they are both using WebKit instead of Chrome, but nothing to
be too alarmed about.  Well, I’m alarmed, but not likely of general concern.  In any event, here’s what it looks
like.

Miletus Example running under macOS Mojave

Again, as with Linux, nothing else is needed other than Delphi and TMS WEB Core to produce the macOS
executable.  This is quite remarkable really, as most solutions to this kind of problem require access to Xcode
to compile the project.  macOS build options also include both Intel and ARM, so it seems that we’re already set
to work with the latest M1 and M2 hardware.  The menu appears as a usual MacOS-style menu at the top.  However,
I didn’t see an option to show the developer tools interface.  Another item for the to-do list.  The “Find Me”
option also wasn’t working here.

A Solid Start

And with that, we’ve got our app running as a web page, potentially even as a PWA, as well as on Windows, Linux,
and macOS.  That’s quite remarkable, really!  No small feat. That covers quite a lot of use cases, and even the
PWA option could cover most mobile use cases if necessary.  So with one set of source code, we’ve basically got
an app that runs on nearly every modern environment. Download the full source code of this sample project here. Future posts about Miletus will explore some of the
OS-specific options that are available beyond what TMS WEB Core can do in the browser.  And we’ll have an
in-depth look at Raspberry Pi as well.