Per-app MSI-based installers

[John Layt]

On 2 July 2014 19:44, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Wed, 2 Jul 2014, John Layt wrote:

> It would, perhaps, be more useful to have a way to figure out which icons
> are actually used by a given application in an automated way and delete the
> rest. That's more tailor-made than splitting them in tiers.

That would be a useful tool, and works well both for the full-fat
installer option and the shared library option.  It's tooling like
that that will be needed to make that this practical on a KDE-wide
scale.

> Right now, my goal for Windows is a second installer package that installs
> all translations right into my application's installation directory.

Hmmm, could the main installer ask the user what languages to install
and dynamically download what the user selects?  Extra languages could
then be added later via GHNS?  But the separate installer would still
be needed for offline use.

That raises another question: localizing the installer itself!

> I didn't think of this... Mostly because for me, it's not relevant, and I'm
> very focussed these days.

Rightly so, and very effective too :-)

>> KHotNewStuff may be useful here.
>
> Isn't that mostly dead these days?

It's just pining for the fjords ;-) It's still used by Marble and
KStars for distributing large datasets, Plasma for wallpapers, etc.
Things like spelling dictionaries seem to me to belong here for all
non-Linux platforms, and maybe even translations, icon sets, themes,
etc, all the things we normally have as extra packages to intall in
Linux.  Users can then just go into the config dialog, or have a menu
entry for "Add more xxx...", but we'd need to develop standard ways of
configuring that.

>> And that sort of touches on another topic: System
>> Settings.  Do we install that, or just ensure all settings needed are
>> accessible via the Help menu?
>
> The latter. No second applications that duplicate platform applications.

Agreed, when Windows users used to have to run SystemSettings to set
their locale it was terrible.  We can install things into the windows
control panel, but that's not easy to discover for casual users, so we
need to have them in the main config dialog, or as separate menu
items.  This applies equally to Mac and Android.  We'll need to
standardise a way for doing that, either the app needs to code for it
itself or we have some standard build tool to configure it.

> Another interesting thing: the default Qt themes for Windows and OSX are all
> broken if you need a dark color theme, so only Plastique and Oxygen work.
> The Oxygen theme is much nicer than the Plastique theme, and I would like to
> ship it, but it's not an independent thing.

Well, theming is another packaging issue too, do you ship multiple
themes in your installer, have them as a GHNS download, make sure the
KCM is integrated properly in every help menu or config dialog, etc,
etc.

John.