<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace;font-size:large"><br>My 2c and my approach:<br>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". <br>


<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:large">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. <br>

<br>
But what native means to me?<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:large">- 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.<br>


<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:large">- 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<br>


<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:large">- 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.<br>


</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:large"><br>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. <br>

<br>
I am hoping Qt Installer or similar tools will be useful.<br>
<br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:large">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.<br>


</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:large"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:large">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.<br>


</div><div class="gmail_default" style="font-family:courier new,monospace;font-size:large"><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:large">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!<br>

<br><br></div><div class="gmail_default" style="font-family:courier new,monospace;font-size:large">Cheers!<br></div><div class="gmail_extra"><br><br>-- <br>regards / pozdrawiam, Jaroslaw Staniek<br> Kexi & Calligra & KDE | <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a> | <a href="http://kde.org" target="_blank">http://kde.org</a><br>

 Qt for Tizen | <a href="http://qt-project.org/wiki/Tizen" target="_blank">http://qt-project.org/wiki/Tizen</a><br> Qt Certified Specialist | <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a><br>


</div></div>