David Faure, the KDE release coordinator, has posted the KDE 2.1 release schedule. The summary: KDE 2.1beta2 is scheduled for release on January 29, and KDE 2.1 is scheduled for release on February 12, 2001. Read the post below.

Here is a proposal for the release schedule for the next two releases.

This schedule gives the 3 weeks of message freeze that the translators asked for,
and gives us a feature freeze of 3 weeks too - hopefully enough time to close
everything on http://bugs.kde.org :-))

An alternative schedule would be to add one week between the two releases,
i.e. delay 2.1 final by one week. I suggest that we don't plan to do that, but we
keep this option at hand in case beta 2 turns out to have too many bugs.

Comments welcome.

KDE 2.1 Beta 2
=============
Friday 12/01/2001
The HEAD branch is frozen again : no new features, bugfixes
commits only, no commit that modifies an application's behaviour,
and **message freeze**.

Monday 22/01
The HEAD branch of CVS is tagged KDE_2_1_BETA2, and tarballs are made.
They are made public immediately, and given to packagers for creation
of binary packages.

Friday 26/01
The binary packages are uploaded to ftp.kde.org to give some time for the mirrors
to get them.

Monday 29/01
Announce KDE 2.1 Beta 2

KDE 2.1 final
=============
The HEAD branch remains frozen since Friday 12/01. Only bugfixing,
there is enough of that to do :)

Monday 05/02
Last day for translations, documentation, icons and critical bugfixes
commits.

Tuesday 06/02
The HEAD branch of CVS is tagged KDE_2_1_RELEASE, and tarballs are released
to the packagers.

The rest of the week is spent testing the tarballs, packaging and writing the
announcement and changelog.

Friday 09/02
The source and binary packages are uploaded to ftp.kde.org to give some time
for the mirrors to get them.

Monday 12/02
Announce KDE 2.1.

--
David FAURE, david@mandrakesoft.com, faure@kde.org
http://www.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

Comments

for a beta release it is better that most people try to compile the code before using it to detect compile-time bug specific to a particular system.
But i believe that binary packages of KDE2.1 final will be avaible just after the official release.

I'm sure someone at Mandrake will make Mdk7.2 RPMs out of 2.1final, and even of 2.1beta2. Look for them at www.mandrakeforum.com! I also suggest you install their 2.1beta1 RPMs; they're pretty stable plus you can do your share of bugtesting :)

It's a shame to be dependent on a company - Mandrake - for RPM upgrades. Isn't this a bit like being a Windows user?

Sure, if you have time on your hands, you can legally hack it, that's good. But, you can't just go to the KDE site and download the latest version - you have to have a Mandrake format, or a Red Hat format or...

GNOME/KDE/Linux - still a long way behind Windows for the average user.

I'm only saying this because I believe it's true, and that it needs to change.

We're going somewhat off-topic here, but your message is a non-sequitor. If you're the `average user', you can wait until your OS vendor releases official binaries of KDE 2.1, just as you would do with commercial software. Meanwhile, if you're so inclined, you also have the choice of downloading the latest Beta and compiling it yourself with very little effort (it only requires a couple of minutes of your time, though your computer will be busy for a few hours). You also have the choice of using binary packages compiled by a third party (such as most of the ones on the KDE ftp site), if someone happens to have put them together. With Windows, only the first option is open to you. KDE/*nix may lag behind Windows in many ways, but this ain't one of them.

Installing QT and/or KDE from source is extremely simple in comparison to a number of other software offerings.

The various package formats are nice for figuring out dependencies... and giving you 'sorry... you need X to install Y' type feedback - but there are also sane methods for add/remove on installs from source.

It's a tough call - a particular vendor has visions about making things 'easier' - but it's probably better to keep help/troubleshooting as generic as possible... and leave it to the users of distribution-specific tools to read between the lines and adapt to their systems.

The Beta 1 release notes linked to further up the page mention specifically that KOffice is NOT included in the beta!!! What's up with that? IMHO, KOffice is an essential part of KDE, but it seems like it's getting very little attention. The majority of the KOffice website hasn't been updated in months. It's still got those same old "More Information Soon!" messages. Well, "Soon" has come and gone, and there is still no information there. Has such an important project been left to die? Or is it just that the developers haven't bothered to tell anyone about their work? (I'm hoping it's the latter)

Sometimes open source can be a bitch. We have been looking to do more with Quanta but you know when you have a life and projects you work on into the night...

What I was curious about is how your open source project is going? Well? Not a programmer? Did you know the programmer on kpresenter learned to program to develop that app? The thing you have to ask yourself is this. How does all this open source software get here anyway? it is sad how few people actually make a difference but amazing what one motivated person can do. You sound motivated.

BTW you can look at cvs and see what has been done by who and when. There is a web cvs to see all of that and it's at kde.org. Koffice is not dead... although kword has not seen much in recent weeks kspread is moving along, kivio has and krayon is seeing heavy develpment and is very encouraging. Graphite is seeing some work too.

Unlinking koffice from KDE is also not good conspiriacy theroy material. Putting krayon in a feature freeze this month is ludicrous... same for Quanta now that I think about it. It allows koffice to release seperately and manage it's development by it's needs and standards. Frankly koffice might be more feature rich today if it had been removed from kde 2. Hmmm?

All of koffice could use not only developers but documentation, input, encouragement... you could make a difference.

Sorry my last post sounded kinda negative, I don't want to make anyone mad. I'll have to take a look at CVS, and maybe look into making a KWord filter or something. BTW, I do have a little open source project, not related to Linux (actually a small game for the TI-89 graphing calculator). It's about done, and I've been wanting to get into KDE/QT programming, so I'll give it a try. Anyway, good luck to all KOffice developers, and I hope they can get their websites updated soon, even if they only say "We're still here! More next month!"

KOffice is still beta software. A newer snapshot *might* be included in 2.1, but it would still be beta. In my opinion, one of the big mistakes of KDE 2.0 was including KOffice without clearly mentioning its beta status.

The Mandrake Cooker rpms of kde2.1 post beta 1 and xfree86-4.0.2 contain anti-alias fonts. Of course you need to upgrade your glibc libs to ver 2.2 and download compat-glibc for backwards compalibility (also from the Cooker), but be beware you can seriously damage your system with this packages. (my 3d h/w accel hasn't work since I upgradeed to xfree86-4.0.2 and I get locale errors messages on perl and gtk apps since I upgraded glibc :(

For anti-aliased fonts you need:
- XFree86 4.0.2 compiled with anti-aliasing enabled
(the binaries from xfree86.org have anti-aliasing disabled)
- Qt compiled with anti-aliasing patch applied
- FreeType
Any KDE 2.X version will do, I'm using 2.0.1 myself. I didn't have to recompile KDE, only XFree86 and Qt.

Would anybody like to post some screenshots w/ AA enabled? I think I saw some a few weeks ago, but I think I also recall that not all of the desktop was stable/functional at that time either. Does it work perfectly w/ AA enabled? If so I'll bother to do the CVS thingy...

Well, all I had to do was download the latest X-Windows from xfree.org or wherever, install it using the script, hack around getting my login screen to work again, and voila, Anti-Aliased text everywhere! Really bloody good when almost every KDE program I run starts doing some run-away scroll bar flickering, and konquerer screws up badly when displaying it's own farging welcome page... see a screenshot: http://www.kyhm.com/~mbevan/images/kde/this-bruiser.png

It's so bad, I have to type this text either in a text-based bruiser, or Opera (opera good, but doesn't support a-aliasing.)

HelixCode Build a Installer Script for Gnome 1.2
It's is very good script, the installation take few second's.
but to install Kde 2.0 you need to Install some Rpm, that every one of them had dependences problam(Like Xfree dependence and more)
so if you will make a Installer that Install Kde 2.1, and solve the dependences probalm(by useing the internet, and website's like ftp.kde.org)
so if there is dependence problam it will be download by the installer script.

Hey loser,Why not run to your local bookstore and buy a book about kde and c++ programming.If you can't do that or don't have time to do it, how do you believe that other people will do it when it is already really easy to install packages...gee, get a life.

This is one of the points I was looking at and I sent a detailed proposal mail to Waldo but never got a reply. The KDE team thinks that its up to distro makers to package KDE and this is a fair point. My idea also means changing CVS around to a more package friendly manner so maybe this is why I got no responce? The mail is copied below.

Mail to Waldo:

[Snip printing blah]
I'm studying for my CCIE (high level Cisco thing) right now, my exam is in
Febuary once that's out of the way, my life is a lot easier; I can then
devote a lot of time to KDE.

On to packaging, I'd like your ideas on this: One of the "problems" I can see
with KDE is its packaging. The packages are too large and although they cover
a specific area i.e. networking, admin etc I don't want to install all the
bits of each package. For example say I wanted to manage my ftpserver via a
nice gui, I then also install a user manager, a cron job manager a dat drive
tool etc. Say I want an email client (kmail) as most people do, I also get an
archcie client, a mail reader, a PPP daemon config util, a AOL instant
messanger etc etc... Most users install KDE from distributions and this is
exactly what they see, a heap of apllications that they don't need and for
the most part don't even understand.

I think Linux has too many applications (well, to many similar apps anyway)
and too many options. Bizare as it might seem this holds it back from the
average user. I'd say with the current satus of Linux mainly power users and
techies use it, these users are the kind that only want to install what they
need. Of course this also can be blamed on the distribution makers but we
need to make it easier for them as well, the current way KDE make releases
isn't that effective.

Solution:

1. KDE core should be maintained as it currently is the 3 main packages:
kdesupport
kdelibs
kdebase

IMHO I think kdesuppport should be phased out if possible but this will take
time? Possible solution to getting rid of kdesupport would lie with the
distribution makers. I *think* KDE currently needs mimelib and libaudio from
kdesupport on my system even though it contains other packages, these aren't
compiled by default as I guess I already have them. Surely we can just make
these few libs a dependancy for KDE base?
Look at it this way, we need openssl for crypto support in konqy, this is an
important feature, why's it not in kdesupport? What about Lesstif for
netscape plug ins or a java implimentation? Of course mimelib and libaudio
are version critical to the correct operation of core fuctionality of KDE
where as the other libs mentioned above provide "nice to have" functionality.
Even so, I can see this only from two sides, which are:

A) Techie compiling KDE from source. If he/she has the knowledge to compile
KDE from source they should have the knowledge to get the dependant packages.
If he/she doesn't have the ability to read figure out why configure
complained about a missing package and read the README what are they doing
compiling KDE themselves.

B) Average Linux dude that installs from a distribution. The distribution
just has to package KDE correctly with the correct libs as a dependancy on
the KDE RPMs / APTS / slackwware packages. This can't be that hard, the
distro people should get this right (I'd hope or else their in the wrong
game), apart from that David Faure / Mosfet are at mandrakesoft, Bero is at
redhat, surely there are employees of the other major distros involved in the
core team that could advise their colleauges.

2. Seperate all the apps out of their current groups so that for example
kdenetwork, utils, multimedia etc are no more. A solution to this would be to
sort CVS out in to two groups:

A) released: These are apps that are currently maintained, are actively
developed and considered up to a high level. Basically 99% of the apps that
now make up the various parts if the distribution. New work is commited in to
HEAD as it is currently and releases are taged when the author(s) feels the
app has new fuctionality or a large bug sqashed. Of course releases should be
compatable with the current stable core release. When a new release is made
the tag should be packaged, for now this is a source only package in tar.gz
format (bare with me, works with the installer..). It must contain a file
called KDE_RELEASE, this file has a strict layout or is in XML and contains
at least all of the following information:

name
description
version
changes
importance

Once the tag has been placed and the KDE_RELEASE file added a script can be
run against CVS to automatically package it, copy it to the KDE FTP site and
remove the old version, it then gets mirrored from the KDE main site. The ftp
site would be layed out the same way CVS is:

Once every hour a script can be run on the ftp server to extract the
KDE_RELEASE file from any new packages if they exist (based on time created I
guess). This would update a file called KDE_RELEASES that lives in the root
of stable, obviously this file contains up to date information on all
released packages.

In it's self this is a far better way to release KDE for the power users out
there who want a stable release but can compile what they need from source
and I'm sure it will help the distros to package KDE better. This is not the
end goal, the installer is.

The Installer: The installer is a simple gui app that acts with two
functions, firstly it can install KDE once the base packages are in place and
secondly it can keep KDE up to date. In the KDE root directory on the local
machine lives a file called KDE_INSTALLED, this is a DB (XML / plain text) of
all packages installed on the machine and is created when kdebase is
installed. Its updated by the "make install" script when a package is
installed or as a post install script from RPM /apt etc. When the installer
is run, it loads the KDE_INSTALLED file and asks where it should check for
new packages, either locally or the Internet. Locally brings up a location
selector, so that for example magazine CDROM can contain packaged updates (a
lot of people are still on dial up) or to install 3rd party software
(something not released by KDE e.g. kcpuload). The Internet option connects
to the ftp.kde.org and downloads a list of current mirrors, the user selects
a mirror and the KDE_RELEASES file is download. The installer compares this
with KDE_INSTALLED and shows updates to installed packages + info such as
importance, description etc. If the user wants to install a selected package
they select download & install, the installer then gets the package and
performs a configure, make, make install. This exact commands should be
configurable so that --enable-final, install-strip or lib paths could be
could be configured for example.

As for installing KDE, the installer should have two radio buttons one for
update that works as described above and only checks for installed packages
and the second lists all packages where multiple packages can be selected and
installed. Further options are for the installer to live in the system tray
and check at regular intervals for updates from their favourite mirror, when
an update is availible for an installed package it alerts the user.

The future: I think up to now, this gives KDE a solid base to expand this
idea, sorts out CVS and it certainly lets the users decide what they want to
install instead of the ever growing kdenetwork, kdeadmin etc packages. It
helps the distributions and is atleast platform indipendant. The big problem
with this is that packages need to be compiled on the users machine so its
not perfect for everyone especially joe average. However, if the installer
does some checks on the development enviroment first it would satify a lot of
KDE users out there as I'm sure most have compilers installed?. The other
flaw is that it doesn't allow uninstalls to be performed which is I think an
important feature, this could be handled by having the KDE_INSTALLED DB
keeping a list of files that "make install" installed and having the app
update the DB if it updates a global config or adds files. This is not
really an elegant solution and duplicates functions of other software (RPM
/APT)

I haven't tought the next bit through 100% but the idea is to have the first
generation installer to get the source as above but to build RPMs and install
them using KDE's own branch under the RPM DB. This way the packages are able
to uninstall via RPM, this can be expanded later to use the installer to
check for updates to bin packages but bin packages create a new set of
problems like install paths etc. I personally like RPM but some distros don't
so there are politcal issues I guess, I do remember some distro writting an
apt to RPM layer so that any packages could be used

B) going back to the CVS stuff, keep the nonbeta part of CVS, might be better
to call it unreleased and move it to its own branch (if it's not already).
Once a package in unreleased proves it stuff it can be moved to released and
a first release can be made. Because everything would be a seperate package
it means that moving a package from nonbeta doesn't have to bloat up a
package group as is the current situation.

I think the installer app should be fairly easy to do and I hope there is
someone with the time to impliment it but getting CVS in the shape where this
will work might be a little hard?

Anyway, the stuff above is just a few ideas that I can see from the outside,
there may be very many reasons why this can't be done, but as I'm not that
involved with KDE, I of course don't know about them. If this is some use,
please feel free to forward it to the kde developers / mailing lists.

As my Debian colleague pointed out, the installer should be distro/os based. KDE runs on all versions of Linux, GNU/Linux, and BSD, as well as Solaris, AIX, HPUX..., and they all have different packaging systems.

Under FreeBSD, simply-->
cd /usr/ports/x11/kde2
make install

If you don't want to actually *build* KDE (an eight hour procedure on my machine), then use sysinstall.

when i install the i18n[he] of hebrew package
there is some probalms:
1. in the login i see only question marks (???)
i solve it by useing the contrl panel.
2. in the headline of windows in Kde 2.0 i see question marks even when i change fonts
3. in every program of kde 2.0 i can see hebrew characters(Iso-8859-8) it's all question marks

Any Desktop environment should be able to manipulate or configure the Whole system whether its linux or solaris or hpux, etc. KDE indeed has many utilities and applications which serves most of a desktop user's need. But still it lacks these. Some of these are built but not integrated as a KDE packaged application:

0. KSoundRecorder

Strangely enough a KDE user can't record sounds and encode mp3! though there are many such KDE application scattered on the Net.

1. Kfontinst. (Font installation)

Mandrake has drakfont which installs truetype fonts. Mandrake which is a big supporter of KDE uses a Gnome application for installing fonts! other distros don't even have such Graphical utility.

2. ZZplayer ( A VCD player )

3. KDVD ( a Dvd player )

The above ones are a must desktop environment's application. Still KDE only provides aKtion which uses xanim, again which limps to run an mpg file. It can't play a VCD or DVD!

KDE in no way tries to go beyond applications and become a Responsible desktop environment by trying to configure every aspect of a Linux (or Unix) system.

4. XKonfigurator ( XFree 86 Configurator )

RedHat and Mandrake has XConfigurator, SuSE has SAX. KDE can bridge this incompatibility by creating an X configuration system utility (as present in Corel Linux). I think you won't like extra work like Corel's!

5. KHardware! (KDE's Hardware adding and removing tool)

Network related stuff still not there is KDE!

6. Tcp/Ip (or Network Configuration)

KDE has no utility or tool to configure networking!

7. Samba.

8. Apache.

9. FTP (server/client)

10. Anonymous FTP (we have kwuftpd)

12. etc.

If KDE really want's to be the best desktop environment, it has to make life easy of its user and the Super User (Administrator's) life easy. My point is "Why isn't KDE including the MOST FREQUENTLY REQUIRED applications and tools, and not creating which are missing and there since a long time in other Desktop Environments, like Windows, Apple MacOS. How about QNX and BeOS? Do you like the ugly looking black mouse pointers?

Please don't mind but KDE needs some thinking and absorbing Good Features from Other Desktop Envrionment! Thank you!