As the first beta has been delayed to finish more PIM features, we're proud to present the second alpha release of KDE 3.2. The first alpha was already seen as a very strong release and the second one is even better with 1374 bugs closed in the last 31 days. The major changes are the import of KSVG and KPDF into the KDE distribution, along with a major rewrite of the window manager. You can download the new release here. The are currently no binary packages, but you can of course use Konstruct to build it. Please give this one a good testing as we'll be moving to the beta phase next.
I am all excited and just building it. Hopefully this time -pedantic won't be a problem in configure (it was last time, Debian Sid gcc) and I can finally have a peek at Kontact.
Time for the killer app: Kontact.
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!
The -pedantic errors where not in konstruct or even KDE at all. They are mistakes in glibc 2.3.2, and discovered by a new strickter gcc 3.3.
Hi there :-)
Thanks for pointing this out. I guess I shall watch for updates on libc then (actually I am not on Sid, but mostly testing if I can).
Ok, I'm a emerge -u world freak. I just can't wait for KDE 3.2.
BTW, is there any chance to get kwin shadow and kdesktop icon shadows in KDE 3.2? I've patched my ebuilds for 3.1.x, but an official release with this patches would be much better :-)
 Won't ever make it. It's an evil hack and it's slow as hell, especially on shaped windows. And it's not stable enough.
 Something similar is implemented since quite some time. Alpha1 has it already. Just enable it.
 and looks -- if working properly -- crappy; glichy -- if not working
The second patch has already been in KDE for a long time. What i'm disappointed with is not having the options in kcontrol for configuring it. :(
(and it also comes with a throughily crappy default)
Put this in your kdesktoprc:
The default's is actually pretty good if you adjust the surround colour to fit in with your colour scheme better. The solid white on black default is pretty nasty looking and not easy to read.
The best thing about the KDE shadow style is it's not a copy of another operating system's style.
I have not yet tried it, but it looks good to me and easier to read than shadow behind.
Why aren't they using an OS X, GNOME or XP like shadow by default. I think the default looks worse than none at all.
Come on people, let's have some GOOD defaults.
Anyway, Alpha 2 seems to be pretty good over all, thoguh I hope that this isn't true: http://osnews.com/comment.php?news_id=4658#147610
> Come on people, let's have some GOOD defaults.
submit a bug report
"emerge -u world freak" -> You are using Gentoo Linux.
KDE 3.2alpha1 is already in portage...
1. Try grep kde /usr/portage/profiles/package.mask
2. sed s/=kde/#=kde/g or hand-edit the file
3. ACCEPT_KEYWORDS="~x86" emerge kdebase
KDE 3.2 alpha2 is not yet in portage. The KDE 3.2alpha1 ebuilds only need little modification to be used with a2. The version I used (my usr/local/portage) is here:
1. wget http://xiando.homelinux.net/gentoo/xiandos-portage.tar.bz2
2. tar xfvj xiandos-portage.tar.bz2 -C /
3. Verify that PORTDIR_OVERLAY=/usr/local/portage in /etc/make.conf
4. ACCEPT_KEYWORDS="~x86" emerge kdebase kdenetwork kdepim
KDE 3.2 is installed alongside KDE 3.1, so it is very safe to install both and experiment.
KDE 3.2 loads Konqueror much faster, has very nice transparent kicker and eyecandy like:
kcontrol -> Appearance & Themes -> Launch Feedback -> Busy Cursor
and is generally fun.
But kcontrol -> change icon theme, and any open Konqueror window crashes... so you'll be visiting bugs.kde.org a few times..
I tried to install the officiel kde 3.2 alpha 2 official package but it conflicts with kde 3.1.3. So i guess that you can not install both of them together.
It doesn't conflict. It's just masked. You'll need to comment the lines out in package.mask if you want to install it.
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.
will keep you busy for the next 36 hours ;)
... 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.
As for being imported for alpha3, there's no chance.
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.
Agreed.. it should have a Window Type Submenu.. right now there are five entries that could into that submenu (Above others, below others, full screen, no border, store window settings)
Just add the other window types that kstart allows, and it'll be great!
Submit a wishlist for kwin.
I don't know if it's a bad time or not, but it's definitely a wrong place. The right place is bugs.kde.org .
For the second part of your request :
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.
Can anyone tell me if View Source is back in the Konqueror context menu? That alone would be worth the upgrade!
No, and it likely won't be in 3.2.
Then I'll just switch to Mozilla - perminately.
That's a bit of a shallow reason to switch. Just assign a keyboard shortcut to view source.
Or, you could just download clee's .rc files, which puts View Source back, but its your choice.
Everyone is going to have to make *some* compromises. You lost this one. Don't whine about it.
*Why* was it removed?
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?
let me be hugely off-topic and propose to have 'Properties' allways as the last itmes of the context menu... This makes an UI so much more consistent.
Do you use HEAD? Properties is almsot always last. The only case I can't think of is sometimes in the sidebar. That looks like a slight bug though.
Here's what I do:
- I assigned Ctrl-U to "View document source" (same as in Moz)
- I assigned Shift-Ctrl-U to "View frame source"
and I won't cry a single tear when the two options
are removed from the menu although I really need the two actions
I wholeheartedly agree that the right mouse
button menu has become way too large.
how do you assign those keys?!?!
In a Konqueror window:
Settings menu -> Configure Shortcuts
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.
I am not a web developer and yet I find the feature very useful in the context menu. So that disproves your entire premise.
It's just like Mail. You always want easy access to the source.
By removing this feature from Konqueror you have disrupted my workflow for nothing. Meanwhile there is useless stuff like "Security..." in the menu.
> I am not a web developer and yet I find the feature very useful in the context menu. So that disproves your entire premise.
I said nothing about web developers. I just said that most intermediate/expert users won't need to use this. Most don't. This is all about compromises. Not everybody is going to get what they want.
> I am not a web developer and yet I find the feature very useful in the context menu. So that disproves your entire premise.
Just assign a shortcut key, or perhaps a mouse gesture through khotkeys2.
If you're enough of an expert to read the source of something, you should be expert enough to do this.
This is about KDE usability.
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.
> 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 think there is enough proof that removing View Source was a mistake and broke UI usability for many people. I don't hear people complaining about anything else having been removed.
For god's sake just remove "Security..." and replace it with View Source. :-)
The developers don't agree at all. Look at kdedevelopers.net and you'll find a lot that disagree.
KDE Developers != Konq Developers/People who contribute to Konqueror
I cannot understand that either, in times where spam, worms spread like nothing else, you cannot even look at the mail source??????
I often get mails that look empty, looking behind the scene shows, it's a self generating worm, that generates an exe if you using IE, looking at the source reveals it.
I'm not using KMail and won't if they think about small menus, look at all the other mail programms, and I have never heard about the fact that someone said they have to many entries in the menu.
Read again! This isn't about KMail!
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.