The KDE Project has just announced the release of KDE 3.0Alpha1,
the inaugural release of the
KDE 3 series. This release is targeted at developers, though experimental
users might want to check it out (be sure to read the
installing KDE 3 alongside your KDE 2 desktop). The principal changes from the
recently-released KDE 2.2.1 stem
from the switch to Qt 3. However, that switch does bring with it an impressive
array of feature enhancements, including new database classes, new data-aware
widgets, improved RAD development with a much-enhanced Qt Designer, a new
powerful regular expression class (with full Unicode support),
improved internationalization support (including the ability to mix different
character sets in the same text), bi-directional language support (for languages such as Arabic and Hebrew),
multi-monitor (Xinerama and multi-screen) support, better integration of pure
Qt applications into KDE, and hardware-accelerated alpha blending. With
the Qt port out of the way, the KDE developers can now focus on the
KDE improvements. Read the full announcement
here, or go straight to the
KDE 3.0Alpha1 Developer's Release Ships
The KDE Project has just announced the release of KDE 3.0Alpha1,
Does KDE3a1 also fix the clipboard problems, just by switching to QT3?
yes, clipboard!=selection, finally.
... but I *liked* the clipboard being the selection... what does QT 3 have to offer me?
You can still use your X middle-mouse-button text buffer thingy, but the real clipboard is now independent of it. So using Ctrl-C to copy uses a different clipboard than simply selecting with the mouse and hitting the middle mouse button. It's the best of both worlds!
Wow, we've been asking for this exact behaviour for so long, and finally, here it is!
This alone makes it worth the download ;) (for me, anyway)
And gnome has had it, as have other X apps :-)
This has always been the ICCCM (the X11 document describing the way apps should interact) stance on how the clipboard should work. Nice to see KDE getting it right at last, this should be popular with Windows converts and X11 die-hards alike :-)
: And gnome has had it, as have other X apps :-)
Yes, but I refuse to use Gnome because it's coded in perl... that's no way to write a GUI. It's just too slow. Plus, since Ximian owns the code, they can start charging for it anytime they want.
I would like to correct some errors of yours:
: Yes, but I refuse to use Gnome because it's coded in perl
Actually, it's written (mostly) in C.
:Ximian owns the code, they can start charging for it anytime they want
No, all the code is GPL/LGPL, so - even if the code were Ximian's property -this could not happen.
Having said that, I would like to add:
: I would like to correct some errors of yours:
Oh, hell... let the countertrolls do their work. I'm tired of the BS about C++ being unstable, and Gnome's use of GTK better because it runs on Windows (as if Qt didn't and as if either Gnome or KDE ran on Windows in anything more than proof of concept works). Logical arguements haven't worked, and the CounterTroll (and the other fauna due soon, the TrollKiller, the TrollSpotter, the Moderator, the GrammarNazi and others) is a sign that the ecology of this message board just went beyond normal users.
Take heart - at least it's a sign that KDE has a high enough visibility so that people who don't even use it (and indeed, don't care about it) can flourish in the nooks and crannys of its online userbase.
i think he was joking ..
Oh no, don't get me started on GNOME. I'll keep my mouth shut this time, only to avoid an "incident"
Well, to copy anything, you first must select it. Only thing is, now the middle-mouse-button selection buffer is seperate from the clipboard. Imagine this:
In KWord, you select and then cut the words "The quick brown fox"
Then, you just select and then delete "Jumped over the lazy dog"
Now, just Ctrl+V and MMB, and you get... well, you can figure it out :-)
Just think of the clipboard as a second selection buffer, that's slightly tougher to get stuff into.
I am happy and appreciate this feature. I was very annoyed with unexpected clipboard selection (both text and files). Thank god, KDE is somewhat more user friendly ;)
Well, now the only thing I can think of that would be nice in the clipboard is easily copying and pasting KParts between apps. I.e. it would be nice if you could copy a Kontour part from within KWord, and then paste it into a presentation within KPresenter. Is something like this already working at this point?
The only proble that I have with the current clipboard behavior is that if something is copied into the KDE (Klipper) clipboard if does not showup in the X-Clipboard.
You have to actually paste it into the X-Clipboard.
On the other hand, if something is copied into the X-Clipboard, it does showup in the KDE (Klipper) clipboard.
Is this problem being fixed?
Yes, I fixed this a few days ago.
I do hope that somewhere along the way that someone will fix the various minor bugs. I realize that this is not as much fun as coding for new features.
BUT, if KDE is going to become a comercial quality product, this must be done.
AND, yes, I am willing to submit bug reports on these and to provide the developer that is working on it more detailed information, to try patches, discuss things in detail, etc.
I am running the current CVS KDE_2_2_Branch. Except that kdebase seems to be broken and I had to download the 2.2.1 tarball.
: I do hope that somewhere along the way that someone will fix the various minor bugs.
3.0 is pretty much a port of the existing code to Qt 3.0. Along the way, a whole slew of new bugs will be picked up, so in a way, the only thing that 3.0 will be is bug fixes - pre-existing and new ones.
At the same time, there is a 2.2.2 branch that was announced that will just have some bug fixes in it, with no new features.
Here's your cake, and you can eat this cake over here, too.
Of course hackers are constantly also bug fixing (e.g. I did nothing else the last weeks since I didn't have time to do something else), but look at the huge list on bugs.kde.org, many bugs are not always reproducible, some bugs are more like feature requests, some bugs are known but nobody knows how to solve them, well, it's not that simple to fix them all ;-)
Is the new regular expression class designed to be compatible with the one in boost? (http://www.boost.org)? If not, why? These guys have spent a lot of energy getting the interface correct in order for a feature like this to become a standard in c++ sooner or later. But having multiple incompatible interfaces for the same thing (implementations don't matter) are really going to cause a lot of trouble later.
And if it was examined and found to "not meet your needs", was any attempt made to tell the boost developers what you needed?
I guess the main concern is Unicode support. Does the boost regex class support it? Another question I've always had is: does std::string support Unicode? A standard Unicode string interface is much more important than regex.
Oh well, the QString class is awesome.
Yes, std::string supports unicode. Actually std::string is just a typedef for
std::basic_string. You might replace that char with everything, even your own personal humpty-dumpty Char-object. Unicode is there. Brought to you by the power of c++-templates.
well, this would be a question best put to Qt developers, not KDE developers, since the class (QRegExp) is in Qt, not kdelibs. the version put in qt3 is perl-compatible, like boost's regexp class. however, I think that the trolltech developers didn't use boost's regexp class for a number of reasons:
1. qregexp uses QString. This is a fully unicode-compatible string class used everywhere in Qt (along with QCString). Boost's regexp class uses std::string. This is not used at all by Qt, afaik. Neither is much of the c++ system libraries or the stl. Qt provides adequate, if not better replacements for all of these. Why? Because Qt has existed long before these things were standardized among many implementations.
2. qregexp has existed for a long time, even before boost's regexp class. qregexp is used to many Qt/KDE apps already, so this new version is mostly a dropin replacement for the old qregexp (with a _LOT_ more functionality, of couse).
lol, we all knew along that jesus christ was a KDE developer. nowonder that KDE is so great ;-)
I wonder if he uses kde on jesux
AFAIK the new Qt regexp class is designed to be compatible as much as possible with Perl regexps.
Anyone care to post them?
There is not much new to see except a splash screen and an optional side image for K menu which both will be changed before KDE 3.
omg... Did they *really* have to copy that??
Now there's really no point in defending KDE when to comes to a 'KDE looks like Windows' flame. They have won without a battle.
and an __optional__ side image for K menu
It's optional in windows too...
OK, so then let's make it mandatory... ;)
I like the DOM tree viewer in konqueror: KDE3-konqueror-domtree.png
I have the DOM-tree viewer too, but I use KDE 2.2.1. I think it is included in kdeaddons.
What is the CVS tag for the alpha1 release?
There are some things that I'd really like to see in the next release of KDE. A few of them are eye-candy, but the rest I feel are truly needed. What do you think?
I've found this *very* neat screenshot of Gnome (rather nautilus) supporting SVG icons: http://jimmac.musichall.cz/screenshots/e-sync.jpeg.
These are really nice. Maybe it's the cartoony style of the icons, I don't know... but I really like them over the current KDE icons.
Also, I've heard that QT 3.0 will support xrender fully -- providing access to "true" transparency. What does this mean? Is it the kind of transparency provided by Mosfet's translucent menu style, or would it be true *true* transparency, where graphics /underneath/ the translucent area change, and you can see the change through the translucent area? I figure this full kind of transparency would be needed if KDE were to implement drop shadows for windows, menus and dialog boxes; if the windows under the drop -shadow change their views, then the kind of transparency we see in Mosfet's style engine would not update the drop-shadow... just a thought...
how long until KOffice shows real support for Hebrew? Abiword is making (admirable) steps to support it, but they are hampered until gtk 2.0 comes out (with bidi & aaliasing support).
Integrating CD mastering into Konqueror:
I wish to develop an ioslave or kpart implementing cd mastering and arrangement-making capabilities into Konqueror (as a kpart or ioslave). So far, whomever I find to help me drops out after a day. Anyone want to see this capability in the next release of KDE? contact me. This could be very powerful. Windows XP has this, albeit in a braindamaged way (you have to drag your files to a cd-burner 'trash-can' and hit 'burn'; my idea is more thought-out). Again, contact me for details ([email protected], IM: MnicHisteriaNARF )
I think it's really important, but not for fancy effects; transparency is the key to a full support of the PNG format. I would love a full alpha support of PNG images in Konqueror - that would make it an even better browser!
Roey says :
> There are some things that I'd really like to see in the next release of KDE. A few of them are eye-candy, but the rest I feel are truly needed. What do you think?
I think that eye-candy things are now uninteresting. It is not important for KDE to copy the MS Windows, Gnome or Mac look. KDE has its own look, I appreciate it, as many users, and the way is to continue, with some little improvements (example : coloured, perhaps animated, cursors)... There are so many things to do more useful that copying looks. But copying good functionnalities of others desktops is useful, of course. For instance, I recently discovered in KDE the ability to put in a window a menu of the K Menu (as in Gnome). Very good ! Thanks ! Also I now can use Kicker in a left vertical bar (without any damage). Very useful for the management of the space in a 19" screen !
Alas, all is not implemented in KDE 2.2.1, so I hope for KDE 3.... For example any program MUST memorize the location and status of the bars (I am tired of changing the properties of the Kate bar or the Quanta + bar...).
> I think that eye-candy things are now uninteresting.
I disagree. Some people choose other environments over KDE because of the look. That can be avoided only by offering as many alternative looks as possible. The G-team has guys like tigert and jimmac and that's the reason why some people choose it over KDE. Yes, KDE might offer better functionality, but that proves the importance of looks. It is NOT to be taken lightly.
> There are so many things to do more useful that copying looks.
I agree. Especially in the case of copying Windows. When I left Windows for Linux I wanted something drastically different. I had a hard time using KDE 1.1.2 because of that. It has gotten better over the years, but we can't stop evolving the KDE look.
So, people out there. If you're more of an artist than a coder, please serve the community by creating different kinds of themes and icons. Submit them to the kdeartwork module and who knows, one day a person might choose KDE over another DE because of that.
They SHOULD make their own style of icons, look at what they talk about in mailing lists
But they have a point, before you can have your own style you must copy the style of what you know works.
better to experiment later, first we need something to compete with windows.
Yes, all those above and a drop shadow on every window ala Mac OS X would be nice ;-).
What KDE 3 should look like ...
That's a REALLY beautiful mock-up!
If KDE had those dropshadows I think it would be easy to attract non-geeks!
Truly, truly beautiful. What a way to give differentiation of space. The only improvement I can think of adding is to brighten up the left and top of the window borders to differentiate two windows side by side where no drop shadow can determine depth.
That is really nice. It would be nice to have a plugin archetecture for WM effects. That way, it wouldn't have to be part of the theme, but you could add as many effects as you want. Pie in the sky, I know, but it's an idea. Stuff like window effects when minimized/maximized, effects when switching desktops, etc.
He yes ... we could have a "genie" effect like in Mac OS X !!
It's beautiful ... and i think visuel apparence of a wm is very important
> I've found this *very* neat screenshot of Gnome (rather nautilus) supporting
> SVG icons: http://jimmac.musichall.cz/screenshots/e-sync.jpeg.
> These are really nice. Maybe it's the cartoony style of the icons, I don't
> know... but I really like them over the current KDE icons.
The Gnome icons are indeed quite nice. Icons in KDE as nice as in Gnome would be a cool feature for KDE3. But I have no idea about creating icons, and I admire everybody who has. Someone out there should create some nice looking icons for KDE...
P.S. I have to revise this a bit: Some of the icons of kde are quite nifty. For instance the K of the KMenu and the icons of konsole and konqi.
But konqi's stop button isn't as nice...
I think whether the icons in Gnome are "nicer" than those in KDE or not depends a lot on your taste. When I last tried gnome, my reaction was, looking at the panel "Boy are these icons ugly compared to the KDE ones".