"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.

the only time i delete comments on my blog is when someone steps over the line and starts being overtly rude, and then only after i've asked them to be constructive versus non-constructive. it had nothing to do with the idea of using multitouch (which has issues on non-multitouch devices, but anyways..).

"I wasn't necessarily saying Vala was an app development language (although it could be)."

GNOME devs are already writing full apps with it, so it is being used as such.

"If Gtk used some other language like, say, Python, with Python GTK widgets and so forth, then how would Java, C#, or even C or C++ have access to these components?"

yes, i understand that is what has driven Vala's design and implementation. i just don't agree with the "we'll wedge another home grown language in between the C and the other languages" approach. i think it's overly complicated and limits the number of people who can (and will) hack on it.

time will tell if i'm smoking crack or not, of course .. =)

"Vala isn't actually a language in the same sense as Python, C# or Java is. It's really just a syntactic extension of C and produces plain, simple, C code."

that is produces C is both a feature and a bug. it makes debugging much more awkward (and for a while wasn't even possible at all! how do you go from your generated C to your Vala code in gdb? there's a plugin now for gdb, but really .. oy vey!) and you lose all the interesting security possibilities of managed code.

"How will using Javascript help in GTK development or building custom widgets or extending GTK and its reach?"

it's simply a language that is well known. pick a different well known language if you wish. make your own runtime if you wish. certainly add your own sugar on top (see QScript for a really nice example of how that can all be done with JavaScript). there's nothing particularly magical about the Vala syntax, except that it's a new language specific to one toolkit.

which is precisely my point.

"it will be possible to extend and improve GTK to equal Qt while still maintaining the ability to use it from any language binding."

let's do this then: let's come back to this in 2-3 years (it takes time to get these things going, i know) and see if that theory works out.

my theory is that it will just be one more baroque tool that people working with Gtk will have to get their head around (and people complained about moc with Qt; they ain't seen nothing yet ;) thereby limiting the pool of candidate developers. as a non-transferable skill it won't gain much in the way of value that might cause people to learn it "just because", and yet people will write applications with it. i expect to see more and more vala usage in Gtk+/GNOME (because, well, that's already happening =) and it will cause the project to become more insular rather than less.

i do expect that those using it will get more done with vala than with plain C, but not to an extent that will make up for the number of people lost by not choosing a language syntax that is already widely known or a language that avoids compile cycles, dealing with the intricacies of C debuging, etc.

given that it's homegrown, it will also soak up resources maintaining and extending vala itself that could be put elsewhere.

combined, i expect individual efficiency of existing contributors to increase due to vala, but the overall effect on the project to be a net negative. i predict that in a few years vala will get quietly binned. bonobo 2.0 if you will: a cool idea that "just has to work, it's so well designed and advanced!" but which just didn't pan out in reality.

again, i could be wrong. and i certainly don't want to see the GNOME team falter. but vala gives me the heebie-jeebies.

"Isn't KDE4 the advanced desktop that just recently implemented the revolutionary feature of hiding panels?"

ha. ha.

yes, panel hiding was recently implemented (and with a neat hover-on-approach feature if you have a compositing window manager), but it also had a dashboard (where's that in anything not-MacOS?), multiple widget layouts on desktop, zooming and various other features you won't find most other places, or in some cases, anywhere else right now. take the whole picture in and it's a different story.

add in google gadgets, enlightenment 17 edje content support, ruby/python/javascript bindings, the krunner search plugins, the wallpaper plugins, the beautiful artwork, the general flexibility and the large number of widgets that come with it .. it's pretty compelling in 4.2 indeed.

and we have plans for much, much, much more.

as for kwin, it too has comes leaps and bounds. the number of effects have risen dramatically and the quality of the effects is quite high. the focus is on usefulness and beauty combined for kwin's effects, so you won't find the more silly effects you can in compiz, but you will find high quality, fast, functional ones. that includes the cube, cylinder and sphere as well as wobbling windows, if you're into that. =)

"but I think KDE4 has a ways to go"

check out 4.2. i don't think we have a ways to go at all, and currently about to start lapping both kde3 and the other desktop environments out there as we move on to yet further adventures =)

afaik, in Norway trolls are traditionally lucky creatures that live in the forests. so culturally it makes more sense. ;)

similar in that they are both canvases, but not similar in functionality or scope at all. check out this blog post:

http://labs.trolltech.com/blogs/2008/12/02/widgets-enter-the-third-dimension-wolfenqt/

it's pretty insane. =)

"The desktop should absolutely be configurable to the point where it could look like either GNOME or KDE"

that desktop is called "plasma". we'll be introducing layout switching for plasma in kde 4.3 letting you change between (or add to existing) layouts with the click of a button. you can already swap things about by hand, since the support for this was built into the design from the start, but making that part of the machine user accessible is kde 4.3 material.

plasma itself has no assumptions (or, really, knowledge) about what "must" be there. you can have 0, 1, 2, or N panels; any number of desktop activity layouts; even per-virtual-desktop layouts (experimental feature in 4.2; we hope to iron out the wrinkles and then expose it in the UI for 4.3) ..

so .. yes. we're going there. =)

i think it goes a bit deeper than the language choice, and the post you are replying to is probably talking about completely custom widgets vs customizing existing ones. that customizing existing ones is already not streamlined is a bit shocking, but ok, as you say, they are working on Vala.

the problem with Vala is the same problem with any niche language: nobody knows it. yes, i know, it's C#-ish. but it's not C#, and people will have to be taught that it is "like C#" first. creating and then supporting an entire language and its runtime just to make a toolkit easy to use is, to be frank, insane.

i completely understand why people make new languages, but the reason for Vala is one of the most absurd things i have ever come across. really, GNOME should just have picked something that already existed and leveraged the developer base already familiar with it.

instead they are creating a separate silo of code called Vala that will only raise the barrier to entry due to the solution applied in an attempt to lower it.

the gnome-shell team's adoption of javascript is much more sane and well thought out. GNOME users and developers really ought to hope that the rest of project takes a cue from gnome-shell and does something similarly pragmatic on the language choice front.

"rather will use it as the desktop containment"

having actually seen packages of 4.2, i can tell you that this is incorrect. i do expect *some* distros out there to do this, however. that's sort of why we have the feature there, of course. =)

"it takes time to rewrite the entire KDE project. "

just to put this into perspective, the only full rewrite is of the desktop shell. we added a lot of new library frameworks (Phonon, Solid, ThreadWeaver, Nepomuk, etc, etc.) did a massive amount of work on the existing libraries (particularly so that libkdecore doesn't require a GUI, sorted the functionality out properly so that they aren't massive globs of semi-random class collections, etc), introduced a number of new apps (akonadi, dolphin, the new printer configuration tool, numerous games, some edu apps ..) and obviously ported everything to Qt4. massive, massive effort, but it wasn't technically a rewrite, with the exception of the desktop shell.

which is why we didn't stop at 4.0 or 4.1. 4.2 brings ark back to usefulness, SSL cert config is there, etc.. i'm pretty sure i've even told you this previously on a different web board. *raises eyebrows* so let's not beat dead horses. =)

of course, we're not stopping with 4.2 either. stopping isn't in our plan at all, in fact. just better and better releases ...

your entire post is moot, as there are high quality Python, Ruby and Java bindings for Qt and KDE. in-application scripting with JavaScript is also fairly common now as well, though that's a bit of a different topic. bindings for Perl and other languages also exist, but the Ruby and Python bindings are the ones i recommend to people doing application development.

heck, KDE even ships an app written in python (the printer manager) these days.

so whether or not C++ is a good language, not a good language, easier or harder to bind compared to C or not is neither here nor there. bindings exist for "better" (according to your metrics) languages and work damn well. use them, be happy and step off the rather irrelevant soapbox.