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
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.
> - KWallet's dialog boxes still too wordy.
Which words did you want removed?
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.
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. :-)
this duty of 'whats this' help
Precisely. This is also the reason for mentioning "KWallet" directly --- so users can look up more information in the online help.
> - Some missing icons (eg: new Google context menu entry).
Just visit Google once (e.g. by using this menu entry).
can you please post some pics?
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?
I think menu item spacing already improved in Qt 3.3
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.
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.
> - Not nice use of separators between buttons in KMail (too many)
Which would you remove? The current grouping seems logical to me.
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).
> - 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?
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.
> 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
There could still be some more spacing there --- I'm pretty sure KDE allows for arbitrary size buttons.
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.
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.
will always do a good job on selling .
There is nothing to sell, no final product exists and even if someone would offer you the same for free.
>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.
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..
Logik? Korporate Identity.
*lol* ... great :-)))
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.
It *is* officially "KDE Kontact" (because of Samsung Contact I assume).
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 :)
The g prefix is for GNU usually.
Many GTK and Gnome applications use the 'g' prefix as well.
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).
To feed the Slashdot trolls of course!
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.
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.
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.
"Even more, 3.3's Konsole at least is able to use X.org's real transparency"
> 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.
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.
Nit pick, it's 4.3 rc2 not 3.4
there is also xouvert and y-windows, so we can just wait (or contribute to one of them)
There is also Fresco (http://www.fresco.org), GNU Hurd and OpenParsec. ;-)
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).
the higher level of code, the more its portability, so kde has good chances to survive after The Great Y Coming
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.
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
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
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
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