So I got quoted in some print media in Minneapolis/St. Paul about my trip to Glasgow and the various delays and 'inconveniences' I had in one single trip. I've never been referred to as "Unrau" in any context outside of hockey before, so it's weird to see myself referred to that way.
I'm posting this from Mandriva 2008 which I'm testing on a spare hard disk. I tried Compiz Fusion this way for the first time on this machine. Since my only experience with Composite on this particular machine is KWin from trunk, it further emphasizes the performance problems I have with Composite in KWin. I'm not sure if it's just a setting problem that can be worked around in the Nvidia driver, but I'll look into it more later.
And now for a discussion that seems to come up within KDE every time a new release is getting closer - a KDE program installer. Attempts have been made in the past, but they have all (except klik) failed to catch on at all. Here's my crack at the ol' whip.
Liquidat recently posted a few words about the development of klik2. I must say that I'm really happy that they are moving to an LSB base rather than the debian base as it makes klik2 even more distro-neutral. I don't know if they solved the problem with packaging for separate CPU architectures yet though, but that would be nice :) But KDE supports (or will support) other platforms as well, such as BSD or Windows, so why not unify the whole program installation thing across our supported platforms and distros.
I'm going to arbitrarily list the requriements of my dream package installer system for KDE:
1) self-supporting - a single downloaded file containing all of the dependencies required to use the package (assuming some base, like LSB + kdebase or something similar on each platform - this is like klik)
2) self-installing - using an installer that works both graphically, or at the shell if required (like PBIs or perhaps .dmg files)
3) installs into a self-contained location (like PBI's with /Programs, or ROX's Zero Install)
4) Solve library sharing issues by installing symlinks as appropriate (Like PBI's or GoboLinux)
5) Are easily updated (see PBI's once again)
6) Are easily removed (like klik's)
7) Have a mechanism for easy creation (see klik or GoboLinux recipes)
8) Have some mechanism for cross-platform support - such as separate packages for each platform KDE runs on (x86 and x86_64 on LSB, FreeBsd, OpenSolaris, Windows, etc... OS X already has .dmg files which would work just fine for that platform) -- each platform would likely have it's own unique file extension
So the question then becomes, how hard would this be to implement? Would the KDE community even care? Can this be developed cooperatively with klik (for example, reusing recipes) or the PBI folks?
If this idea does not seem unreasonable, I think I'm going to try to make this a reality for 4.1. I don't want to reinvent the wheel, so I'll see if anyone (from the other projects) is receptive to this idea and use that as a base to start work. I know that klik is heading in a somewhat different direction for klik2, but that doesn't mean that we can't work together on recipes and such :) And the PBI stuff from PC-BSD already has a pretty nice kcm module for updating and removing packages and similar actions which may be useful.
Now back to other topics: the release team's updated release schedule (including the early Developer Platform release) looks good. My only concern these days has to do with plasma, and only plasma. In all honesty, the rest of KDE 4 is in a mostly usable state, less a bug or two that's still floating about. I know that right now the plasma team's focus is just on getting something that is a functional replacement for kicker, and that's good because we cannot ship without it.
But, I really do hope that it's still being done in a way that is not going to come back and bite us. We rushed to get aRts into KDE 2, even though it wasn't really ready, and that came back to haunt us. So while Aaron and Robert and a number of other great coders are hacking like mad to ensure that we have something that can 'replace' kicker more fully, I hope that we haven't lost our original design considerations, like ensuring that every data source is accessible from other applets.
For example, the default appearance of the panel in 4.0 will not necessarily be the prettiest but should at least be usable. If the data engine design goes as planned, users will be able to create replacements that will look or function in unique ways. Like Pinheiro's panel mockup, which looks beautiful and would really be a unique panel for KDE, but has some usability complaints (like Fitt's Law). The beauty of the plasma concept is that someone can implement Pinheiro's concept within plasma without sacrificing the existing code - it's simply another plasmoid that shares the data source. In later versions of KDE, we can likely expect a darwinian approach where the best plasmoids for a specific task are included in the release, which should be cool.
Lastly, someone on IRC was complaining about Plasma not being a real KDE application. So my question is then, what defines a Real KDE application? Does it need to implement a File Dialog? KStyle-rendered widgets? Link to libkdecore? When does an application count as a KDE application?
- Log in to post comments