game on, indeed

Ruurd, i'm going to take your issues one by one and address them.

but first let me address why your penultimate post pissed me off so much: you failed to explain one bit about what your problem was. it's not like i didn't put out a little warning flag just the other day about this. if you haven't noticed by now, i'm done putting up with it.

this last entry of yours, however: actually useful. thank you for that. apparently i had to kick you in the teeth to get it out of you. i don't like doing that, and i'm sure you didn't like it either. so in future, try being productive from the start. it's a much happier path.

so, your issue is that "things are different" and therefore "we need a migration plan". this is, in my opinion, what we call "stating the bleeding obvious". this conversation was had and done over a year ago, in fact. you apparently didn't catch it, fair enough, but dude: i'm not stupid. just posting that question in your blog would've been so much easier, no?

in particular, you want a migration plan for kicker, kmenu and kdesktop. well, kicker's not a real problem: we have panels (and yes, a configuration ui is coming so even users can figure out that it has the features you expect), we have launchers, systray, clocks, pagers, etc. if your concern is the default layout, i don't know how many times i've said this but: the layout in svn is not the final one.

we will not be supporting transfering kicker's configuration files, however. why? i don't have the time to start with, but more importantly the configuration systems are pretty wildly different. we could probably map the most well-known applets between the two systems (e.g. system tray, task bar, etc) with a fair amount of work, but it would be rudimentary at best. this is a one time pain, much like with the intro of kicker itself in 2.0.

next, the traditional kmenu; seriously: it's a horrible horrible design. that's a statement backed up by a lot of testing and user feedback, but i understand why those used to it would like something similar. it was on my TODO list in the "if at all even remotely possible for 4.0" section to provide exactly something like that. you'll even find threads on panel-devel and bugs.kde.org discussing this very issue. the b.k.o one is particularly easy to find. i have two directories on my devel system here, one containing the start of a menu oriented display of the data models in kickoff, another which is a straight port of the kicker kmenu code.


however, in line with my recently adopted "i don't reward negative behaviour" position, due to the completely out of line missives i've received on this issue, capped by yours, it is now officially off my table. so if you want a "traditional" menu, then you make one. when someone asks why i'm waiting for someone else to show up with the code, i'll be sure to point them your way. i'll be more than happy to see it in workspace/plasma/applets as soon as it does show up, of course.

we can live just fine without a traditional kmenu, so i don't see it as crippling anything; and there is absolutely nothing stopping someone else from stepping up and doing the work in my stead. the point is, however, with community comes responsibility, and if have to help us all figure that out, so be it. i am not your rag doll, and i do not respond to tantrums. nobody needs it, nobody wants it and personally i am through tolerating such community destroying behaviour.

now, the desktop. that one's easy because all it requires is listing files in a folder and putting an icon for each on the desktop with an option to hide them away. the old desktop was so amazingly featureless that it's actually nice when one goes on to do something else ;) we already have launchers (the layout is broken today in svn due to all the layout mucking and fixings we've been doing over the last 2 weeks, but i'll be fixing that shortly) so the next step is adding code to the desktop containment to watch the contents of the desktop folder. that's what ... 50 lines of code? at most? let's say i'm constantly interrupted, run into a bug somewhere in the stack or am just slow and lazy that day, it's half a day's work. putting icon postioning (align to grid, etc) would be the rest of the day.

btw, due to the new design, i can actually now with great accuracy and without nasty hacks tell exactly what the viewable space on the desktop is and avoid the hair tearing annoyances of icons that slip beneath panels or refuse to appear beneath them when the user puts them there on purpose. this is one of the fine details to the new system that i understand virtually nobody will appreciate, nor do i expect them to. i just expect them, or rather you, to give me some basic credit here and figure that maybe, just maybe, there's reason for my madness. and i'll take a "why are you doing this apparently crazy thing?" question over a "you're doing a stupid crazy thing." statement any day.

as for the rest of the desktop stuff (minicli, screensavers, etc), that was ported and improved months ago. in fact it was some of the first user visible work we did on the path to replacing kdesktop/kicker. fast user switching needs some love, still. the sysguard stuff is faster and better now, though as another added perk (mostly thanks to Tapsell).

so to recap:

• kicker: pretty well done, needs some config ui and the ability to (auto)hide panels


• kmenu: you and your party of sad screwed that one for now; someone else can provide that code (which i'll be happy to see put into workspace/plasma/applets, of course)


• desktop: an absolutely trivial bit of work is left

i hope, with the exception of the kmenu thing which i don't expect you to be happy about, that the rest of this puts you at ease, at least somewhat. see how easy that was, and could've been from the start?

so, let me thank you again for eventually providing the reasons you were hot and bothered so that i could address them.