Waldo Bastian, the KDE 2.x release coordinator, has announced that KDE
2.2.1 was packaged as a tarball yesterday and will be officially released on September 17, 2001. Those
of you expecting the release this Monday will be happy to know that the extra week was used to squash bugs. At about the same time, Dirk Mueller, the new KDE 3.x release coordinator (thanks, Dirk!), posted the projected KDE 3.0 release schedule. The short and sweet: first beta on December 3, 2001, first release candidate on January 7,
2002, and KDE 3.0 on February 25, 2002. Unlike the KDE 1 to KDE 2 change, this one
should be much smoother: Qt has changed far less, and very few (if any) core applications will be completely rewritten, as many were for KDE 2.

Since many of us now have access to *nix on several machines, a really useful thing the KDE could broker would be keeping running apps inside a session, and manage those apps. When you log out, you would have the option of killing all your running apps, putting them to sleep, lowering their priority, suspending them to disk, or leaving them as they are. Further advancements would be a graphical way to detach processes and leave them running (like compilers, for example)

Then when you return to login via KDM, you could return to the session you left alive, or start a new session (on a new display, if you're starting a new session on the same machine). All of this would be run over SSL, meaning that we wouldn't have to worry in the future about security complaints (or at least they'd be easy to fix). And one could easily add VPN support.

I don't know how hard it would be , and I would welcome comments on where the difficulties might lie.

Uses:

I leave my box running at home when I go to work. My roommate could come and login and use apps that run out of her own home directory, without me killing all my own apps. Since I have a 1GHz box, this shouldn't be all this big a deal.

I leave apps running at work, and could pick up a session right where I left it, either from home or work, just by logging back into that session.

this sort of session management sounds like a real good idea.
But it sounds like a heck of a job because of all needed interaction. I would be a lot of work _and_ it is not really required.

If you have a lot of MHz and RAM you can reach your goal (in this special prob. with your roommate) in this way:

Lock your running box with a blank screensaver (passwd activated). Then change to a new basic console (e.g. ctrl+alt+F2).
After this your roommate has to log in with his/her username and passwd. Then he or her will be able to start a second X-session with:

startx -- :1

(BTW: There is a space between "startx" and "--" _and_ there is a space between "--" and ":1" [The most common failure ;-)] )

Voila. A independent X-session will open with the standard windowmanager!

At least when you use SuSE 7.2 or other systems with support the WINDOWMANAGER variable then also those versions should also work:

This works very fine for me ;-)
Now you can change between those sessions with e.g. alt+F8 and alt+F7 or whatever your standard for X is.
(Do not use :0. This is normally the default X-session.)

(Warning: It should work, but if you log in twice as the same user you maybe will have some probs. I have also observed strange effects when i use two different windowmanager at the same time in two independent X-sessions. I dont know why. :-( IMHO it should work. But maybe thats only a effect on my custom build box with its strange configuration. So my fault. ;-) )

I've never seen any satisfactory answer to that:
why does KDE use aRts ???
1- this is the worse piece of software included in KDE, it leaks memory like hell (seems worse in kde 2.2 than before, btw), or it crashes without any reason...
2- everybody outta here use ESD (look at flash, realplayer, etc.)

can't we modify ESD in order to give him an aRts interface for backward compatibility, and go on that way ? or is MCOP compatibility too hard to implement ? in this case, why not implementing ESD compatibility ?

anyway, maybe i'm tough, but it's very frustratring that it crashes all the time, and not to be able to use esd-compliant progs (artsdsp doesn't work well at all). or maybe i'm the only one still using an old sound card with only one audio device ?
btw, KDE 2.2 has decreased memory consumption, but processes are more keen to have memory leaks. after a quick look at bugs.kde.org, seems they're all known... waiting for 2.2.1... maybe they will be a 2.2.2 ? ;-)

I wish they'd fix the problem with utf-8 charset webpages, I've made some changes to ttmkfdir2 to make my truetype fonts available as unicode and that fixed most of the problems, but for pages that rely on the default font it still looks really ugly (take a look at http://www.kernel.org). I would like if they just defaulted to using the default charset fonts if the page doesn't specify the fonts itself, like all other browsers do.

We already have a new SMB slave that supports read-write access that has been developed by Caldera. Unfortunately it needs the new SAMBA library which is not yet included in any of the stable SAMBA releases.

I've attached a screenshot of stuff I've been doing while my internet has been out.

a) It's obvious the k-menu is copying from microsoft's start button
b) wharfs are easily more usuable than that
c) wharfs (and NeXT's user interface), at least in my opinion, is the pinnacle of UI design, it does everything right, at least with their "panel" : It puts it on the right-top, it makes the icons larger
d) starting an app with kicker takes very much siginificantly longer than a wharf: (kicker) move mouse, click, move mouse, move mouse, move mouse, click; (wharf) move mouse, click, move mouse, click
e) Users have difficulty identifying apps for the first time by icon, all wharf buttons can have captions.

Today is Tuesday September the 18th 2001 and it still hasn't been a Offcial release for KDE 2.2.1 on www.kde.org, and so far there is no sign of the release except the directory. Don't feel rushed, take your time and do a good job.

Well, here's my input.
1. Perhaps the k-menu could be turned into an applet, which has many reincarnations and the user can choose whichever suits them

2. Is it hard to implement animated cursors? how about colour cursors? well it's just that I go to use windoze and it has this fancy cursor, much more configurable and better looking than the X one. maybe KDE can implement this?

3. I second the idea for a theme/style creater.

4. Maybe some fancy animations? like a button which flips over when the mouse is over it? or like the superflous option in WindowMaker the window explodes?