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.
Dot Categories:
Comments
I think I'm in love with this quick one-release-a-month way of doing things.
Keep up the good work!!!
It is too fast...
I even haven't have chance to upgrade to KDE2.2 and planning to do it this week until I read this news of KDE 2.2.1 release.
Question: If I Install the KDE 2.2 now, is it easy to upgrade it KDE 2.2.1 or Do I need to download again all the libraries (20 packages or more)? Should I wait for KDE 2.2.1 instead?
> Question: If I Install the KDE 2.2 now, is it easy to upgrade it KDE 2.2.1 or Do I need
> to download again all the libraries (20 packages or more)? Should I wait for KDE 2.2.1
> instead?
Better wait until 2.2.1 is out. It fixes several bugs. For several reasons discussed >1000 times we do only provide the tarballs as a whole and most packagers create completely new RPMs, so there won't be a smaller "upgrade version".
Cheers,
Hmmm...this is only a rant/flame but if installing new updates is such a complicated matter with your distro, you can always switch to Debian and have everything done for you.
P.S. Daniel, "we do only provide tarballs" is not very grammatical. I believe that should read "we only provide" and the do is implied. [Major flame/rant]
I tried Progeny Debian last week, and the "latest" release of KDE for Progeny was 2.0. I found a site where I could get KDE 2.1, but it didn't have instructions on how to install it from within Debian.
I've been running SuSE Linux 7.2 for a while, and have KDE2.2 installed from several very nicely packaged RPMs, available from SuSE's LinuKS (Linux KDE Service) site.
Debian itself seems to be fine, but in order to get the latest and greatest, you almost always have to compile from tarballs.. so why even bother with Debian in the first place?
This is a serious question, not meant to be a flame or a cutdown on Debian.. I simply want to know.. with Debian having this great package management system.. how come the latest and greatest software isn't available on Debian when it is for other Distros, like SuSE, RedHat or Mandrake?
Thanks,
Steven
It's not?
merlin:/home/spark# apt-cache show kdebase
Package: kdebase
Priority: optional
Section: x11
Installed-Size: 16456
Maintainer: Ivan E. Moore II
Architecture: i386
Version: 4:2.2.0.20010822-1
You just have to use the "unstable" branch, easy as that.
And no, you system won't become unstable because you do that. ;)
It's just that you will NEVER find anything in stable that isn't tested out for months and you'll never find anything in "testing", that is just packaged (A few days after usually).
So use unstable but don't do a dist-upgrade, just fetch all the sotware you need.
You'll get all the latest and greatest packages, nicely packaged by over 500 dedicated maintainers, mostly a few days (or even faster) after the source is released.
KDE and Gnome packages are usually available at the day of their release.
I never have to compile from source, unless I want to try out a CVS version or a 0.0.1 app in development.
It's not?
merlin:/home/spark# apt-cache show kdebase
Package: kdebase
Priority: optional
Section: x11
Installed-Size: 16456
Maintainer: Ivan E. Moore II
Architecture: i386
Version: 4:2.2.0.20010822-1
You just have to use the "unstable" branch, easy as that.
And no, you system won't become unstable because you do that. ;)
It's just that you will NEVER find anything in stable that isn't tested out for months and you'll never find anything in "testing", that is just packaged (A few days after usually).
So use unstable but don't do a dist-upgrade, just fetch all the sotware you need.
You'll get all the latest and greatest packages, nicely packaged by over 500 dedicated maintainers, mostly a few days (or even faster) after the source is released.
KDE and Gnome packages are usually available at the day of their release.
I never have to compile from source, unless I want to try out a CVS version or a 0.0.1 app in development.
Jep, Debian is just GREAT for KDE. :)
Never had such a nice KDE installation and it was never that easy.
That was the first time I did with Debian back in the good old days of KDE 2.0 and that was the reason why I fell in love with Debian. :)
But this doesn't change the problem that upgrading everything KDE will be a pain for modem users. :) Especially if they have to pay for their onlinetime.
Fortunatly, that shouldn't be many anymore. :)
The main problem I have with Debian's KDE packages is that by default they install Debian's menu items in the same menus as the KDE-only stuff. I prefer to separate KDE apps from non-KDE ones. Similarly, I somewhat dislike how everything installs in /usr/share instead of like /usr/kde or something like that, but I suppose it's in the spirit of the FSSTND.
Minor gripes though. Anyway, keep up the good work, KDE and Debian!
Actually, it's in the spirit of the FHS :)
It's been a pain to complete the transition, lets not go back again :P
Hmm, for me Debian puts it's own menus in submenus, like
Utilities -> Debian -> Application
That's pretty handy.
Don't know why though, maybe it's a different "menu" version.
And if you don't like this at all, you can just do a
apt-get remove menu
This won't hurt you much.
About /usr, that's a matter of taste. I for one HATE seperate directorys for every desktop. I mean, usually 90% of my applications are from one desktop, so this is not ONE part, it's THE part of the system, that's why it should be in /usr and not /usr/kde or even worse /opt/kde! This is just causing incompatibilities.
Oh yeah, that's what I meant: Debian icons go in submenus of the KDE menus. I prefer to have a "Debian" submenu off the K menu and put all that stuff in there. Mostly just because most non-KDE, non-GNOME apps don't have icons (and the ones that do don't look nice like KDE ones), and I hate the look of a menu full of nice KDE icons mixed with "unknown" icons :)
Yes, just a matter of taste.
[And yeah, I meant FHS, not FSSTND. I knew it had a different name but was too tired to think of it :)]
Actually, I don't like it and I have several reasons why.
First: Stability. I like a cutting edge system, but I also want it to work. With only a month for programmers to find and fix bugs, releases get out that are not exactly stable. Also, it doesn't give a lot of time to optimize code. You can get it to work, but will it work fast and efficient?
Second: Upgrading. I would rather wait until a program has been fully implemented than to see little bits and pieces of improvement or fixes as releases go by. Its progress, but it doesn't seem worth going through an upgrade.
Third: Time. For nine out of 12 months I live on a college campus and have a blistering fast T3 connection. For the other 3 I live off campus and have a 56k dialup modem. Pretty soon I plan to live off campus 12 months a year (all year) and will have a 56k modem until broadband prices fall and it becomes available in whatever area I will live in. That said, it will take me quite some time to download the tarballs for a release. Compiling, too takes some time (even on a 1 gig Athlon). So I would want to actually spend more time in the windowmanager than getting it and compiling it. My grandmother is quoted by saying "I don't want to spend the rest of my life in front of a computer when there really isn't much left." She's pushing 70 years now and is moderately healthy, but you can understand her argument.
Fourth: Time. This is different in that it relates to the developers. This is free software and so any of the developers develop as volunteers. Consequently, I don't wish to rush them or crowd their lives anymore than they might already be because this college kid wants pretty fonts on a free OS. Also, I soon will be among the list of developers around the world, and intend to contribute to the open source community; still, I would consider it a secondary activity (if not a hobby), presumably as do many of the developers of KDE and its app family. Hobby should not take precedence over making a living. That may sound overly capitalistic, but "whoever said money is the root of all evil obviously never went hungry." I forgot who said that, maybe it was a rapper, maybe it was Murphy.
So thats my opinion, not meant to be inflammatory. Maybe I will be one of the KDE developers one day, or will develop a really cool KDE app. Only time will tell.
Is Dre colour-blind? Or am I?
The jury's still out on that one ;-)
¿Where can I suggest new features for KDE 3? I have read the announce and it seems not have many changes ...
¿What about a little redesign of the user interface (kpanel, i.e.), like XP (XP is beautiful, and MacOS X is more beautiful ...)
It's Kicker, not kpanel, and beauty is only skin-deep.
But in a GUI, is it not that skin-deep beauty that is vital?
That's like saying:
"Look a my Ferrari, it doesn't have an engine, but it looks great!"
but you buy a Ferrari for its appearance, not (only) its engine...
but you shouldn't have one without the other, else both are pointless!
They're called themes.
I wouldn't like KDE to look like XP's Luna, or MacOS's Aqua. It needs to at least be original in some way. And might I use this chance to be on-topic to say that I think it's childish how MS made a badly-done copy of the Aqua gui? You should check out XP's gui before they released Luna, and after. Completely different styling. It's not at all that surprising that Luna (just the name is a rip-off) showed up a bit after Aqua.
Besides, I don't even like Luna. I think it's ugly (it doesn't have sheens, which are a core element of the liquid effect).
But you *can* make KDE look like Luna or Aqua. Well, I don't know about Luna, but Aqua for sure, which is available in several incarnations on kde.themes.org. :)
... or even better than those slow pixmap-based renderings of Aqua at themes.org, go to mosfet.org and download his Liquid style engine :) Luna-style window decoration coupled with Aqua.
Michel
I always hated all available KDE styles and themes, but I immidiatly fall in love with Liquid. :)
It does not even compare to every other Aqua or Luna clone I've ever seen. It's so much better! It feels like a "real" and "native" style, not a clone or something.
And it's unbelievable fast.
Here is my desktop:
http://home.wtal.de/borgmann/konqueror.png
Note that the menu on the top is for some weird reason shown BEHIND the menu bar in this shot. Usually it's not so it looks better in reallife. ;)
Is Mosfet's Liquid Engine like a window manager? Is it like Window Maker (or Sawfish, etc), or a copy of KDE with a new look?
It's a style engine for KDE, Sarah. That means it changes the appearance of Qt and KDE apps for you - just like you can choose to have your KDE desktop look like Mac, Windows or Unix currently.
Basically it consists of:
1. a set of window decoration for KWin, the KDE window manager
2. a style engine to change the appearance of the widgets (buttons, scrollbar etc) of Qt/KDE apps
3. a colour scheme to switch the colours
Pretty amazing stuff! GNOME won't have easily-switchable colour schemes until GNOME 2 next year.
Regards,
Michel
You should try Mosfet's High Performance Liquid theme.
Yes, that's pretty damn cool (I use it currently), but I think he didn't speak about the style that is themable, but about fixed elements like the panel or the startmenu. Or even the login menu...
I would also suggest to work on the desktop/filemanager part.
Some ideas of Nautilus are pretty good. For example the transparent and colored select box when dragging the mouse while mousebutton is held. That's not just very nice to look at, but also easier to the eyes than a thin black line. :)
I also like how Nautilus renders Text below items. Very nice. KDE needs some improvement in this area.
Also missing is transparent moving od icons. I thought that was already implemente? I remember something like that, but can't find it in KDE 2.2. This does not just look nice, but it is VERY usefull to exactly see where you are placing your icon. :)
Something I do NOT like about the current KDE optic is, that it always and everywhere renders thin black lines! What's up with that? For example: I select an icon and click on the desktop to deselect it. Now their is a small black border around the icon... why? To show me that I clicked this last? It just looks ugly.
This also happens to buttons and many other widgets.
Please remove that! :) There is also a lot of weirdness when clicking and moving things. For example, when dragging an item, there are boxes drawn around the item and the text... why? It even lacks behind the actual rendering of the item... very ugly. :) Selected items do not look nice as well, that could be improved.
You see, there is a lot more about eyecandy than GUI-style and window decorations...
Some other ideas: When drawing the menu on top of the screen, can't you (optionally) place a shadow below it like Mac OS X?
Or even better, implement those shadows (optional) for every window and probably even icons?
That would just rock. I know that it would be quite a performance hit, but maybe this would force the lame XFree developers to come out with this alpha blending extension soon!
It would also be great to have real transparent windows (while moving or for backgrounds of some widgets), but I think that would be way to slow without native support by Xfree. :(
It would be great if someone could port Qt and KDE to DirectFB.
I know that people don't want to abandon Xfree, so it would be great if KDE would only depend on Qt, so it could run on every plattform that Qt supports and you could run this either on Xfree or on Linux framebuffer.
Qt/Embedded looks so great... why do our embedded devices have more eye candy than our desktop computers?? :) That's not fair.
XFree already has alpha, with the xrender extension. Or am I mistaken?
Has it? I don't think so.
AFAIK transparency tricks like the Liquid menus or the transparent windows while moving in Enlightenment still have to be done by copying the screen to a buffer and using this as the background. :(
That's why this Enlightenment windows always stop for a second before you can move them transparently. This sucks.
Alpha blending could be used for so many things...
X is not really the greatest thing for a desktop.
I would gladly switch to DirectFB for desktop rendering and user X only for 3D games anymore.
echo "exec quake3" > .xinitrc
startx
:)
Hmm, lack of one eye-candy oriented feature (that's already currently in devel) is hardly reason to switch entirely to FB. FB is good, but X has quite a bit going for it, like network windowing support, and acclerated 2d.
Not really. Xfree really doesn't have that much 3d support, nor hardware 2d. I know this is a complicated thing, you have to implement OpenGL or Mesa to even have and hardware acceleration in Xfree. Still, my video card, an S3 Savage4, that is has hardware accelerated 2d and 3d cannot do hardware acceleration because it is only implemented for 3dFX, Matrox, and NVidia chipsets. What about the rest of us? If I had full hardware accel. support for my board, X and KDE would no doubt run so much faster, but as I don't they are noticeably slower compared to win 98 with hardware accel. support from the manufacturer. Absolutely no 3d games for me until Mesa can fully support my card's chipset.
Accelerated 2D is MUCH better with DirectFB! They even have a DirectFB X-Server, which outperformces XFree in benchmarks. Couldn't try it yet.
XFree has more drivers and better 3D support. Drivers will come and 3D support is not important for the desktop (I could still launch XFree from within the DirectFB desktop for the game).
The network support is something, that many users don't really need. :)
It would be great, if KDE could just run on "Qt" (not Xlibs) and Qt would run natively on DirectFB, so you could choose your environment.
X is really not everybody's taste.
Or their could be something like a "layer" between Qt, the hardware/operating system and KDE, so you just had to port this layer (along Qt) to other plattforms if you want to run KDE on them.
KDE could become a kernel independent operating system, like Qube or Athene. :) That would really rock.
>KDE could become a kernel independent operating system, like Qube or Athene. :) That would really rock.
Eh, I dunno about that. There's a whole lot more code and work in between a DE and a full OS, and the KDE developers are working hard enough as it is. On the other hand, perhaps a Linux distro dedicated to nothing but KDE (and not a crappy commercial one either, but an open source distro) would be very cool.
>For example: I select an icon and click on the desktop to deselect it. Now their is a small black border around the icon... why? To show me that I clicked this last?
No, it's for people who like to use the keyboard. That line indicates where the current focus is so that you can move it around with the keyboard. Win2K has a very nice option that turns off these keyboard hints until you press an arrow key. Yet another option for KDE's overcrowded configuration panels.
>maybe this would force the lame XFree developers to come out with this alpha blending extension soon!
The render extension is already out. That's what gives us the wonderful anti-aliased text. Alpha-blending is already used in various places in KDE. I think with QT3 support for alpha-blending will become more universal, but I'm not sure.
>Qt/Embedded looks so great...
What you aren't seeing in the screenshots is the fact that QT/Embedded is not hardware accelerated, which makes it very slow. QT/Embedded was never meant to replace X for normal usage.
> No, it's for people who like to use the keyboard. That line indicates where the current focus is so that you can move it around with the keyboard. Win2K has a very nice option that turns off these keyboard hints until you press an arrow key. Yet another option for KDE's overcrowded configuration panels.
1) They should look nicer. :)
2) That's a nice idea. Why not just do it by default?
> The render extension is already out. That's what gives us the wonderful anti-aliased text. Alpha-blending is already used in various places in KDE. I think with QT3 support for alpha-blending will become more universal, but I'm not sure.
I know that it's used for Antia Aliasing, but I never saw it used for actual alpha blending of windows or widgets. I don't think this part is out yet.
If it is, why isn't is used? Maybe somebody know?
> What you aren't seeing in the screenshots is the fact that QT/Embedded is not hardware accelerated, which makes it very slow. QT/Embedded was never meant to replace X for normal usage.
Framebuffer IS hardware accelerated (look at DirectFB). And it's very fast.
Of course no 3D yet. :) But I don't need 3D on my desktop (yet). And it wouldn't be a problem to launch X to play Quake or so.
The framebuffer is *NOT* hardware accelerated. DirectFB is not the framebuffer. DirectFB is hardware accelerated. DirectFB is a layer on top of the framebuffer that provides an interface to hardware acceleration. DirectFB needs lots of drivers to catch up with XFree.
DirectFB does look like a cool project. Those screenshots are amazing! Especially this one:
http://directfb.org/news/count/videoshot.png
I dearly hope someone ports QT to DirectFB (which is not the same as QT/Embedded running on the framebuffer) so we can enjoy that DirectFB goodness. However, even if KDE was ported to DirectFB, it probably couldn't use any DirectFB specific features because DirectFB only works on Linux and KDE is cross-platform.
In regards to QT embedded, the graphical layers bypasses X and talks directly to the frame buffer (in the kernel), hence the reason the importance of frame buffers in the kernel, thus removing the need to have a top heavy X + QT etc etc.
I think kicker should use some xml skin system like noatun, sonique or winamp3.
This would simply rock! Imagine that you could choose a background for kicker (a png with any format) or even some images for the background, then each item on kicker could be a png in any format...
It's hard to explain it well.
Later I'll post some screenshots and some xml to show what I mean.
Ok, here's the idea:
http://www.protoman.f2s.com/pic01.png (144k, png)
Now let me explain how this theme would be build (I'll supose the background is only one image called blue.png) - this is only a idea, so I'll kick values for posx and posy (position x and position y) for the items. So here's the xml:
20112
kmenu.png
6296
24
and so goes on for dock, clock, other applets, etc.....
this can be more generic, as instead of a tag for each applet, a generic tag that receives a applet name.
Anyway, this is my idea, what do you think?
I think it is already possible. Kicker can have a backround image already. Kicker's buttons can have "backround tiles" that show up behind the icons. You can change Kicker's icons with an icon theme, and you can change the appearence of the applet handles, buttons, etc. with a regular theme. You wouldn't want to specify the positions of buttons and applets in the theme itself, that is for the user to decide. The only thing that is missing is the XML to tie it together. Currently KDE's themeing capabilities are somewhat widely distributed in different places. You're welcome to invent an XML theme parser for KDE, since no one else has shown a desire to do so (although unified theme support is an often-requested feature).
Yes, the only think that seems to be missing is enabling other formats of kicker other than a rectangle.
This could even be extended to it's applets. Imagine how cool a circle clock or elipsed buttons for open apps.
With this and hability to use kicker as any format, things should be very easy, but I really would like to extend it more to something like Object Desktop.
I like your ideas.
It would be really need to be able to skin kicker like say... k-jofol. :)
Someone could do a sience fiction kicker, etc...
Look at Athene (www.rocklyte.com) to know what I'm talking about (you can download and install it, it's pretty easy and a nice demo of a fully skinnable desktop! Very impressive).
Of course that's very hard to do, cause you have to provide places for applets, the menu entry's, etc. You can't hardcode them, cause the user could decide to load an unknown applet or something like that.
I don't expect this very soon, but would probably be a nice idea for KDE 4.0 ;)
Try kde.themes.org for themes and help with making your own. That's the great thing about Free software: If you don't like it, you can fix it! I eagerly await your beautiful new KDE skins!
I think a lot of users will be surprised reading that there is no plant to make a unique theme handler, merging things like window decoration / theme / style into one single menu point under kcontrol, and even more important, integrate a theme creator which enables the user to simply choose style / wallpaper / colours etc, save everything into 1 file, and upload it to the one-day-probably-working-and-updated-again-kde.themes.org.
I think its SO important. I would like to start to improve my C++ to build a theme creator. I think this is not very difficult. Only a wizard that asks you what color or pixmap do you want for the different widgets.
Yeah, we'd all appreciate your efforts!
I took again a look at the list of planned features and it makes me think that kde-developers are not really talking about all their plans. I guess we ll be surprised by the things that are upcoming and not mentioned in the list by our kde-wizard heroes.
Dont forget about improving your c++ abilities and write the theme-manager ;-)
I think its SO important. I would like to start to improve my C++ to build a theme creator. I think this is not very difficult. Only a wizard that asks you what color or pixmap do you want for the different widgets.
Right said. That merging would be _badly_ needed.