* you can rubber band in the file manager
* weather works just fine with European cities. i live in one, so i know.
* graphics glitches are usually driver related, but we've also fixed a lot of issues (small and large) in the least couple of years
* creating a launcher -> drag it from the file manager, the launcher, from a search in krunner, ... yeah, not hard.

i realize that reality often does not come into play much when people create and then post again and again these kinds of lists. really it comes down to your last point, doesn't it: you have a highly personal preference for 3.5 (which is fine) and you work backwards from that to justify it. your points, however, are outdated or were never correct.

but that's alright. one can't please everyone all the time, of course. we do have many users who are quite happy, and both sides of that (number of users and average satisfaction) appears to be growing with each release. perhaps not amazingly, it is those people, not those who generate lists for re-posting on every article they can find, who get developer focus.

We're already working on it: http://www.notmart.org/index.php/Software/KDE_on_MeeGo

We had been working previously with both Maemo and Moblin, so this in a way simplifies things a bit for us. It's early days yet, but we're making great progress. The more the merrier, so feel free to join us (you can find us in #plasma on irc.freenode.net)

it wasn't talled "the taskbar" in KDE 2 or KDE 3 either. :) in fact, Plasma calls them exactly what they were called in KDE 2 and 3: panels. the "taskbar" has always referred to the windows picker/manager. personally, i wish we'd always called it something like "windows" that was a bit more obvious.

but yes, in this case it's actually completely consistent with what's always been there.

sorry to burst your bubble.

> I'm just asking for a tiny fraction of that effort put toward helping me understand how to develop apps for it.

techbase.kde.org

and it's an open wiki with a large number of people contributing to it.

> I'd be happy to help with docs, but I need some guidance.

you can find many of us on irc.freenode.net in #kde-devel and there are all the mailing lists.

> it started around 4.0 and 4.1, back when it was not possible to have good KDE releases

KDE specifically stated that 4.0 should not be used in production, and yet that's what a number of distributions rushed to do: place it as the default their users got when installing an OS that was intended for production use. i understand why distributions did what they did, but those are reasons not justificatons. i think a lot has been sorted out on all sides since then, and things are improving in general (though we saw a repeat of the same with pulseaudio, sadly)

> I want to know how development progresses,

we used to have that in the form of the commit digest. would be nice to see that revived by people with interest and the time.

> I want a website which displays the reported recent plasma crashes.

easily available with a query (which you can save, btw) on bugs.kde.org

> I want a website that explains me a single working methods how to set up a built environment on a free machine.

techbase.kde.org, which is linked to from kde.org

> I want an idea torrent set up for KDE.

brainstorm.forum.kde.org

> I want to see the users get involved to discuss KDE in a open and honest way.

i would, too. unfortunately that seems to require more time for research and patience for careful analysis than most computer users can manage. just because it's a GUI that you can see with your eyes and manipulate with your mouse doesn't make the topics of design immediately accessible.

> I don't want slogans and empty marketing gibberish. I want better code.

would you take both? or rather, ignore the former as they are evidently not for you and revel instead in the latter.

> I don't want a code of conduct bullshit,

i'm sorry to hear you think agreeing to treat others with reasonable levels of common-sense care is bullshit. those who spend their time working on KDE tend to feel differently about that.

> I want management by geeks and hacker ethics.

the two aren't mutually exclusive.

> I want to praise the artists which make KDE great.

kde-artists@kde.org

> desktop widgets are basically small applications that don't scale

they scale visually, and they scale to different device form factors. if you are looking for them to scale in functionality to, say, replace Digikam or Kdenlive, that won't happen. they are helpers and quick tools. they aren't supposed to replace applications on their own, just as an application like Digikam is never going to be something you'd put in a nice photo frame device to show some photo collection :)

> use a different window manager

they aren't windows in form or function. unless you consider the objects in inkscape, oo impress, etc. to be windows as well.

> WHO WANTS TO ROTATE A FUCKING WIDGET?

while many seem to enjoy positioning photos just as they'd like on their desktop (which is a fairly minimal reason for rotation), it's actually rather useful when you have a large flat surface that lays horizontally.

given that rotation is couple of lines of code and has resulted in ~zero maintenance overhead and does not impact your usage if you don't care about rotation, this seems like a molehill rather than a mountain.

> At least with Gnome every panel and panel applet is optional

it is the same with KDE Plasma Desktop.

in KDE 3 you were always stuck with a minimum of one panel, actually, and that is gone with Plasma Desktop where you can remove all the panels if you wish.

> Context menu items, keyboard shortcuts, and drop behaviors were broken and/or different from what konq or dolphin did.

little of that was easily sharable when folderview was started. with each release, the people working on the file management components (konq, dolphin, file open/save, folderview) have been pulling this kind of code out into libkonq (in kdebase-apps) and libkfile (in kdelibs; this is actually where most of this stuff exists now).

the was pretty much the same for kdesktop in kde 3, as well. it reimplemented a lot of interaction and functionality itself, but had a number of years to get there. folderview is already more advanced at this point, which is promising.

between the modularization of these file management bits into more easily sharable libraries and the more component-centric model of plasma, i really hope we don't have to go through a similar process again for many, many years (i won't tempt fate and add "if at all" ;)

"What I do need is for firefox to pick up on my application preferences"

OpenSuse has this; hopefully other distros will pick this up, or maybe even firefox itself will.

"for drag and drop to be snappy and accurate and always work,"

lots of improvements have been made in various places for d'n'd.

"for ark to not suck so hard,"

it actually works very nicely in 4.4

"for my folderviews on my desktop to always be up to date, look good, not pile up icons in weird ways"

if your folderviews aren't up to date, then there's a bug in the IO plugin (or it simply doesn't support automatic updates; some network IO plugins don't)

piling up icons in weird ways sounds like a bug; hopefully you've submitted a report for it with details.

as for the semantic desktop, don't use it if it isn't useful to you. it's that simple. however, with apps starting to use it behind the scenes, you'll likely be using it without even knowing it. you'll just be finding that things work nicely and wondering how all that information gets shuttled about. an interesting use case is the groupware system (akonadi) is now using the semantic framework (nepomuk) extensively.

"Kooka"

skanlite is what ships with KDE 4, and there recently was work started to ressurect a full "scanning workflow manager" type app (kooka+ style). aside from batch processing and OCR, skanlite does what kooka did with a rather more streamlined interface.

"porting to Qt-4.x (easy)"

i can see you haven't done much porting to Qt 4, at least not of any apps with serious amounts of code in them.

"and merging fixes (tedious), but maintaining compatibility with the existing installs."

that part would be doable, yes. some people want others to do it, nobody wants to do it, however. funny that.

"Having set up family and friends with (then-latest) KDE-3.x, and all of us using customized desktops, menus, and shortcuts, we don't want to start all that from scratch. No way, no how... "

i honestly doubt that your desktop is so customized, given what was possible with KDE 3, that a transition would be painful. your shortcuts on the desktop will show up in folderview just fine; your keyboard shortcuts will continue to work; your panel layout will need to be re-worked. in the meantime you get a whole lot of new functionality. many of the apps in KDE 4 are also mostly or completely backwards compat configuration wise. we kept compat in our dev branch for ~8 years with KDE2 an KDE 3 (note that KDE 2 was a similar break with KDE 1, though); in some places in the infrastructure it was time to move on so we could achieve things we needed to rather than be held hostage to old design choices.

in any case, mountain, meet molehill.

"Heck, can kpanels (or whatever they are) stretch across xinerama/twinview screens yet?"

no, and since screens can be different resolutions, there's no plans to do so either. this feature in kicker broke on many people's systems and gives no real benefit over a panel per screen, though it did mean more config UI.

"BTW, has KDE4 finally gotten the useful 'run command' in whatever they call kpanel now?"

the panel is part of Plasma Desktop (and it hasn't been called kpanel since KDE 1; where have you been the last 10 years?). anyways, alt+f2 does a lot more than KDE 3's "run command" ever did, including all the things you mentioned. it's also integrated into kickoff now too. there isn't a stand-alone Plasma widget that's included, though writing one shouldn't be very hard. just takes someone motivated to do so. there are a lot of things that are possible, but they all take a little bit of effort. thankfully, less effort than they did in KDE 3, but still some effort.

gwenview is the default image viewer in the KDE 4 software distribution, and the only one included as part of it. other image viewers are available as add ons as part of KDE Extra Gear.

"rather than hiding this info in a tool tip on mouse over it would be nice to see it in it's own column"

you can right click on the table headers and select PID as a column. it's not shown by default, true, but it is there.

> I thought Dolphin was getting a tree view.

it did. system settings did too. just turn them on in the view options.