Per-app MSI-based installers

[John Layt]

On 2 July 2014 23:04, Kevin Funk <kfunk at kde.org> wrote:
> On Wednesday 02 July 2014 20:53:14 John Layt wrote:

> Currently, the "barrier" for people on Windows trying KDE applications is to
> find out that a) there *isn't* an installer for that particular application
> he/she wants, eventually find out that there is some central installer, go
> through that, select the correct packages and hope that everything
> downloads/installs correctly. I can completely understand that people are
> reluctant to go through that and instead just look for alternatives that have
> a "normal" installer and "just work".

Yes, discoverability is a big issue, and as a test my asking a new
user to try find the installer for an edu app went nowhere very fast.
But that's not an argument for single installers, it's an argument for
better website management.  We need to clean up our websites a *lot*
to simplify things, we have too much confusing jargon trying to
explain the "Why" when users just want the download link.  Another
problem is most apps are too scared to provide a direct link to the
current Windows installer from their home pages given how scary an
experience it is, and how we keep saying it's only beta.  That is a
good argument for single app installers.

I think we all agree that single app installers linked from home pages
and kde.org/applications are the best way, I think we're more
discussing the right way for those installers to perform in the
background.  Any app store would just be a way of providing access to
those installers.

> Things like the KDEWin installer are unfortunately completely unexpected for
> the average Windows user. And before trying to force the Linux way onto them
> regarding package management, you first have to convince them that it is worth
> to learn it. (By showing off your applications via making it easy enough to
> install them.)

I'm not arguing for a Linux-style package manager front-end, I think
those are a poor option for users on Linux too.  I'm talking app
stores that hide all the scary stuff from users and manage it in the
background for them, like the Ubuntu Software Centre.  However my
thinking now is that we don't want a downloadable app store (at least
not yet), a web-based directory would be better using AppData to build
kde.org/applications pages which provide direct links to the
installers for Win, Mac, the Android store and the project home page.
It's the installers that should manage the library dependency stuff in
the background.

> You're talking about 100 MB of disk space in conjunction with "for the more
> well off"? Really, that's not an argument. Disk space *is* cheap. And I'm sure
> we can get the installer sizes far below 100 MB (stripping out icons, unneeded
> common data, etc.)

You can't say you want to maximise the potential KDE on Windows user
base, and then exclude people with limited bandwidth and storage, it's
a real issue even here in the UK.  Some people just don't have the
money, or just don't feel it's a necessity to update, but they still
want some nice edu apps for their kids.  Equally, I can't insist on
network-based installers when a significant user base could be
bandwidth-limited or offline users.  And someone still has to pay for
serving all that data.

I'm sure we can reduce the size, Marble for Windows (without KDE libs)
is only 25MB, the test Okteta is 21MB, so sizes will be smaller, and
once Nicolás finishes his experiments the issue may well be moot.  We
just need to be able to justify the size of the download for the
benefit the user will get, especially if they see a competing free
product is smaller.  Notepad++ is a 9MB download.  Paint.net is 6MB,
only downloading .Net in the background if needed.  Skype is 1.6MB,
but downloads lots in the background.  Picasa is 16.5MB.  Firefox is
30MB.  Acrobat is 40MB.  So 25MB may well be acceptable for most apps.

>> We have the same argument on Mac where most apps are distributed as a
>> complete bundle, but what about Android or iOS or Blackberry where
>> users do get jealous of every MB that an app takes up?
>
> That's not really an argument either. That's desktop Windows vs. mostly
> tablet/phone OSes. And on these OSes the system even limits you in how to
> distribute the application (no inter-package library dependencies possible or
> similar)

So what of Ministro on Android?  I do worry about huge packages on
mobile platforms, as I know plenty of people with low-end Androids
with little memory and no SD expansion who regularly cull apps they
see as taking too much space.  In a choice between Angry Birds and
KGoldRunner, both taking 50MB storage, the birds would win.

But even with everything bundled into a single package, my point about
a shared process on all platform still stands, as the exact same
minimal set of resources will need to be determined and packaged for
each platform, if we have different tool chains for doing that on
every platform then we're wasting our limited resources.

> Sure. But if you seriously want to target 5 different platforms, you *have* to
> spent some time on polishing your app on each of them. And that also means
> polishing and testing your package on each platform. You can't just make it
> compile on that platform and hope everything will just work.
> Of course, we should provide tools which make this is as easy as possible.

Yes, we need to polish for each platform, and solve integration
issues, and many more things besides that we just don't have the
people to do.  We need to make sure as much of it as possible is
shared tooling as part of the build system so devs only have to worry
about appearance and functionality.  I do think if we get our apps
onto those platforms first though, then we can attract more 'native'
devs to help do that polish (and yes, that is an argument for taking
the quickest native solution).

> - I definitely want single-app *standalone* application installers on Windows

I think we all agree on that.

> - Make these installers as robust as possible
>   (i.e. by *not* downloading dependencies, as this will likely
>   cause more headaches when debugging what's going wrong)

Downloading bits in the background is a commonly done thing on Windows now.

> - Make it standalone. MS Windows mostly stays backwards compatible,
>   hence these installers could stay intact for a wider audience
>   for a long time
>   (just take a look at packages such as gnuwin32 [1],
>   which are dead old but still work)

And confuse me no end when looking for an gnuwin32 installer :-)
Leaving old installers around is usually bad news.

> - The KDEwin installer should definitely stay, for power users,
>   such as for teachers wanting to install the complete Edu suite or similar,
>   just like John mentioned.

I'm not so sure, or at least not as well advertised anyway.  Having
two different ways to install apps could get confusing, both for the
users and for the support forums, especially if someone installs
different versions of the same app from both the old installer and the
new one.  It's also more code to maintain with limited resources.  I
think its one or the other.  For 'bundled' installs a single module
level installer seems a better bet to me.

One option is to adopt the Microsoft model and offer both "Network"
installers and "Offline" installers.  The offline installer has
absolutely everything packaged in it and is guaranteed to work offline
anywhere.  The network installer just ships the apps main requirements
and then offers download options for things like translation files,
dictionaries, etc.  Note that shared versus standalone libraries are a
different issue to offline/online, you can have offline installers
that still use shared libraries.

So, getting away from the philosophical stuff, it seems there's two
points of contention, so perhaps we should try focus on those:
1) Do we use a shared library model or a standalone library model?
2) Do we use the offline installer model, or do we use online
installation options?

Quick question: what of the Qt Installer Framework? It being Qt based
can be both a good and bad thing, but it supports Win and Mac.  It
also has an online updater built into it?  Does anyone have any
experience with it?

Cheers!

John.