Don't expect too much yet. While Kontact is certainly a nice thing, it's probably one of the least complete and least stable things in the 3.2 feature plan in this alpha. But we are getting there, thanks to all the contributors and especially to Matthias Kretz, who invested a really great amount of time into Kontact and KControl!

Problem is QT > 3.2 is required for this a2 release but QT brakes (somehow) kde 3.1.3. kde 3.1.4 is now in the stable tree and works with QT 3.2.1 (not my own experience). So, edit the QT 3.2.1-r1 ebuild, delete the line about kdelibs, emerge this QT, emerge kde 3.1.4 and emerge kde 3.2a2. I am compiling QT right now.

... since there are CVS ebuilds, too.
they also leave your stable version intact, so you can use it to play around
just head to http://dev.gentoo.org/~caleb/kde-cvs.html
I would advice to install ccache, too, since this makes updating much faster from the second build on.

The biggest thing missing from the kde-3.2alpha-series is the inclusion of the k3b from the kdeextragear-1 and possibly kmplayer and kmyfirewall from the kdeextragear-2, is there any chance that any of those could be imported to the kde-3.2alpha3?

Or are some/all of those going to pushed down the stream to kde-3.3/4.0, or even pieces of software never gonna be included in the main distribution?

I don't see how KMyFirewall belongs into the core distribution. It's not portable beyond Linux. It's probably nice to have and important such a tool and distributors should ship it if they don't have a solution already.

It's not that you couldn't install the packages on your own, is it? Plus most distributors ship packages of apps in kdeextragear.

Anyway, neither of those apps is in the feature plan, so the move won't happen. It's a bit too late to ask for it now, we better try to get the feature plan implemented and the bugs down.

the point of the extragear modules is to allow applications to be developed in KDE's CVS repository without having to be part of the KDE devlopment cycle, e.g they don't have to adhere to the feature freeze and so on.

I know it's a bad time to ask for major feature-requests, but I think this is a rather small request, as something similar is already implemented. KWin-III now has a "Window noborder" menu-entry in its title-bar context-menu, finally(!). How about having a separate submenu dedicated to window-borders, like Enlightenment has? It should have, IMO, "Noborder, Border only, etc." This is one of the features I miss the most from KDE-1.x days. KWin-III doesn't have an option to bring up the context-menu for windows which cannot get focus. This is a problem for f.ex. KPager when its in "noborder"-mode. Then you can't bring up the context-menu to toggle "window above others" which is really annoying.

Does this seem too much to fix before a 3.2 release? Every other window-manager that I have used have these features, and it's a shame if KWin wont have them.

You can set a keyboard shortcut to bring the window context menu of the currently selected one (which of course works no matter if there is a border or not)
I am not sure but I think the default shortcut is ctrl-esc ? Or otherwise it's alt and a function key, something like alt-f3. Anyway, look at the keyboard shortcuts in the control center and you'll see .. (I am unfortunately suffering on a windows system right now ;-)

I am also sure you can set a keyboard shortcut for this window-above-others switch.

Because a lot of people find it useless, and the developers (apparently) agree with them. I've never once used View Source, and I presume that most people who don't do web-development don't use it either. The menu is already getting too large, so they decided to kick out a little-used option.

PS> I'm not going to have this large-menu vs small-menu debate again. When somebody convinces Apple, Microsoft, and the GNOME project to change their HIGs, then I'll gladly concede the point...

That's some strange reasoning, if you don't mind me saying so. You don't use it, so you assume nobody else does?

I'm not a web developer, but I find it invaluable, especially for working out why some pages don't seme to work properly with Konq - not Konqs fault, it's usually some Javascript explicitly checking for IE - but without view source, I wouldn't know that.

You are forgetting one important usability axiom:
Optimize for intermediates
If you are looking for browser identification scripts, you are an expert user. A program/system should be open for expert use but not designed for it from ground up. Care shoud be taken, as it is here.

> That's some strange reasoning, if you don't mind me saying so. You don't use it, so you assume nobody else does?

That's not the point. The feature is still there; just not in the context menu. It's an advanced feature that even most intermediate/expert users just won't use. Stop Animations is gone from the context menu in HEAD now (change was made after alpha2 was released), but something like Set Encoding _will_ be used by a lot of intermediate users, as many languages need this feature.

> This is not about silliness like editing rc files or shortcuts or mouse gestures. Nobody should have to be an expert to have a conveniently usable KDE.

Yes, but the point remains that most people won't need view source, and thus, it will not be in the context menu.

Usability is all about compromises, we could stuff a number of things in the context menus that are only applicable to a select group of expert users, but we don't since it hurts the efficiency (this has been proved over and over again in usability studies) of the rest of us.

I would in fact advocate 100 item context menus if it didn't hurt efficiency.

I don't use view source that much and I'm all for making the context menus smaller. I would prefer to have this option available via right click but I don't think it is a huge problem to have to access it via konqueror menus or with some shortcut - since many people are complaining about it, assigning a default shortcut at least would be positive.

I do think however that kde apps should be as consistent as possible, and even though they are very different, IMO it would be positive if the source of emails (kmail), ng posts (knode), and web pages (konqueror), could be accessed in similar ways. Since I really want to keep this option accessible in kmail and knode, for sake of consistency, I think it would be nice to keep it in konqueror too.