[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-windows
Subject:    Thoughts on the KDE windows installer (was: Re: Principles on what
From:       "Thomas Friedrichsmeier" <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date:       2010-10-12 14:42:38
Message-ID: 201010121642.43462.thomas.friedrichsmeier () ruhr-uni-bochum ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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" (application/pgp-signature)]

_______________________________________________
Kde-windows mailing list
Kde-windows@kde.org
https://mail.kde.org/mailman/listinfo/kde-windows


[prev in list] [next in list] [prev in thread] [next in thread]