Well, since Aaron raised one or two issues, I'll take the time to blog again.
Our primary goal for KDE on Windows is easy installability and a complete and stable KDE on the Windows platform. So the question is - where do we start?
Aaron mentions that our installer seems to be way more complicated than installing Linux and that a simple fire and forget installer is far better for a broader audience.
This is probably true and was already part of some discussions. The task of rewriting the packaging format is also not the biggest part. More tricky is the problem of updating the core package, which would then contain quite a lot of smaller libraries which are now handled by the installer. And the second point is: If you want to install more than one package, you might find a package manager far more convenient (on a side note: it is near to impossible to use the .exe installers as packages from inside the kdewin-installer). This part of course gets less important if you want to install just Amarok or just Digikam.
The second point Aaron brings up is how we see ourselves. Aaron says that it could bring a lot more for KDE if we see ourselves as the ones to deliver the libraries for other application developers and at the same time be our own consumers (in our role as the ones who deliver the applications).
The equivalent model would be the java runtime environment vs. java applications. I have been thinking about this model already for quite a while and it never really has vanished. On the other hand I must say that I think the priority is wrong. Until recently an external KDE application was not compilable out of the box on top of our packages (thanks go to Alex Neundorf for fixing it). A whole lot of shiny new KDE technology has no working backends under Windows (think of solid) or is really unstable (phonon). There are really basic bugs like you cannot copy files from one drive to another (recently fixed in kio_file), and last but not least on a lot of corners you don't have any system integration for your applications (this is somewhat similar problem to the missing backends). Personally I consider those issues far more pressing because I benefit from fixing those issues when using KDE applications.
On a more personal level now as it is already getting late:
One of the funny things is the usage of the word 'we' in and around KDE on Windows. This can have multiple different meanings: All the folks working on Windows (which excludes people not working on Windows), the people that distribute their software via the installer (excluding KDAB which uses a single installer for kontact), and not to forget the 'we' Aaron uses where he includes himself. That there is a difference between the first two has been made obvious here but I think those issues have been solved now more or less. The third 'we' is a general KDE one and sometimes also looks from outside: If 'we' have to change our way of thinking, then it is of course not the 'we' including Aaron who has to do something but the other two 'we'.
Enough ranting for now.
skip to main |
skip to sidebar
MyBlogList myBlogList();
Open Source Software.
Labels
- kde
- windows
- Koffice
- Release
- digikam
- Marble
- emerge
- okular
- Amarok
- sprint
- fairs
- installer
- system integration
- Python
- bugs
- git
- kile
- nepomuk
- nightly builds
- Yokadi
- apache2
- compiler
- gsoc
- gwenview
- imaging
- intel
- introduction
- kate
- kdegraphics
- libjpeg
- libpng
- mysql gwenview amarok cmake
- personal
- plasma
- qdf
- quality
- solid
- soprano
- strigi
- taskplanner
- transqript
- viewgit
- work
Posts
17 comments:
Hello,
First things first : thank you for your work !
I don't want to talk about the communication problems 'you' (whoever that would be ;) are facing in this project, so I'll just talk about something else :)
Do you think it would be possible to create a 'all in one' installer for Kate ? containing only the needed dependencies for THIS application. Maybe the hardest part would be to find *what* is really needed, but imho there's no need for strigi, dolphin, nepomuk, libjpeg, gwenview and maaany things.
I understand that this is not 'your' priority. But I just wanted to discuss if this would be really hard.
Of course, the toping on the icecake would be to have a simplified kio and kfiledialog using native windows counterparts for a better integration... That would remove some features like kio over ssh, but for me, this is not the most important feature of Kate.
I think a good installer / deployment model would attract mode developers to the KDE/Windows platform. Currently, the installer is a major turn-off for me.
For example, I still can't promote KMess on Windows because it's not easy installable. -> hence no attention from developers on Windows to work on it.
My preferred model, based on aaron's and your blog would be:
- the current installer can be kept as is, as poweruser tool.
- A new "KDE runtime" installer provides the runtime, and some installer system backend. This is not new for Windows either, see http://www.microsoft.com/web/ for the "Microsoft Web Platform" installer as example.
- The individual apps, are provided as separate installers. They locate the KDE installer backend, install themselves and optionally request additional libraries if needed.
For users this looks like:
- Installing the "KDE Runtime"
- Installing the app, separately.
About the installer, I don't think you need to kill the current one, but rather have specific installers. For instance, we could have a krita-setup.exe (or kate-setup.exe, ...) that the user can download from krita.org, and that will then do the selection of package automatically, and install krita in two or three clicks. And then you can keep the "expert" package manager interface.
I really like the ideas of Diederik and Cyrille. The installer first checks for the prerequisites in common locations, like KDElibs, Nepomuk, etc. and downloads the binaries of the application and what is additionally needed. I wouldn't completely take apart the libraries though. A big KDElibs package is okay. The .NET framework 3.5 SP1 also has a footprint of 234MB.
I imagine a shiny website which offers the small web installers for applications, where you could even mark some checkboxes to have a combined installer.
I guess the versioning will be quite difficult, though. The libraries should of course be shared, but coexist in different versions.
The original installer should definitely survive, cause it's great for installing a development and debug environment, or if you want to download a whole set of applications.
I agree with Cyrille too. This sounds like a good idea.
What could maybe be done is simply using some kind of wrapper around the existing installer, that makes it look like individually made for the application, including a logo and such branding details.
Dunno if that is feasible, just an idea :)
Regards, Mark.
Ok, to answer a few things:
@shamaz:
I doubt that there will be a kate only installer. The work is to much to find out for every app, and the result will always be bigger then every other editor you can find (and it also would mean to remove many features from kate).
@Diederik:
We spoke about that already and I know that it is true for you; I would really like to talk to you about your issues now that we have fixed the major problem.
@Cyrille:
Yes, but this task requires not only to build the installers but also to split up koffice. This task is the real problem there. And the second point: who wants to maintain hundreds of installers if one can't even really manage to ensure that koffice works properly from inside the installer. But this of course will change if every app has an installer :-/.
Wouldn't it be possible to let the one-app-installer be a variant of the current installer where the package selection is predefined and hidden from gui?
Hello,
also wanted to say thanks for your work :)
Thanks for replying to my blog entry, as well as for your (and the rest of the KDE Windows team's) ongoing eforts.
Some thoughts/questions:
"More tricky is the problem of updating the core package, which would then contain quite a lot of smaller libraries which are now handled by the installer"
Would that really need to change so much? In other words, is it any harder to manage one big package at installation time than a bunch of small ones? I don't think changing the internals is so important (especially as it seems to work nicely) as it is to hide these sordid details from the innocent user.
"If you want to install more than one package, you might find a package manager far more convenient "
I agree; and I can think of a couple of possible answers to this challenge. My current favourite is:
The package manager could be included in the "base install" so that users get it "for free". If they are only installing the base, it could be launched automatically post-install.
If, however, the core package is installed as a part of a "stand alone" package (e.g. for just Kontact, or whatever), then the package manager wouldn't be launched. (Ok, that was probably obvious. ;)
I don't think we need individual installers for each app in KDE SC, extragear and KOffice, either. This change would be more to enable the creation of such installers by others. This would in turn encourage more people to write applications that target windows using the KDE development platform.
So this would not necessarily have too much affect on how KDE SC is packaged for Windows (aside from the install order being changed a bit: you'd install the core, then select the packages you want from a package manger window), but it could have a massive effect on 3rd party adoption of the KDE Dev Platform.
That man power would help with the "lots of things left to work out in the code". Consider it an investment of time in getting more hands onto the project in the future. So while this work may delay some of the other bugs getting fixed, in the long term we'll have more people using and therefore probably also working on the Windows port and those bugs and missing features will close up faster.
Sometimes the people at a project's core need to do things that don't directly solve the immediate issues, but which make it easier and more likely for others to help them. It's a bit counterintuitive, but it works in my experience.
"If 'we' have to change our way of thinking, then it is of course not the 'we' including Aaron who has to do something but the other two 'we'."
The KDE on Windows "we" are part of the KDE "we"; so while the change has to happen on an individual, local level as you note, it does involve part of the KDE "we" as well. As such, the KDE "we" can perhaps help by providing light on these issues and giving the KDE on Windows "we" people to discuss these issues with and a place to do so.
I just want to say that there are still people who live without unlimited intenet or with inet almost unlimited but still with some limitations.
There are people who still lives on dial-up (ok, I do not live on dial-up, but I also do not use windows) and also people who has limitations on external traffic ammount.
I think the major part which is currently missing with kde installer is "download all at once" option. In this case I could take the whole KDE windows installer (no matter how much it would take - 1gb, 2gb or more) and put it on the local torrent tracker, so every one could download it once and would not care about how much traffic it would desire to eat during installation. Or I could bring it on single dvd disk to a place without inet and install required packages offline.
The last time I gave a try to kde windows (probably about a year ago, maybe later), there were no option to do this - only small installer and wait-while-I-download-what-ever-I-want process at the end. I had 5gb monthly limit at those times and I just canceled this process for a better time as I could not predict if my limit would expire after this operation.
I think giving people who lives on windows a good package manager is too big task which they are not ready for and that's not kde's team mission. Remember photoshop vs gimp - how much usual windows application would install with itself without caring about place on disk or existance of same libraries in other installs in "Program Files".
If one wants to download and install KOffice on windows - give him a link to the "1gb KDE SC" file with okular, kate and other usual programs inside - and KOffice would also be there among others, but dowloadable by 1 click and installable with 2 steps - this would not be a surprise for windows user to see office package of this size, but it would be much easier to install it and also share with offline friends.
@benderamp:
There is such an option already:
When you start the installer, simply choose 'Download only' select all applications, specify your download directory, put the installer into this directory & burn it onto CD (it should theoretically fit). Then you can use that CD whereever you want, simply click the installer on that CD, select 'Install from local repository' and select the location of the packages. Then you can choose again which applications to install.
@Aaron:
Well, I am not as sure as you are that defining a core brings more users of the API and because of that developers. Otherwise it would mean that under Linux KDE shouldn't have any applications that use KDE technology, as it does exactly what we do under Windows?
On behalf of the individual installers: This is what everybody wants, an individual installer for his application. I doubt that Cyrille or Mark will now start to set up a Windows system and build an installer (They'd also need to build your project) just because I rearrange the package installation.
And I also doubt that windows developers (especially those interested in Open Source Software) have a big problem setting up a system atm.
As far as I can see it, an easier way to install Software doesn't mean more developers but more people using the software, asking questions and increasing the workload for support, rather than for development.
The second point I have against working on a different base than Linux is that people will have to adapt even more - people can be confused about what we will deliver exactly (phonon, nepomuk, akonadi, etc. yes or no?). So how can we get new developers if we have a big anonymous bunch of libraries? Do you really find that attractive from an outsiders point of view?
There are definitely pros and cons for both sides and I know that we need to consider them. But I don't believe that problems can be fixed that simple.
@SaroEngels: I think Aaron is talking about users as in users of the core libraries. If 3rd party developers develop applications that depend on kdelibs then they are likely to want to make kdelibs work well and hence offer assistance.
Most developers/3rd parties will not use a platform if they can't rely on it either being installed on the system, deliverable with their software, or easily installable by the user. It needs to be dead simple.
Currently, If I'm create an application to deliver on windows and rely on kdelibs I have to either a walk the user through the required steps to install the libraries through the current install and hope they don't make a mistake or create my own packaging of the libraries and include them with my software making it much larger than I would like. Many users aren't going to try my software in both of these cases. They are use to library installers like .net, java, and even flash.
Any way, just offering up my POV, thanks for all of the KDE Windows team's hard work.
I find the arguments against individual installers for just one app very unconvincing.
If Krita, Amarok or Kate would be available as just one big exe it would without a doubt bring those apps more users. No matter how big they are. The current installer is a major turn off for every windows user and it keeps KDE apps from being promoted on all those big freeware/shareware sites.
And I don't see any reason why the current installer can't have preselection options that essentially make it look like every other windows installer (there are lots so a slightly different look is no turn of for windows users.)
And all the current possible selection could be scripted to build single exe installers .. you have all of that in place right now.
2010 target:
- Double click exe
- Select location
- Click Next and Done
@SaroEngels:
You are completely right about this: It would be a big hassle to get each application team to write its own installer. That is problematic.
But back to my "wrapper" idea, I thought about it some more:
Imagine we made some kind of system that works much like "theming": Every application would provide a file (or a number of files), containing some XML or so that defines some rules, and then some artwork that would be shown in the installer. With a uniform system, it would be easier for each team to provide the necessary data.
This way, we wouldn't have to drum up completely new installers for each application, but just one "theme package" that the installer would parse and use.
Again, I'm not sure how feasible this is, it's just an idea. You can judge this better if this is actually doable :)
Regards, Mark.
OK, I tried the newest installer and here is my mini review/rant:
Way too many options! This isn't Linux from scratch. I just wanted to install Digikam.
Don't tell me how much bloat you are going to download and show lots of process bars. I am OK with the 407MB install for Digikam, but don't want to see individual packages download and install. This isn't Debian.
Provide an UNINSTALL! I might not like what I get or it might be too crashy, slow or unfinished so provide a method to get rid of everything the standard way (control panel).
Add shortcuts to the start menu.
Other than that it is fine, maybe try to split the bigest packages into smaller parts, like Digikam needed the whole of KDEedu just for marble .. most of it is probably not needed.
The experience is bad for users AND for developers. As a developer looking to provide his users with cool and easy technology the missing uninstall and menu entries are a big minus.
But those are just minor things that should be easy to fix compared to solid or phonon.
Hello,
My POV (not in order of importance):
a) the installer style has no much difference from cygwin installer, it resolves the dependencies ( windows lacks of libraries and they can't be simply be apt-get'd, so the installer is very handy and it is as convenient in this point as e.g.: KPackage manager on Kubuntu )
b) It was hard to get used to emerge "method" but it is also very handy while keeping linux-style installation.
c) Some time ago I've installed simon from kde-apps.org, it has an individual installer, the problem is: it messed up my kde installation and did not work correctly because each installation had their own dbus-daemon , their core libraries etc. so it would be hard to maintain several packages ensuring they'll use the same set of libraries etc. e.g.: an user has installed kate from kde 4.2 and wants to install kdegames from a more recent version, the libs (from kde or qt or external dependencies) had probably some structural changes that would occasionally mess up kate, I had similar problems when updating qt to 4.6 and had to reinstall everything, even 4.6 being binary compatible to 4.5 ( at least on linux it is BC )
d) I see no big problem on 12 steps of installation (Visual Studio, Windows Live "et coeteras" and other installers just bother me a lot more :P ) but I do have a few suggestions to reduce the steps:
I)some steps are really optional, instead of an obligatory 'visit' to 'proxy' screen, use a single configuration screen with buttons "proxy...", "directories...", "mirrors..." ( or simply "advanced..."), so these screens are only shown to who are interested to change these settings.
II) *.kde files that are to be open-with'd the installer, e.g.: I do have a kde-installer run to just make my settings of compiler, mirror proxy etc., then I go to windows.kde.org where I download a small file "kate.kde", where *.kde files are associated with the installer that will download dependencies etc. just as it currently does but with almost no steps. The installer could be run later to simply update current packages or change configuration. This would also one to select either a "KOffice.kde" package or just "KSpreadsheet.kde", "kdeutils.kde" or just "okteta.kde".
Finally, I don't think the installer is a major problem, many things in kde needs port on windows, kde is still quite unstable on windows when compared to kde on linux and these are the points that shall be focused. I disagree that packaging should be modified, it works as beautifully as cygwin/debian/gentoo packaging with additional convenience of a "nnf" installer. Changes in the installer should be thought only when everything else gets more stable.
(hope no one gets angry with me :P )
Post a Comment