Hi, while we're at it, I'll throw in my two cents on the windows installer. Of course, I only know so much about the technical background, so some of this may not make much sense. Nethertheless, I'll word my thoughts as suggestions, and use "should" a lot, as it's easier to write that way. Make sure to have some salt at hand, and add where needed.
1) Multitude of versions 1a) Release versions Currently the KDE installer offers you a host of different release versions (page 7 of the installer; length of the list depending on the mirror), most of those long obsolete. Certainly it makes sense to keep the old versions archived, somewhere. They could even be accessible from the installer, if the user enters the archive URL, manually, on page 6. But offering all those old versions by default is unlikely to help Joe User. In fact: - If users fail to find what they are looking for, it simply adds one more point of wondering, whether they should have selected something else. - If users select the latest point release (i.e. "stable 4.4.4", ATM), it means they will not get to see any updates, which is unlikely to be what they want. Thus, by default, the only choice should be between "stable latest", "unstable latest" (where "unstable latest" should always be most recent, i.e. point to "stable latest", as long as there is no current alpha/beta), and "nightly latest". 1b) Release handling I'm not sure, how this is acutally done, but I see there are "repositories" and "releases", with "releases" being snapshots of the repository at a certain point of time (KDE SC release). As far as I understand, the installer operates on "releases", only. I think it should operate on repositories, instead. Rationale: If package X is available in, say, 4.4.4, but fails to compile in 4.4.5, then the only options are to either stick with 4.4.4, or not to have package X. But most of the time package X-4.4.4 would work just fine with kdelibs-4.4.5, so why shouldn't it be included in the release? I don't think users generally care about having a particular service release, but rather about having the latest (stable/unstable/nightly) version of their software. 1c) Upgrading One of the things I'm missing most dearly is an "Update all" button, which will mark for installation any available updates for *all* installed packages at a single click. 2) Mutlitude of compilers 2a) Drop obsolete options Please drop the "MinGW"(3) option. If a users happens to select it, they will not see any packages for the latest release. 2b) MSVC Is there still a compelling reason to include MSVC-compiled packages? As far as I understand, there used to be issues with debug symbols. Is this still the case? Otherwise I really suggest dropping MSVC from the installer, and to offer only MinGW4. This would - obsolete one more UI setting - probably make it easier to create releases - definitely make it easier / more attractive for third parties to start developing on KDE for windows, since it will finally offer a mostly uniform platform. Note that I do *not* suggest to drop MSVC-support from emerge, only from the installer. 3) Multitude of packages Earlier in this thread, others have touched on the problem of finding a single application that is part of a larger bundle. The obvious (although probably not trivial) solution is to allow "lookup by application name". On the other side of the coin, installing any KDE app means installing a whole bunch of dependencies. Currently the installer has all these dependencies as single packages from aspell to zlib. Yes, this is quite elegant, from a technical point of view. But from a usability point of view, I doubt there is any usecase for this in the KDE windows installer. I would suggest to create one large package "KDE Platform", including kdebase-runtime (or even kdebase- apps) *and* all dependencies. This will lead to - less "noise" in the UI - fewer large downloads, instead of many small ones (at least two RKWard users reported that they experienced problems while downloading all the individual packages from at least some mirrors) - make it much easier to re-distribute for third parties -> making the platform more attractive to third party developers. Of course, if you want to keep up the claim that the KDE windows installer is also "the" solution for deploying Qt-only software, then it would have to be split into "Qt and dependencies" and "KDE platform and all other dependencies besides Qt". Again, I do not suggest to change the behavior of emerge in this respect, only of the installer. 4) Package manager mode Please allow to switch between "Package manager mode" and "End user mode" at any time, without going all the way back to page 3 of the installer. Well, enough for now. I hope you'll find at least some of these thoughts useful or at least mildly interesting. Keep up the good work! Thomas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-windows mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-windows
