Per-app MSI-based installers

[Jaroslaw Staniek]

My 2c and my approach:
KDE on Windows (as a project) was not meant to transform Windows to an OS
with full KDE experience. Such distracting task would be against our "FOSS
business model", our reply would be better "want full experience, use an
open OS".

In my imagination at the time of funding KDE on Windows and later, KDE apps
honoured the rule of Qt and alike), by sitting as a kind-of internal
detail  to make development and deployment easier for contributors, without
staying against users habits. So the dream was to have the apps' experience
as native as possible.

But what native means to me?

- Native style: still a challenge when custom widgets are used, 80% of
fixes are  subtle things that have to be done; it's a moving target after
Metro design language won at MS, Apple, Google, the web; slowly apps became
to differentiate using their styles on the desktop too; this came from the
Web and Mobile areas: user inside of you thinks you don't want to have
exact the same tables in all your rooms... At tech level, QStyle is not
enough to define style anymore since it does not support layout/form factor
specifics, today's design languages affect styles this deeply. Existence of
dual styling in KDE: QStyle and KDE Plasma styling shows the dynamics here.
And please note, Windows (and Mac) apps typically do not have all these
icons on buttons. Love icons? Use them on Linux platforms :) Or enable them
on Windows/Mac but this shall not be a default IMHO.

- infra: no KIO (when statistically nobody is asking for that), no ksycoca,
no dbus, no a copy of settings in system-settings, no alien tech on
platforms that have these features out of their scope or have own (perhaps
more naive but built-in) equivalents

- deployment: no packaging on the way we know it (no saving Windows with
alien solutions like repositories when Windows communities are not asking
for that); no package manager; instead installers, all-in one blobs, with
remotely-accessible selectable components as Qt Installer permits, *maybe*
a re-distributable package (but we'll have soon 5 of them installed side-by
side, I am convinced as KF5 and Qt is a quickly moving target).
Auto-updates of any way is a plus. Translations installable/discoverable in
the context of apps.

So no splitting to small packages. Existence of MSI should not be confused
with existence of dpkg and alike, MSI isn't a lightweight means for
deploying highly splited libs or resources like icons or translations.

I am hoping Qt Installer or similar tools will be useful.

The user base is typically not willing to be part of development community
on Windows and Mac, so deployment would be better able to address that. But
because of the volume, they are able to drive development of our FOSS apps
in many other ways, so for benefit of the entire community.

Look, Android/iOS packages are largely all-in-one blobs on so less
performant machines than desktops and nearly nobody complaints too much IF
the app in question is worth pulling 10's of MB. I'm saying to myself,
start with value first, then perform 2nd-level optimizations later.
Removing unnecessary bits of resources, disabling unused modules or making
them optional - this all is a 2nd-level nice-to-have stuff.

As you see I am largely with Boudwijn in these areas. Krita and Kexi, and
possibly the rest of Calligra goes the pragmatic way. KDE offers a lot of
value in apps too!


Cheers!


-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt for Tizen | http://qt-project.org/wiki/Tizen
 Qt Certified Specialist | http://www.linkedin.com/in/jstaniek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-windows/attachments/20140703/58bd7fa3/attachment-0001.html>