From kde-windows Tue Oct 12 14:42:38 2010 From: "Thomas Friedrichsmeier" Date: Tue, 12 Oct 2010 14:42:38 +0000 To: kde-windows Subject: Thoughts on the KDE windows installer (was: Re: Principles on what Message-Id: <201010121642.43462.thomas.friedrichsmeier () ruhr-uni-bochum ! de> X-MARC-Message: https://marc.info/?l=kde-windows&m=128689460909832 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0344825301==" --===============0344825301== Content-Type: multipart/signed; boundary="nextPart4460658.g8pVkodZX6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart4460658.g8pVkodZX6 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Hi, while we're at it, I'll throw in my two cents on the windows installer. Of= =20 course, I only know so much about the technical background, so some of this= =20 may not make much sense. Nethertheless, I'll word my thoughts as suggestion= s,=20 and use "should" a lot, as it's easier to write that way. Make sure to have= =20 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= =20 (page 7 of the installer; length of the list depending on the mirror), most= of=20 those long obsolete. Certainly it makes sense to keep the old versions=20 archived, somewhere. They could even be accessible from the installer, if t= he=20 user enters the archive URL, manually, on page 6. But offering all those ol= d=20 versions by default is unlikely to help Joe User. In fact: =2D If users fail to find what they are looking for, it simply adds one mor= e=20 point of wondering, whether they should have selected something else. =2D If users select the latest point release (i.e. "stable 4.4.4", ATM), it= =20 means they will not get to see any updates, which is unlikely to be what th= ey=20 want. Thus, by default, the only choice should be between "stable latest", "unsta= ble=20 latest" (where "unstable latest" should always be most recent, i.e. point t= o=20 "stable latest", as long as there is no current alpha/beta), and "nightly=20 latest". 1b) Release handling I'm not sure, how this is acutally done, but I see there are "repositories"= =20 and "releases", with "releases" being snapshots of the repository at a cert= ain=20 point of time (KDE SC release). As far as I understand, the installer opera= tes=20 on "releases", only. I think it should operate on repositories, instead.=20 Rationale: If package X is available in, say, 4.4.4, but fails to compile i= n=20 4.4.5, then the only options are to either stick with 4.4.4, or not to have= =20 package X. But most of the time package X-4.4.4 would work just fine with=20 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 releas= e,=20 but rather about having the latest (stable/unstable/nightly) version of the= ir=20 software. 1c) Upgrading One of the things I'm missing most dearly is an "Update all" button, which= =20 will mark for installation any available updates for *all* installed packag= es=20 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 wi= ll=20 not see any packages for the latest release. 2b) MSVC Is there still a compelling reason to include MSVC-compiled packages? As fa= r=20 as I understand, there used to be issues with debug symbols. Is this still = the=20 case? Otherwise I really suggest dropping MSVC from the installer, and to o= ffer=20 only MinGW4. This would =2D obsolete one more UI setting =2D probably make it easier to create releases =2D definitely make it easier / more attractive for third parties to start= =20 developing on KDE for windows, since it will finally offer a mostly uniform= =20 platform. Note that I do *not* suggest to drop MSVC-support from emerge, only from th= e=20 installer. 3) Multitude of packages Earlier in this thread, others have touched on the problem of finding a sin= gle=20 application that is part of a larger bundle. The obvious (although probably= =20 not trivial) solution is to allow "lookup by application name". On the other side of the coin, installing any KDE app means installing a wh= ole=20 bunch of dependencies. Currently the installer has all these dependencies a= s=20 single packages from aspell to zlib. Yes, this is quite elegant, from a=20 technical point of view. But from a usability point of view, I doubt there = is=20 any usecase for this in the KDE windows installer. I would suggest to creat= e=20 one large package "KDE Platform", including kdebase-runtime (or even kdebas= e- apps) *and* all dependencies. This will lead to =2D less "noise" in the UI =2D fewer large downloads, instead of many small ones (at least two RKWard = users=20 reported that they experienced problems while downloading all the individua= l=20 packages from at least some mirrors) =2D make it much easier to re-distribute for third parties -> making the=20 platform more attractive to third party developers. Of course, if you want to keep up the claim that the KDE windows installer = is=20 also "the" solution for deploying Qt-only software, then it would have to b= e=20 split into "Qt and dependencies" and "KDE platform and all other dependenci= es=20 besides Qt". Again, I do not suggest to change the behavior of emerge in this respect, o= nly=20 of the installer. 4) Package manager mode Please allow to switch between "Package manager mode" and "End user mode" a= t=20 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 us= eful=20 or at least mildly interesting. Keep up the good work! Thomas --nextPart4460658.g8pVkodZX6 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAky0c94ACgkQEKRv+5DVNhiDawCgyz/+FdcwUTD8JO64VVT6YJeK 7SMAoMDGo/Hf4Qce2MmYXuQrjD/0TU81 =xJcV -----END PGP SIGNATURE----- --nextPart4460658.g8pVkodZX6-- --===============0344825301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kde-windows mailing list Kde-windows@kde.org https://mail.kde.org/mailman/listinfo/kde-windows --===============0344825301==--