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
_______________________________________________ Kde-windows mailing list Kde-windows@kde.org https://mail.kde.org/mailman/listinfo/kde-windows