Waldo Bastian, the release manager
for KDE 2.2, hasposted
a revised schedule for the next major release of the KDE core applications
(KOffice is on a separaterelease
cycle). The schedule has slipped somewhat to provide time to add
some major new features to the next release, including such popular
wish-list items as (1) a better printing framework; (2) IMAP support
in KMail; and (3) improved database support with KDE-DB. The schedule
now contemplates an alpha release on April 16, beta releases on
May 14 and June 18, and the final release on July 16 (109 days, but who's counting?).

Comments

I'm glad everything got pushed back a little bit. It seems like there has been tons of releases the last few months. This will give us users more time to digest 2.1.1 and give better feedback! Good job KDE guys!

- Add a popup menu when clicking at menu items with the right mouse button.
-> open
-> open in konsole
-> cut
-> copy
-> copy the link (stored in *.desktop)
-> paste
-> properties

The clipboard:

- Deactivate the autocopy/paste behavoir of X:
-> Marking text with a pointer device (in X) owerwrites all information
cached in the clipboard.

|
> If you want to mark text to delete it, all clipboard information,
like filenames and text passages, are lost.

System administration tools:

There is lack of administration tools in KDE.
Many people prefer to edit configuration files.
There are also inkompatibilities between different applications and UN*XES,
but many users and admins don't have enough time and skills
to fight through various types of docs and manuals.
There is need of graphical system configuration tools in KDE.
It's difficult for the masses(Win9X/Me and WinNT/2k users/admins) to migrate to
Linux (or other UN*Xes), this has to be changed.

KDM:
- Toggle between different resolutions, color depth or even X configurations
-> Games often need different resolutions and color depth.

KEYBOARD auto-repeat and RESOURCE management:
Keyboard auto-repeat should be disabled while holding down CTRL, ALT or other special keys.
If the system is out of resources you should be refused to start new apps
until others are terminated. The user needs the possibility to logout at any time.

Hold down CTRL and ESC in KDE2 for some seconds and the whole system gets messed up.
This is caused by keyboard auto-repeat and missing resource management.
Lots of KTOP instances are started until the system freezes and even the X server cannot be killed
with CTRL+ALT+BACKSPACE.

If you have any further ideas about how to improve KDE post them or even better start coding.

The Kicker upgrade you proposed is a straight way to The Great Confusion. And the current (2.1)version isn't perfect too. When I want to start a program and click on the big K I often get a little plus, drag'n'drop starts, some icons landing on my desktop - God knows what happens, a few mouse moves and I have my desktop reconfigured. This horrible Drag'n'drop should be removed ! The interface design should be very simple and clean. If you want to change the menu start menu editor.

Themes:
Controlling the placement of window buttons over all themes isn't really possible with the new KWin architecture. Instead, what we need are more themes to choose from, because they decide themselves where the buttons are placed.

Animated MNGs everywhere:
I'm not sure that's desireable, or even possible! I wouldn't like it, it would be like Internet ad hell! Flashing, animated thingees everywhere! Besides, that's just asking for bloat, slowdown, and screen flickering.

Kicker menu:
I'm not sure we should go the MS route and make everything in the menu draggable and right-clickable. I think instead we should focus on making the menu editor better. If you want a program opened in a Konsole, simply open a Konsole and type it's name.

Clipboard:
I agree that the behavior of the X clipboard is annoying, however, that's a QT problem, not a KDE problem. AFAIK, it will be fixed in QT3. There will actually be 2 clipboards - a Windows style one and an X style one. They will be completely independent, so you can use either one exclusively, or both if you want. Choice is good!

System Admin tools:
I can only agree that there should be better admin tools. However, it is very hard for the KDE team to do anything about this, because they can't single-handedly create and maintain 50 different versions of each admin tool, one for each OS and each distribution out there that KDE is used on. (and it really would require 50 different versions because each distro works differently). The only solution is for distributions to do it themselves.

Resolution/color depth changer:
That's mostly an X problem. A graphical X configurator would be nice, but that falls under the category of hard-to-make admin tools discussed above.

Keyboard auto-repeat:
Auto-repeat should NOT be disabled when Ctrl or Alt are pressed! Think of the poor Emacs users! Many other Linux programs would become much harder to use if KDE did this.

Resource management:
A bad idea. There is simply _no possible way_ to tell how starting another application will affect the responsiveness of the system (or to tell what level of responsiveness the particular user deems acceptable). Any attempt to make something like this would simply serve to frustrate users who ran up against the limits. The obvious solution to the bad situation you describe is to make KSysGuard a unique application: that is, only one instance of it can be running at one time. Running it again would simply bring up the already-running instance.

Also, anytime Ctrl-Alt-Backspace doesn't work is an X bug, not a KDE problem. Badly behaved programs should never be able to crash your X session.

>If you have any further ideas about how to improve KDE post them or even better start coding.

No, don't post them here! Go to bugs.kde.org and file a wishlist item. That's what the wishlist is there for!

Has arts been excluded from the key important issues ? I remember reading the output of a chat session wherer there was a whole discussion on the topic and how to give a *serious* face lift to the sound server.

i wish aRts was optional. i have a sblive that already supports playing multiple sounds through /dev/dsp so i don't need aRts. it just waste alot of resources for me. also some programs (like Jezzball) don't have sound unless you are using aRts. i think this should be an option at compile time to use arts or not..

I'm not sure (for I haven't really programmed KDE2 yet), but I think it won't be possible. There had to be a "stub" interface in the KDElibs in place of sRts then, and after all the analog realtime synthesizer supports much more features to the programmers than just mixing into /dev/dsp

Shoot! Since the release has been pushed back, I won't be able to download KDE 2.2 on my cool Ethernet connection here at college using apt-get. I'll be stuck downloading it over a 28.8 modem, at home during the summer. Yuck. And I'll have to use Windows, because I have a winmodem. Double yuck! Oh well, it'll be worth it.

Kernel 2.4.2 supports winmodems? I believe you are mistaken. A few isolated types of winmodems do have drivers under Linux, but of course the one I have isn't supported. The vast majority of winmodems aren't supported by Linux. And it isn't possible to make a generic "winmodem driver" because each type of winmodem (each chipset) is different. So it isn't really possible for kernel 2.4.2 to "support winmodems" because it would have to have lots and lots of drivers, one for each type.

Kernel 2.4.2 supports winmodems? I believe you are mistaken. A few isolated types of winmodems do have drivers under Linux, but of course the one I have isn't supported. The vast majority of winmodems aren't supported by Linux. And it isn't possible to make a generic "winmodem driver" because each type of winmodem (each chipset) is different. So it isn't really possible for kernel 2.4.2 to "support winmodems" because it would have to have lots and lots of drivers, one for each type.

Well, you should first use the summer to get rid of Bill Gates, then make your Winmodem running in Linux as I did it on Suse 7.0 on my Compaq notebook. After having done those things FIRST you should be able to download KDE 2.2 without any problems.
Matthias

Does anyone know if in 2.1.1 it is possible to have an external (hideable) taskbar like in KDE 1.x? I just upgraded to 2.1 and I thought that I read at one point that they would fix that, but I haven't read anywhere whether they have. Just curious.

Well, you can add an external taskbar, but I am not sure whether it can be made"hidable". Right-click on the "handles" of any section in the main kicker - i.e. verical bars with raised dots - for instance near the clock - select Panel Menu -> Add -> Extension ->External Taskbar..

I use kicker with auto-hide option and the taskbar-applet only. The standard KDE stuff (clock, page, K-menu...) is on a solid child-panel.
I *think* you need Aaron's patch from kde-devel mailing list to have a instant child-panel after starting (or you have to start kasbar)

I fear it's impossible although it was the feature most anticipated by me for KDE 2.1. :-(
Kicker currently is far from beeing as cool and configurable as GNOMEs panel which is the Reason I'm using a mixture of KDE and GNOME. (They interoperate nicely, BTW.)
What I's *REALLY* like to see in KDE 2.2 is
* (auto)hideable child panels of an arbitrary
. size,
* corner-aligned panels additionally to the
. default edge-aligned
* _serious_ kwin extensions like configurable
. window borders on a per-app-basis, the ability
. to remember a window's state (like E does.),
. cooperationg with "managed" Wine-windows,
. animated desktop switching, animated shading
. of windows, ...
* or, alternativly, if that is not possible,
. making kjava work with other WMs than kwin so
. I can continue to use my Enlightenment,
. GNOME-panel, kdestop, Konqueror-Environment
. with emmbedded Java applets...

Not really actually
because the API is pretty stable, you usually
don't need to change anything in your app
everything (like menu animation) is done by kdelibs unless you want to use a new feature like kprinter for example.

Now coding in kde cvs is another matter
you have to keep up with the every day changes.
But it is not that hard since the technological choices were usually the good ones:) (like C++/Qt for example)

If i'm not wrong, the change to the print framework is only about the printer management (adding a new printer, on the network, on the parrallel port, default page size,..).
this is done via CUPS, but the system supports plugins (like LPR, LPRing etc).
KDE does not not (AFAIK) need a printing framework ala open2d (or whatever the name of it is ;o)), QT provides it already (QPainter).

Of course it can also be that i'm misunderstood and that i say garbage. correct me then! ;o)

I meant the OpenOffice equivilient to QPainter, I'm also not sure why KDE dosen't use imlib and other stuff, it would be very eisy to make performance good more than now, if some stuff not TrollTech's was used.

For your information, the new KDE print framework _is_ QtCUPS and KUPS together (I'm the author of them), but completely integrated into KDE. This means that all KDE apps will use the QtCUPS print dialog, and there will be a KControl module for print management (like KUPS). The nice thing is that I switched to a plugin architecture allowing to support other print systems as well through the same interface. For example managing printtool printers (RedHat) with a KUPS interface.

Yes and no.
The KDE print framework is not only a print managament tool, but more an intermediate layer between KDE applications and the underlying print system, which provides a nice user interface to control print job. The applications just send their drawing primitives to the system, and the framework takes care of sending the print job to the printer using the selected print system, print options, ...
But this is not a rewrite of a QPainter class. Qt does a good job, and the print framework uses it internally.

It would be great if KDE had a standard intallation program (untar, unzip, make menu shortcut, resolve and install dependent libraries, etc) for itself or applications that are in apps.kde, for example.

Search the Dot archives - there was an article about an installer that was being worked on. In the meantime, I recommend that you try Debian. You won't be sorry! Here's how I install KDE:

apt-get install task-kde

That's it! apt-get then goes out on the Internet, downloads all KDE packages _and_ dependencies automatically, then installs them and configures them in the right order, while I read a book :-) Upgrading works much the same way, and I usually have updated KDE packages downloaded and installed even before the release has been announced! I can hardly begin to express the complete and utter coolness of apt-get.
And of course, this works for any other program that has a debian package.

Slightly OT: A big thank-you goes out from me to all the Debian KDE packagers - THANK YOU!!!

It would be great if KDE had a standard intallation program (untar, unzip, make menu shortcut, resolve and install dependent libraries, etc) for itself or applications that are in apps.kde, for example.

I have a question. What has happened to the ablity to hide the applet handles on kicker, like you where able to do in 2.0. Since upgrading to 2.1 and 2.1.1 I have not been able to find this option anywhere, it seems to have been dropped from kcontrol. I realy liked this feature. I now have to edit the config file by hand when I change to option.

Anyway, I would realy like to see this added back in for 2.2. I did enter a bug report when I first noticed but I never got a reply.

Since the 2.2 release has been pushed back, I think it would make more sense to release a 2.1.2 in about 6 weeks after 2.1.1. And even a 2.1.3 6 weeks after that. That way, we don't have to wait till July for new fixes. But then 2.2 will come with its own bug to be fixed in 2.2.1 :)
We need a stable version to go back to. Too much change too fast is bad too. KDE guys should stabilise a release more than they have been.

Why not give the next release plenty of time instead of pushing back the schedule. It's beginning to sound like MS and it disappoints many.
KDE 2.1 is excellent and we can survive until the next one is technically superior and reliable. Need a better KOffice to handle MS Word docs and Kmail to handle existing email addresses.
Programming is the best I've seen for any GUI. Kudus to all.