Announcing KDE 3.3 Beta 1 "Klassroom"

The KDE Project is pleased to announce the immediate availability of KDE 3.3 Beta 1. As another step towards the aKademy in late August, this release is named Klassroom. This beta release shows astonishing stability, so the KDE team asks everyone to try the version and give feedback through the bug tracking system. For packages, please visit the KDE 3.3 Beta 1 Info Page and browse the KDE 3.3 Requirements list. The Konstruct build toolset has been updated for this release.

Dot Categories: 

Comments

by Rayiner Hashem (not verified)

Spiffy things:

- Konqueror display seems much nicer now. You don't get that effect where you see half of the old page while waiting for the new page to load. Everything get's drawn in one go now, which makes things look solid.
- Cool integration of Google into Konqueror.
- MacOS-style menubar follows the panel background now.
- Nice use of separators between buttons in Konqueror.
- Handy search field in kmail
- Elegant "highlight text view" effect in Plastik.
- Kopete's new buddy-list effects are *awesome*
- Very nice new Kontact splash screen (doesn't last long enough :)

Not spiffy things:

- Not nice use of separators between buttons in KMail (too many)
- New KMail search bar needs some margins above and below.
- I got four copies of kconf_update in my taskbar the first time I started up Kontact
- Some missing icons (eg: new Google context menu entry). Cervisia Konqueror plugin icon still phenomenally ugly.
- KWallet's dialog boxes still too wordy.

by George Staikos (not verified)

> - KWallet's dialog boxes still too wordy.

Which words did you want removed?

by Rayiner Hashem (not verified)

When saving a password, the current text is:

"Konqueror has the ability to store the password in an encrypted wallet. When the wallet is unlocked, it can then automatically restore the login information [the] next time you visit this site. Do you want to store the information now?"

Most of that is extraneous. The text should simply be:

"Would you like to store this login information in your current KWallet?"

1) It refers to specific program features by name, which is considered good practice.

2) It gets rid of all the preamble, which the user doesn't really care about anyway.

3) It takes the real question "Would you like to store" and puts that at the forefront, instead of burying it after a lot of other text.

(3) is particularly important, given that the dialog is not one of those "verb-button" dialogs, but rather a "yes/cancel" dialog.

by arcade (not verified)

Personally I would prefer a 'more' button or something, with an in-depth explanation of what such a feature does, where the passwords are stored, how they are stored, how they ar kept safe from others, and so forth. :-)

by Nick Shaforostoff (not verified)

this duty of 'whats this' help

by Rayiner Hashem (not verified)

Precisely. This is also the reason for mentioning "KWallet" directly --- so users can look up more information in the online help.

by Anonymous (not verified)

> - Some missing icons (eg: new Google context menu entry).

Just visit Google once (e.g. by using this menu entry).

by charles (not verified)

can you please post some pics?

by theorz (not verified)

What about the spacing between the menu items in programs (Location Edit View Go Bookmarks Tools...)? I have always found that they are too close together in kde making them all look run together. gtk2 seems to have the spacing about right. I heard something about this being adressed in a new kde releases. Has it made this one or is it waiting for something like qt4?

by wilbert (not verified)

I think menu item spacing already improved in Qt 3.3

by anon (not verified)

qt styles are free to change it at will in qt 3.3.x.. plastik-cvs uses something like 18px in my eyes.. old was 14px. gtk2 uses something like 16px.

by me (not verified)

For me it is more strange if you get asked if a password should be stored:
One the question if I want to store the password: It shouldn't be "Cancel" but "no" as a third choice.

by Anonymous (not verified)

> - Not nice use of separators between buttons in KMail (too many)

Which would you remove? The current grouping seems logical to me.

by Ingo Klöcker (not verified)

Besides, those separators have always been there. Only they were no line separators but just spacers. Now it was decided to use line separators by default for all of KDE. If you want to have it changed then send your complaints to the KDE Usability list.

BTW, you can remove the separators that you don't want (Settings->Configure toolbars).

by Ingo Klöcker (not verified)

> - New KMail search bar needs some margins above and below.

Margins? Why? Do you probably mean a line? I could understand that you want a line above the search bar, but why below? Below it's already clearly separated from the message list. Or maybe I don't understand the problem because I'm using Keramik?

by Rayiner Hashem (not verified)

Not a line, just some space. In Plastik, the search bar is right up against the message list below. It's actually a pervasive problem in KDE --- all the widgets are very close together, instead of being nicely spaced out. Arrows next to button icons (as in Konqueror's back/forward buttons) are scrunched up against the icon. Compare (say), Mozilla to Konqueror. In Mozilla, the buttons are nicely spaced out, and there are margins above and below the search bar. To me, maintaining esthetic appeal is worth a few dead pixels.

by Sad Eagle (not verified)

> Arrows next to button icons (as in Konqueror's back/forward buttons) are
> scrunched up against the icon.

That's because they're part of the button, not a separate widget

by Rayiner Hashem (not verified)

There could still be some more spacing there --- I'm pretty sure KDE allows for arbitrary size buttons.

by Ingo Klöcker (not verified)

In my opinion in Mozilla too much space is wasted by the extremly large spacing. But that's obviously a matter of taste. And as such it has to be solved in the widget styles.

by Rayiner Hashem (not verified)

Not a line, just some space. In Plastik, the search bar is right up against the message list below. It's actually a pervasive problem in KDE --- all the widgets are very close together, instead of being nicely spaced out. Arrows next to button icons (as in Konqueror's back/forward buttons) are scrunched up against the icon. Compare (say), Mozilla to Konqueror. In Mozilla, the buttons are nicely spaced out, and there are margins above and below the search bar. To me, maintaining esthetic appeal is worth a few dead pixels.

by a.c. (not verified)

will always do a good job on selling .

by Anonymous (not verified)

There is nothing to sell, no final product exists and even if someone would offer you the same for free.

by a.c. (not verified)

>There is nothing to sell, no final product exists and even if someone would >offer you the same for free.

and the reason for announcing this at the kde.org site and the dot is why?
Pure news? Or are we wanting others to download it, install it, play with it, then file bug reports and ideas? That is called selling. If it was to remain with the developers on the list, then it would never have made it here. and it certainly would not have been bundled up.

And yes, even at this stage, screen shots help.

by charles (not verified)

Can someone tell me the logic behind the numerous K(s) in KDE associated names? By the way, I love KDE and use it everyday.

Cb..

by Anonymous (not verified)

Logik? Korporate Identity.

by Anonymous (not verified)

*lol* ... great :-)))

by tomislav (not verified)

I agree that we need identity, but here is a suggestion: instead of "Kontact", "Kroupware", (Ksomething instead of [C|G|?]something) i would propse KDE + Name. For instance KDE Contact. KDE Groupware. KDE Name it here. That would be much more convinient.

by Anonymous (not verified)

It *is* officially "KDE Kontact" (because of Samsung Contact I assume).

by Carlos Leonhard... (not verified)

The same logic behind Windows WinApps, Mac iApps, GNU GNUApps, wxApps or gnome GApps: it is an easy way to tell something to the user, being the OS to run the apps, the maker, the toolkit, the desktop, whatever.

In KDE case, a KApps usually means "made with KDE technology and integration".

Now you know :)

by Max Howell (not verified)

The g prefix is for GNU usually.

by Patrick McFarland (not verified)

Many GTK and Gnome applications use the 'g' prefix as well.

by Dan Leinir Turt... (not verified)

Come on, do we really have to state the old truth again? "The everybody else argument doesn't work". There, that's done.

Now, I totally agree that the naming of applications is becoming rather silly. How is it that so few have inventive names? Unsermake at least is an interesting name. The name does /not/ have to describe the function of an application, that's what the comments fields in .desktop files are for.

from the Campaign In Favour of More Inventive Naming of Software (hereforth CIFMINS).

by Tom (not verified)

To feed the Slashdot trolls of course!

by anon (not verified)

I think everyone else did so back in 1996 when KDE was founded and the first crop of KDE apps appeared. CDE had dtterm, dtmail, dtfile, dtpanel, etc.. XWindows itself had xterm, xcalc, etc.. In the Windows world back then, everyone was coming out with products with "95" on their end, or "Win" at the beginning. In the Mac world, most Mac-only apps had "Mac" suffixes.

It's just a way of letting users know that an app works with KDE.

by Shulai (not verified)

KDE 3.3 XServer Requirement says:

Package: X Server (with link to www.xfree86.org)

Level: Required

Description: An X Server provides the underlying display technology on UNIX systems. The KDE Project recommends the XFree86 server.

With at least major Linux distributions using X.org server now, and XFree86 with an uncertain future, it this still correct, or just a forgotten detail?

Even more, 3.3's Konsole at least is able to use X.org's real transparency, so using XFree86 means that some (ok, trivial) features won't be available.

by Chakie (not verified)

I'd say those requirements are just copy and paste from some older requirements, with maybe some central libraries updated. I'd say there is no political statement behind the XFree86 requirement.

by Janne (not verified)

"Even more, 3.3's Konsole at least is able to use X.org's real transparency"

by Anonymous (not verified)

> 3.3's Konsole at least is able to use X.org's real transparency

You confuse the "X.org" and fdo's "X-Server" X servers.

by Janne (not verified)

Sorry, I screwed up with my earlier post

"Even more, 3.3's Konsole at least is able to use X.org's real transparency"

X.org does not have "real" transparency. You are confusing X.org to Freedesktops Xserver (which DOES have "real" transparency and other cool features). Current X.org is just Xfree 3.4 RC2 with few additional changes and fixes.

by Mark Hannessen (not verified)

Nit pick, it's 4.3 rc2 not 3.4

by Nick Shaforostoff (not verified)

there is also xouvert and y-windows, so we can just wait (or contribute to one of them)

by anonymous (not verified)

There is also Fresco (http://www.fresco.org), GNU Hurd and OpenParsec. ;-)

by Nick Shaforostoff (not verified)

hm, sounds interesting :-)

but Y is in development less thet a year, while freSCO - more the 5 years.
and afaik Y doesnt use slow CORBA (as well as kde).

by Nick Shaforostoff (not verified)

the higher level of code, the more its portability, so kde has good chances to survive after The Great Y Coming

by Mark Hannessen (not verified)

you are kidding right? it's the other way around. x is not THAT bad, so y only has a chance if most of the existing stuff can be ported without to many problems.

by James Richard Tyrer (not verified)

If only I could figure out why the KWin-Styles won't build.

.libs/nextclient.o(.text+0x1fea): In function `KStep::NextClient::menuButtonPressed()':
: undefined reference to `KDecoration::showWindowMenu(QRect const&)

It builds correctly with ALPHA_1.

--
JRT

by anonymous (not verified)

Your kdelibs version seems to not be the KDE 3.3beta1 version since kdebase/kwin/lib/kdecoration.cpp does contain the implementation for the KDecoration::showWindowMenu(const QRect&) method.

http://makeashorterlink.com/?T126351C8

by anonymous (not verified)

If I use for eg. IceWM (icewmtray), Gnome or any other Freedesktop compilant tray application?

they are already compatible with kdetrayproxy (which is included in kdelibs in kde 3.3), but available for kde 3.2 as well

by Iuri Fiedoruk (not verified)

The only two problems I found so far are:
- mouse wheel is scrolling horizontaly and not vertically by defailt, what is very annoying (does someone know a fix fot this?)
- kget crashes