KDE 4.1 Alpha 1 Is Out
Wednesday, 30 April 2008 | Skuegler
The KDE Community is happy to announce the first preview for the upcoming KDE 4.1, due in late July. KDE 4.1 is based on Qt 4.4's goodness, bringing performance improvements, WebKit, widgets-on-canvas and other goodies. Also new is Dragon Player, a KDE 4 port of the codeine video player which is famous for its simplicity and ease of use. KDE 4.1 Alpha 1 ships with Akonadi, the new data storage framework for our beloved PIM applications. KDE-PIM will also see its first KDE 4 release with 4.1, but is not yet based on Akonadi. More planned and already implemented features can be found in the KDE 4.1 Feature Plan. The Plasma desktop shell has just undergone major surgery, so expect some additional breakage there.
Comments:
wow - ac - 2008-04-30
Just what we needed -- major surgery and additional breakage.
Re: wow - sebas - 2008-04-30
Yep, that was needed. We did the following two things: - Porting plasma to Qt 4.4 new widgets on canvas support. Previously, it was not possible to use Qt widgets in Plasmoids. Plasma in 4.0 needed its own layout system, and widgets. Now we can use all the gorgeous Qt and KDE widgets. Better integration, much faster development, smaller codebase, and instantly lots of new features. - API review. This is more a mid-term thing. For the 4.2 timeframe, we would like to merge parts of Plasma into kdelibs. Also, before a wider adoption of the Plasma libs, we wanted to make sure that the API is intuitive to use and well designed. The changes necessary to make it a nice, consistent and easy to understand interface will definitely pay off long term. Aaron Seigo has just written an interesing blog about that btw. All that nearly in time for an "Alpha1". In fact, both, the WoC porting and the API changes are in by now. That's where we can get back to stabilising. Not a surprising strategy WRT to release plans. That said, the current state of things feels very good, at least on my box, and starting in May there are a solid two months to stabilise everything even further.
Re: wow - Alex - 2008-04-30
> Yep, that was needed. We did the following two things: Yes, sure. But from my POV, plasma has been the component which receives most criticism in KDE 4.0.x. So finishing the announcement for the first 4.1 alpha with "expect more breakage in plasma" is IMO "suboptimal". Alex
Re: wow - DR - 2008-04-30
Thats what KDE 3.5.9 is for. KDE 4.0.3 is usable(have been using it as my only desktop for over a month now, and have not had any serious issues with it.) Anyway, I downloaded the Suse 4.1 live cd. It had a lot of problems with plasmoids(none of them worked) but the basic desktop worked perfectly. It also looks amazing.
Re: wow - Jonathan Thomas - 2008-04-30
If people using an alpha get mad because Plasma is somewhat broken, then its their own fault. Breakage while implementing new features are what alphas are all about in the software world. (Though in the past we've been spoiled by high-stability KDE pre-releases.)
Re: wow - Emil Sedgh - 2008-04-30
People using alpha getting mad? KDE 4.1 Alpha1 is released just to be a preview for 4.1 it 'is' alpha.this is 100% usual that an Alpha software includes broken stuff.this is why its called 'Alpha'.
Re: wow - bsander - 2008-04-30
In case you haven't noticed, you guys agree.
Re: wow - Jim - 2008-04-30
> If people using an alpha get mad because Plasma is somewhat broken, then its their own fault. I think the point being made is that Plasma was considered by many to be unfinished by KDE 4.0's release and responsible for a lot of its problems. Everybody unhappy with KDE 4.0 was told that KDE 4.1 was the "real" release, and that KDE 4.0 was just a preview. So to find out that Plasma is undergoing yet more big changes rather than stabilising just makes a mockery of everybody who was fed the excuses about 4.0 and the promises for 4.1. > Breakage while implementing new features are what alphas are all about in the software world. Oh, I was saying that for 4.0. I was told I didn't understand open source and that betas and release candidates are appropriate for breakage while implementing new features too.
Re: wow - Janne - 2008-04-30
"So to find out that Plasma is undergoing yet more big changes rather than stabilising just makes a mockery of everybody who was fed the excuses about 4.0 and the promises for 4.1." Dude, why don't you just wait until 4.1 is released? Basing your critique on Alpha-software is disingenuous at best. "Oh, I was saying that for 4.0. I was told I didn't understand open source and that betas and release candidates are appropriate for breakage while implementing new features too." 4.0 was and is a major undertaking of moving the project to a whole new foundation. And 4.0 achieved that. Is it functionally equivalent to 3.x? No. But 4.1 should take big steps in turning KDE4 in to a robust everyday desktop. And to respond to your whining... Again: Wait until 4.1 is released, before you start whining how Plasma is "broken", OK? Because as things are right now, you have exactly zero idea that is it breoken or not. And before you say something like "Well, the announcement of 4.1 Alpha says that it's broken!"... Yes, it might be somewhat broken in 4.1 Alpha. But Alpha is not the final release. Hell, we might get second Alpha, followed by few betas, followed by one or more release candidates. In short: Wait until the software is actually released, before whining about that software, OK?
Re: wow - Jim - 2008-04-30
You seem to be more eager to parrot the party line than to read the comment you are replying to. > Dude, why don't you just wait until 4.1 is released? Because the point is not that Plasma is currently unstable, the point is that after telling everybody that 4.0 was the broken release and 4.1 was for stabilisation, they did the exact opposite and went ahead with more major changes to Plasma. Whether they pull it together and fix things before 4.1 is released is beside the point. Porting to new APIs while adding features does not increase stability, it does the opposite. The fact that they are willing to do that shows that the claims that 4.1 was the stabilisation release was just an excuse. The truth is that 4.0 was simply unfinished and moving to 4.1 is a case of completing all the development they wished they had done for 4.0. If the development process continues at this rate, people will be complaining that 4.1 is unstable and they'll get told that 4.2 will stabilise things. > 4.0 was and is a major undertaking of moving the project to a whole new foundation. And 4.0 achieved that. Is it functionally equivalent to 3.x? No. But 4.1 should take big steps in turning KDE4 in to a robust everyday desktop. Jonathan pointed out that alphas are for risky development, and I pointed out that means little because betas and release candidates are also for risky development as far as KDE is concerned. Your soundbite about KDE 4.0 being a major undertaking really has no relevance to that point, it's like a generic press blurb you copy & pasted. > In short: Wait until the software is actually released, before whining about that software, OK? I'm complaining about the development process, not the software.
Re: wow - Antonio - 2008-04-30
> I'm complaining about the development process, not the software. Your complaint about the development process, while perhaps both entertaining for some and frustrating for others, is based on a terrible misreading of what has been said. > Because the point is not that Plasma is currently unstable, the point is that > after telling everybody that 4.0 was the broken release and 4.1 was for > stabilisation, they did the exact opposite and went ahead with more major > changes to Plasma. Nobody said 4.1 was a `stabilization release'. They said Plasma would become what it was meant to be much more so in 4.1 than it had time to in 4.0. They also said that, since there will have been more testing, more bugs will have been found and fixed. > If the development process continues at this rate, people will be complaining > that 4.1 is unstable and they'll get told that 4.2 will stabilise things. If the process continues at this rate, we'll be light-years ahead of the competition in just a few releases. The rate at which Plasma has been developed from nothing to a working, if not-as-featureful, replacement for KDesktop to what it is now is absolutely ridiculously awesome, for any company or community. Software is continual stabilization. 3.5.9 is as stable as it is because it has had *6 years* of development on it at this point, 3 between 3.0 and 3.5. And that *wasn't* as major a re-architecting (the previous one having been KDE 2). > Jonathan pointed out that alphas are for risky development, and I pointed out > that means little because betas and release candidates are also for risky > development as far as KDE is concerned. > > Your soundbite about KDE 4.0 being a major undertaking really has no > relevance to that point, it's like a generic press blurb you copy & pasted. It is a fact that a major re-architecting will introduce bugs. Amusingly, you make that same point earlier on. But now you say it is irrelevant to the fact that 4.0 was buggier than 3.5.9 that KDE 4 is a major re-architecting? Hopefully the paralleling there makes you see how silly that sounds. New platform releases are not for `risky' development, they are for total restructuring, which will, yes, introduce new bugs. Finally, I've been using KDE4 on laptop and desktop for a few months (latter) and a few weeks (former), and while Plasma started out a little buggy, it's been doing fine for me recently. And yeah, it looks gorgeous. To the point where a Mac fanboy walked past the other day and went `wow, Linux is looking really good...'
Re: wow - Jim - 2008-04-30
> Nobody said 4.1 was a `stabilization release'. Wow, are you kidding? I heard it practically daily in the run-up to KDE 4.0 when everybody was complaining about it being unstable. It was the standard excuse for why 4.0 was so buggy. > If the process continues at this rate, we'll be light-years ahead of the competition in just a few releases. I had that opinion during KDE 3. When I saw the state of KDE 4 and the change in attitude that caused it, I changed my mind. I'm now using GNOME, and I have to say, KDE isn't the racehorse it used to be. I have to keep hold of KDE for work purposes, but I'm not using it on a daily basis any more. > Software is continual stabilization. 3.5.9 is as stable as it is because it has had *6 years* of development on it at this point Correction: 3.5.9 is as stable as it is because it has had 6 years of development *that wasn't focused on major re-architecting*. Just the mere act of development doesn't make software more stable. It depends what *kind* of development it is. Some can make it more stable. Some can make it less so. The post-4.0.x work that has gone into Plasma so far is the latter. > But now you say it is irrelevant to the fact that 4.0 was buggier than 3.5.9 that KDE 4 is a major re-architecting? No, I'm saying that what he said isn't a response to what I said. He's just trying to talk over me with pro-KDE talking points without listening to what I'm saying.
Re: wow - JRT - 2008-04-30
It will come as a surprise to nobody that I basically agree with you. The Plasma project could be used as a case study of why hacking is not a valid software development method. I have to disagree slightly about 3.5.9. It isn't really that stable and has serious regressions in the desktop which were not fixed because the developer was moving to Plasma. The reason that 3.5.9 is somewhat unstable is that changes were made faster than bugs were fixed and the result is instability. Konqueror 3.5.9 crashes several times a day. Fortunately, this is Linux and it crashes cleanly and doesn't usually bring anything else down with it. KDE almost never crashes. Sometimes Konqueror crashes Kicker (which restarts). But stability is lacking in 3.5.9. I don't know the reason, and it would be hard to debug since the crash handler often reports that a trace is not available because the stack was corrupted. IAC, what the development process needs is some design work -- avoid unpremeditated code!! Yes, I have an example: Bug 159492. Don't want to say anything to insult the person that wrote that piece of code, but I have to say that if a lot of the code needs that much work, we are in real trouble. My advice as a former volunteer TA is to decide exactly what you want your code to do *before* you start writing it. Trying stuff to see if it works is not a valid software engineering method -- although you should test your changes before you commit them. To do it this way and still collaborate, is going to require changes in our development methodology as others have already suggested.
Re: wow - Richard Dale - 2008-04-30
"Plasma project could be used as a case study of why hacking is not a valid software development method." You remind me of Mr Magoo..
Re: wow - Ummm - 2008-04-30
Umm... seems your KDE is b0rked? Or is it your distro's fault? My konqueror crashes as often as Firefox crashes / locks up (I use konqueror for 90% of my browsing). And in one Konqueror window I can open more than 20 tabs, so far no crash for few days.
Re: wow - Kit - 2008-04-30
>Konqueror 3.5.9 crashes several times a day. By any chance do you have Adobe Flash (and possibly the other versions of flash as well) installed and enabled by default? I've found that to be the cause of pretty much ALL Konqueror crashes/freezes (in the case of a freeze, you can often kill nspluginviewer, I believe was the name, and Konqueror will become responsive again). I disabled plugins globally in Konqueror after Adobe broke Flash in all non-gecko browsers on Linux and have had about *one* crash since then (Facebook's massive amount of js really slows down Konqi). KDE 3.5.9 is EXTREMELY stable for me. I haven't had kicker or anything else crash (that I can remember). I've had this session running for 7 days and 9 hours so far (suspending to ram at night, so maybe half that time doesn't count, give or take some hours) with 2-3 instances of Konqueror running without any crashes (I have 4 running atm, but this instance I just opened and will probably close after I finish reading the Dot and the blogs). If you're having lots of crashes it could be your configuration (if the files in ~/.kde have been carried through LOTS of upgrades it's possible for things to just get brittle), how your distro compiles/installs KDE (ridiculous compiler flags, patches, things just installed oddly, etc), hardware failure (bad ram can lead to very hard to diagnose crashes... I've had ram that caused the system to crash when doing certain things making me think it was a bug in the software), or just really bad luck even.
Flash - T. J. Brumfield - 2008-05-01
Yet Flash is a feature most will come to expect as part of the standard browsing experience. Flash doesn't crash IE, Safari, or Firefox. If Flash is causing crashes on Konqui, and Konqui alone, then perhaps that needs to be looked into.
Re: Flash - Kevin Krammer - 2008-05-01
The Konqueror devs are trying to find ways to work around the respective bugs in the Flash plugin, though optimially Adobe would actually care about releasing a fixed version.
Re: Flash - T. J. Brumfield - 2008-05-01
What percentage of the browser market does Konqueror have? If it only crashes in that one browser, then I wouldn't say it is Adobe's problem to fix. How is it that other browsers can load the plugin with no problems?
Re: Flash - Kevin Krammer - 2008-05-01
> If it only crashes in that one browser, then I wouldn't say it is Adobe's problem to fix. As long as the problem is in the Flash plugin code, which only Adobe has access to, it is Adobe's problem to fix. When possible developers working on nspluginviewer obviously try to use workarounds to improve the situation until Adobe has fixed the cause of a problem, but of course the possibilty of such workarounds depends on the nature of the problem.
Re: Flash - T. J. Brumfield - 2008-05-01
> As long as the problem is in the Flash plugin code, which only Adobe has access to, it is Adobe's problem to fix. Except the problem likely isn't in their code. They released the plugin to operate using Netscape plugins. Other browsers who follow that standard, implement the plugin just fine. If Adobe had a problem with Flash, it would be noticed by the countless users who use it every single day. Clearly the nature of the problem is how Konqueror implements plugins. This is one of the many reasons I will never uses Konqueror as web browser.
Re: Flash - Kevin Krammer - 2008-05-01
> Except the problem likely isn't in their code judging by the issues that have already been fixed in the plugin, it is quite likely that most remaining issues are bugs in the plugin as well. > If Adobe had a problem with Flash, it would be noticed by the countless users who use it every single day. As we know it is noticed by countless uses who happen to not use Gecko. E.g. one bug was that the plugin accessed GTK functions without calling gtk_init(), which only works if something else has already called that function. Even a non GTK based Gecko engine would have failed that. The fix was to properly call the init function, as documented in the GTK API docs. A recent discovery is that the plugin calls a plugin host function and cannot handle user agent strings which include "like Gecko" but requires to have just "Gecko". However, any later call of that function can return the correct user agent, cleary indicating that there is a bug in the plugin code responsible for the first call. > Clearly the nature of the problem is how Konqueror implements plugins. Clearly the nature of the problem is how Adobe's Flasg plugin developers assume things outside the definition of the plugin API instead of properly using it an other APIs (see GTK misuse above) > This is one of the many reasons I will never uses Konqueror as web browser. I use Konqueror as my main web browser every single day, even with Adobe's Flash despite Adobe's best efforts to make this impossible. It is awesome how Konqueror/KHTML/nspluginviewer developers manage to find workrounds and outside fixes for problems Adobe seems to be uncapable of fixing where they originate.
Re: Flash - Sebastian Sauer - 2008-05-02
> Adobe seems to be uncapable of fixing where they originate. To be fair it was Macromedia who wrote it in the first place and someone just needs to work a bit with there other products (Director does provide there a fantastic impression how software should _not_ be) to see that it was there philosophy to deliver such kind of software ;)
Re: Flash - Anon - 2008-05-02
Actually plenty of the mess in Flash nowadays was introduced after Adobe taking over Macromedia. It is the versions since then (7) which turned Flash into an apparently unmanageable kitchen sink of browser plugin meets media player meets multimedia toolkit framework. To make matters worse (likely related to the worsening of the code base) Adobe doesn't even bother to offer code of Flash version after 7 for commercial licensees anymore resulting in unsupported platforms being stuck with a more and more unsupported version 7 (a mainstream example is Flash in Opera for Nintendo Wii). That and Flash being used for the majority of ads makes me wish it'd rather die today than tomorrow.
Re: Flash - Sebastian Sauer - 2008-05-03
Thanks for the details which I wasn't aware of. Somewhat frustrating for those who depend on it and a good example why closed / non-free software does provide more problems then to solve any :-/
Re: Flash - fred - 2008-05-02
If you want to see how many hacks needed to make nspluginviewer works in Konqueror, you can refer to Lubos Lunak's blog. http://www.kdedevelopers.org/node/3162 (Guess what? Opera is also not supported) When something is badly engineered and closed source, you can only a hack to make it works. And this is the fault of those who implement the plugin. Do you know that people with non-32 bit machine (e.g. AMD64) also got headache to enable flash in Firefox? (no 64-bit flash plugin so far) And they curse Adobe even more than us Konqueror users because of that. I heard Adobe has released their swf spec, hopefully it will make Gnash/swfdec better and other browsers can utilize this to provide better flash.
Re: Flash - Velvet Elvis - 2008-05-02
It doesn't work in Opera either
Re: wow - Sebastian Sauer - 2008-05-01
> Konqueror 3.5.9 crashes several times a day doesn't seem here with my 3.5.9 setup but that for sure doesn't mean, that they are not there. > hard to debug since the crash handler often reports that a trace is not available often is not always what are imho good news cause we would only need a valid backtrace one time :) > serious regressions in the desktop in Konqueror or in the desktop+kicker? Please don't understand that wrong (I just try to find the reason for that), but may it be the case, that your distributor did there something by there own? I ask cause according to the 3.5.8=>3.5.9 changelog ( http://www.kde.org/announcements/changelogs/changelog3_5_8to3_5_9.php ) there was no work done on desktop+kicker and therefore I doubt that there are NEW regressions (or better ask myself how there could be any).
Re: wow - Moische - 2008-05-01
in case of interest, that site leads to reproducible crashes of Konqui 3.5.9 here: http://www.debianhelp.org/node/12647 but i'm feeling forced to state, that kde 3.5.9 including konqui runs pretty fine and stable here - not to compare with that infantile plasma-thing called kde4 sorry, of course there are a lot of users with the urgent need for continuously having a weather-forcast while working at their computers. Maybe only Meteorologists like me are not able to understand that ;-)
Re: wow - Morty - 2008-05-02
That link work without problem for me, which leads to two possibilities. Either the problem has been fixed post 3.5.9, and require a distribution which backport such fixes or you have to wait for a possible 3.5.10 release. The second possibility are that your distribution simply are broken.
Re: wow - hmmm - 2008-04-30
You are an annoying person who is not only looking at a gift horse's mouth, but downright insulting the donor! You are also an ignorant person who thinks re-architecturing and cleaning up the code should never be done. You believe incremental updates lead anywhere in terms of features irrespective of the starting codebase. They don't, the limit was 3.5.9, which is brilliant and extremely stable, except where the architecture found its limits -- PIM, the desktop/panel. The goal is to have plasma _in kdelibs_ which means binary compatible, which means that the API must be _right_, because there won't be changes in the next five or so years. This is the _correct_ way of doing it. And for such a thing as the widgets, which must cater to morons also (sorry, Aaron had some social-network-name for them) this is _hard_. And this is what will make all the alternatives irrelevant in the medium term. So if they want rearchitecturing, let them. Be happy that they do, and that they don't listen to the uninformed opinion of armchair commentators such as you. I am using the svn snapshot, and although plasma is pretty broken just right now, by the next snapshot it will be fixed. And going back to KDE3 is painful: KDE4 apps are, by now, downright better. I will however grant one thing, much trolling came from the way the 4.0 release was handled. From a developmental point of view, the KDE team did the right thing, from a please-the-trolls point of view, no so much. I suppose if you care about what you do, sometimes, you need to do the right thing anyway...
Re: wow - Jim - 2008-05-01
> You are also an ignorant person who thinks re-architecturing and cleaning up the code should never be done. Please don't make stuff up. I don't think this at all and there's nothing in my comment to suggest it. > The goal is to have plasma _in kdelibs_ which means binary compatible, which means that the API must be _right_ I thought the party line was that KDE 4.0 was for application developers to port to KDE 4 rather than end-users? More incompatible changes in the API? Will KDE 4.1 be for application developers to port rather than end-users as well? Don't you understand that fixing the API at this point only strengthens my claim that KDE 4.1 was just an excuse for KDE 4.0 developers to finish their work? > And for such a thing as the widgets, which must cater to morons also (sorry, Aaron had some social-network-name for them) this is _hard_. Which is why hacking on widget code shouldn't happen in the main branch, on the code responsible for vital UI features like the taskbar, when you are supposed to be stabilising things! > And this is what will make all the alternatives irrelevant in the medium term. I'm sorry but there are a *lot* of widget systems about, Plasma really isn't that compelling, and unlike KDE, the alternatives don't let work on the widget systems drag them down. The core idea of Plamsa is fine, I have no complaint there. But the way development has occurred, and the way KDE has relied upon it prematurely, has turned it into a complete albatross around KDE's neck. > although plasma is pretty broken just right now, by the next snapshot it will be fixed. People have been saying this ever since the first alphas of KDE 4.0. "Don't worry, the beta will be stable". "Don't worry, the next beta will be stable". "Don't worry, the release candidate will be stable". "Oh shit, we're not going to get this done for 4.0... I mean, KDE 4.0 isn't for end-users, dummy, you should wait for KDE 4.1". > I will however grant one thing, much trolling came from the way the 4.0 release was handled. A troll is somebody who posts insincerely in order to annoy people. Very little trolling came from the KDE 4.0 release handling, although false accusations were abundant. Why can't you understand that people have legitimate complaints about this?
Re: wow - Paul Eggleton - 2008-05-01
> Why can't you understand that people have legitimate complaints about this? Legitimate based upon what? What do you believe gives you the right to continually complain on this site about the way KDE is developed? Furthermore, what do you hope to achieve by making complaints here?
Re: wow - hmmm - 2008-05-02
See, I understand that it might disturb you as a concept, but ignorance is not a point of view. - The rewrite of plasma was planned from the start to happen upon the release of Qt 4.4. - Aaron, being the maintainer of kicker and co. said it was a nightmare. And he is a pretty smart guy. If he says: "this must be replaced by something new and sensible", odds are, he is right. Also, there are _now_ way more devs on plasma than there ever were on the old shell. Can you guess why? Oh, no, you can't because in your vision of the "right" universe, we would have no more devs and a half-working shell and a depressed and frustrated Aaron. IRL, you are a PHB, right? - It is not about having a widget system, it is about having a general, all-encompassing widget system which builds upon all the other widget systems. And the design of which also allows, as a side effect, the rebuilding of a desktop shell. And you know what, they are pretty much there. - No complaints are legitimate here, none, never. Unless you are a dev. You might state that you are unhappy, you might voice opinion, but to complain, you have no rights. - This is free software, this is not Apple inc. where all the mishaps and difficulties of development are hidden from the customer's view, you get to see them, people debate in the open about problems and difficulties. This is how you get better software in the end. Thinking of free software as a product gives you wrong ideas. It has no products, just projects that at some points become better than products.
Re: wow - Janne - 2008-04-30
"Wow, are you kidding? I heard it practically daily in the run-up to KDE 4.0 when everybody was complaining about it being unstable. It was the standard excuse for why 4.0 was so buggy." The thing I have heard is that 4.1 is the version that should match 3.x in terms of feature-set. And now that they add new features, you whine? And if they didn't add new functionality, you would whine that "we were promised that 4.1 will have all these new bells and whistles!". And like I said: are there any indications that 4.1 will be buggy? Yes, 4.1 alpha has some issues. That's why it's an alpha-release, and not the final gold master. What you are doing is complaining because the next major version of KDE has new code and functionality, and some bugs in the alpha-release. YOu somehow extrapolate from the alpha-release that "4.1 will be buggy!", even though several people have said that Plasma in SVN-snapshots is coming along nicely. And what is this about the developement-process? Are you somehow shocked that there's major rewrites and like between major releases?
Re: wow - Jim - 2008-05-01
> YOu somehow extrapolate from the alpha-release that "4.1 will be buggy!" I repeat myself: > the point is not that Plasma is currently unstable, the point is that after telling everybody that 4.0 was the broken release and 4.1 was for stabilisation, they did the exact opposite and went ahead with more major changes to Plasma. > Whether they pull it together and fix things before 4.1 is released is beside the point. Porting to new APIs while adding features does not increase stability, it does the opposite. The fact that they are willing to do that shows that the claims that 4.1 was the stabilisation release was just an excuse. The truth is that 4.0 was simply unfinished and moving to 4.1 is a case of completing all the development they wished they had done for 4.0. > Are you somehow shocked that there's major rewrites and like between major releases? I'm shocked that some people are saying that they are stabilising Plasma while simultaneously making major changes to it.
Re: wow - Janne - 2008-05-02
"I'm shocked that some people are saying that they are stabilising Plasma while simultaneously making major changes to it." So, do you believe that the plasma (or Kwin, or any other part of KDE) that we had in 4.0 will be the version we will have for all eternity? Like I said, major version-number (like 4.1 is) are there for major new features and functionality. And I bet that Plasma in 4.1 will be more stable and functional than Plasma in 4.0 was. They can do both: make big changes and make it stable. Like I said before: instead of whining about Plasma, how about waiting until 4.1 is released before passing judgment on it?
Re: wow - hmmm - 2008-05-02
Even though reality seems to have no impact on your opinions, try to spin that: This rewrite was planned from the start to happen upon the release of Qt 4.4. The "breakage" was fixed within a week of the rewrite. The rewrite was mandated, obvious, necessary because of WoC, and the fact that much of the logic originally in plasma is now found in Qt. The fact that this results in significantly simpler plasma code does not affect your opinion that obviously it _must_ introduce new bugs and hinder stability.
Re: wow - yman - 2008-04-30
I can't help but get the impression that once a piece of software reaches the point where you can get work done reliably and securely, you wish it to freeze in place and undertake no more improvements what-so-ever. Is this correct? As to your complaints about false promises, I remember much whining about missing features and Kickoff being the default menu, but nothing about stability. The promises made in response were that 4.1 will reach feature parity with 3.5, and perhaps even surpass it in some areas. It seems to me this may be bothering you, since if Plasma does surpass KDesktop and suffers no major stability issues as consequence, you will no longer be able to make complaints that will not be regarded as issues of personal taste.
Re: wow - Jim - 2008-05-01
> I can't help but get the impression that once a piece of software reaches the point where you can get work done reliably and securely, you wish it to freeze in place and undertake no more improvements what-so-ever. Is this correct? No. > As to your complaints about false promises, I remember much whining about missing features and Kickoff being the default menu, but nothing about stability. In that case, by all means browse each and every release notice that appeared here on the dot, on Reddit, on Digg, on Slashdot... there were a hell of a lot of complaints, you'd have to be blind to miss them.
Re: wow - Leo S - 2008-04-30
>> I heard it practically daily in the run-up to KDE 4.0 when everybody was complaining about it being unstable. It was the standard excuse for why 4.0 was so buggy. Without a source your statements are useless. Also, if 4.1 is more stable than 4.0, then saying that 4.1 will be a stabilizing release is accurate. Without a change in Plasma API, perhaps it could have been more stable. But if we were after ultimate stability, KDE 4 would never have been started, so this argument is stupid. >> I'm now using GNOME And yet you still feel the need to troll the KDE boards. Apparently you aren't happy with Gnome either, otherwise you wouldn't ever look back. >> I have to keep hold of KDE for work purposes, but I'm not using it on a daily basis any more. The fact that you apparently need KDE for work is telling. >> Correction: 3.5.9 is as stable as it is because it has had 6 years of development *that wasn't focused on major re-architecting*. No shit. That's the point. >> The post-4.0.x work that has gone into Plasma so far is the latter. If you're not involved, you can't possibly know that. I'm using a snapshot of 4.1 right now that is much more stable than 4.0.x ever was.
Re: wow - Jim - 2008-05-01
> > I'm now using GNOME > And yet you still feel the need to troll the KDE boards. Apparently you aren't happy with Gnome either, otherwise you wouldn't ever look back. Sorry, you're the one using the classic trolling tactic of only partially quoting the other person. The quote in full: > I'm now using GNOME, and I have to say, KDE isn't the racehorse it used to be. I have to keep hold of KDE for work purposes, but I'm not using it on a daily basis any more. It's quite obvious that using KDE is a necessity to me regardless of what I think of it or GNOME. If you cannot debate sincerely, please just be quiet.
Re: wow - Leo S - 2008-05-02
>> Sorry, you're the one using the classic trolling tactic of only partially quoting the other person. The quote in full: The funny thing is I included the rest of your quote 2 lines down from that line.. But I guess you didn't read the rest of my post...
Re: wow - blah - 2008-05-01
>> Nobody said 4.1 was a `stabilization release'. > > Wow, are you kidding? I heard it practically > daily in the run-up to KDE 4.0 when > everybody was complaining about it being > unstable. It was the standard excuse for > why 4.0 was so buggy. I'm with Jim here... You guys can deny it all you want, but this was the impression regular users where given. ("Yeah, KDE4.0 wasn't so good, but you just wait for KDE 4.1, man! I'll be great!") KDE4 is shaping up to be a huge disappointment, and somewhat of a disaster. Oxygen looked good in theory, but the implementation is really bad with buttons and icons all over the place, the active window-problem, and different styles everywhere -- and plasma is still unstable. Then you go and introduce a new API? WTF?! Is there *ever* a time to polish the way KDE4 look? Honestly, KDE4 looks like shit now. The GNOME-folks OTOH have done a great job polishing their DE, making it look really attractive and coherent (albeit somewhat of a throwback to Win2K looks-wise). It's time for me to upgrade, and as bad as KDE4 is looking now, I'm moving to GNOME...
Re: wow - Jonathan Thomas - 2008-05-01
Just stop with the FUD. Before the API refactoring, Plasma was quite stable. And now, just slightly a week after said API refactoring, Plasma is stable once again. The API changes were necessary, and once all the obvious bugs that were introduced in the applets due to the API change are fixed, the base is only much more stable because it is now relying more on Qt4 code and less on custom Plasma code built to duplicate Qt4 features. Read this for more, and keep in mind that what you are throwing a shit fit about is alpha software: http://aseigo.blogspot.com/2008/04/on-recent-libplasma-changes.html "Disaster"? Hardly. Currently alpha-staged software? Yes. There is no doubt in my mind that KDE 4.1 will be awesome. P.S. The default Plasma theme will go under the polishing board, and Oxygen issues such as the inactive window "problem" are being addressed.
Re: wow - fred - 2008-05-01
WTF? Major complaint about KDE 4.0 is because it needs more features once we had in KDE 3.5.9, especially desktop and kicker. And now they want to make the desktop better and you still complaining? And about KDE4 looks like shit, did you live under the rock when GNOME released their 2.0, or were you with your proprietary system? GNOME 2.0 looked like the worst single GUI on earth, and yes, they didn't have clearlooks or ubuntu-human that make GNOME looks so beautiful nowadays. Give them a time dude! I guess you even never tried KDE 4.0 or KDE 4.1 alpha. My last advice: go troll somewhere else!!! Sometimes we just hate idiot users who can only complain and whine. And also, who the heck cares if you're moving to XYZ Desktop Environment?
Re: wow - Stefan Majewsky - 2008-05-03
> KDE4 is shaping up to be a huge disappointment, and somewhat of a disaster. Oxygen looked good in theory, but the implementation is really bad with buttons and icons all over the place, the active window-problem, and different styles everywhere The "active window" problem is being worked on. Also, the appearance of Oxygen (as with any other style) is very subjective. If you do not like it, change the style. > and plasma is still unstable. Then you go and introduce a new API? WTF?! The last time Plasma crashed for me was during the KDE 4.0 beta phase. If you have crashes which are not caused by own incompetence (i.e. which are reproducible what I assume) report them.
Re: wow - Antonio - 2008-05-01
> Wow, are you kidding? I heard it practically daily in the run-up to KDE 4.0 > when everybody was complaining about it being unstable. It was the standard > excuse for why 4.0 was so buggy. As others have pointed out, I would appreciate your telling me where you saw that. People were promising that 4.1 would be _better_, yes. People were saying it would have fewer bugs, because it would have been more tested, as I pointed out in my own post, something which you utterly disregarded. There is a massive difference between `yes, there will be fewer bugs' and `our focus will be stabilization rather than new features'. The former is normal for major releases, the latter is not. Stabilization is for bug-fix releases. The 4.0.3s of the world, which have shone in that regard. > Correction: 3.5.9 is as stable as it is because it has had 6 years of > development *that wasn't focused on major re-architecting*. And it had the luxury of not focusing on major re-architecting because it built on the major re-architecting in KDE 2, which introduced features (KParts and KIO, for example) that other environments (Windows and such included) *still* don't have. > Just the mere act of development doesn't make software more stable. It > depends what *kind* of development it is. Some can make it more stable. Some > can make it less so. Which... Was exactly what I said. Thank you for reiterating. > The post-4.0.x work that has gone into Plasma so far is the latter. Well, for one thing it wasn't post-4.0.x, it was parallel-to-4.0.x. Which is important because bug fixes were made along the way. Yes, this new API has obviously re-broken some things, but the point, as, again, has been pointed out elsewhere, is that the API is hopefully going to go into long-term maintenance mode, and, by affiliation, the underlying stuff will not be *able* to be revised for five years or so.
Re: wow - Stefan Majewsky - 2008-05-03
> it [KDE 3.5.9] had the luxury of not focusing on major re-architecting because it built on the major re-architecting in KDE 2, which introduced features (KParts and KIO, for example) that other environments (Windows and such included) *still* don't have. Perhaps the point is that we do not have many developers (esp. when compared to M$ and Apple) and thus have to implement things in a very effective way. Many key components of KDE (such as the mentioned KParts and KIO libs) and the underlying Qt libraries allow applications to implement features with less code (and therefore less possible error causes). Some examples from my personal impressions: To open a website in the user's favorite browser, the code is one line (KRun::runUrl()). Downloading a file from an arbitrary location (from local files to web services to SSH resources) costs three lines of code (KIO::NetAccess::download() to temporary file + error check + cleanup temporary files). Under Windows, access to files at arbitrary locations requires you to essentially write a new API for your program which links against several libraries.
Re: wow - Hans - 2008-04-30
> I'm complaining about the development process, not the software. How would you have preferred it? Waiting three years until a perfect KDE 4.1 is released and all Plasma issues are fixed? Wait with the porting of Plasma to Qt 4.4 and WoC sweetness? Break the API between 4.1 and 4.2 instead, or don't review it at all? Label this release "KDE 4.1 this-is-really-REALLY-pre-pre- -pre-unstable-not-for-users-KRASH-alpha-release" ? KDE 4.1 isn't going to be perfect, nor absolutely stable, but it's one step in the progress of KDE4.
Re: wow - fred - 2008-04-30
> Because the point is not that Plasma is currently unstable, the point is that after telling everybody that 4.0 was the broken release and 4.1 was for stabilisation, they did the exact opposite and went ahead with more major changes to Plasma. > Whether they pull it together and fix things before 4.1 is released is beside the point. Porting to new APIs while adding features does not increase stability, it does the opposite. The fact that they are willing to do that shows that the claims that 4.1 was the stabilisation release was just an excuse. The truth is that 4.0 was simply unfinished and moving to 4.1 is a case of completing all the development they wished they had done for 4.0. Dude, making a software stable is not only achieved by keeping all things in order and start bugfixing. Sometimes if the underlying tool offers something better, we need to replace our own implementation with better one. With the new WoC on Qt 4.4, Plasma devs can get rid of tons of code in their own layouting and widgets code, and probably less bugs since they're now relying on Qt's layouting which is already proven. So the devs can spend their time fixing other bugs and issues rather than spending time fixing the layout issues. They can't use WoC for KDE 4.0.x simply because Qt 4.4 was not released (Qt 4.4 is to be released before KDE 4.1) You can read here: http://vizzzion.org/?blogentry=812 And some more blogs about Widget on Canvas which I've forgotten.
Re: wow - Janne - 2008-04-30
"Because the point is not that Plasma is currently unstable, the point is that after telling everybody that 4.0 was the broken release and 4.1 was for stabilisation, they did the exact opposite and went ahead with more major changes to Plasma." Again: You are whining about alpha-software. That is: software that is nowhere near release. And in case you didn't know, major version-numbers (4.0 ==> 4.1 ==> 4.2 etc.) are for new features and functionality, besides bugfixes. And that is exactly what is happening here. New functionality often bring with it new bugs. But those get sorted out. "Whether they pull it together and fix things before 4.1 is released is beside the point." No it is not. "I'm complaining about the development process, not the software." Why? What matters is the software that gets developed. I don't care one bit if KDE-coders create 4.1 night before the release, what I care about is the quality of the software that gets released. And alpha-software is way too early to pass judgement regarding the quality of 4.1.0.
Re: wow - she - 2008-04-30
No, he has a point. There was a lot of anticipation that KDE 4 will shake things up positively. I still believe it will, but there was a lot of frustration from user's point of view too. It would have been much more honest to not raise expectations too much as was done last year.
Re: wow - Aaron Seigo - 2008-04-30
> Plasma is undergoing yet more big changes rather than stabilising the changes we have done are required to stabilize things. more over, these changes were planned for 4.1 before 4.0 itself was released. this was not some random changing of everything because we feel like it ... they were changes with a purpose that were planned, expected and now executed.
Re: wow - dkite - 2008-04-30
What was written reflects my experience over the last weeks. I am reassured when what I read fits what I see. This is good. Derek
Re: wow - anon - 2008-04-30
I'm honestly getting bored of people using alpha and beta software and complaining when things aren't working, that is the point of alpha's and beta's. KDE 4 is still a beta. Released to get people to port to it. It is not something that anyone should use if they want a stable release. It's release was solely to get people porting applications to it and for people to test and find bugs.
Re: wow - JRT - 2008-04-30
I would not complain at all if 4.0.0 had been released as either Beta or the unstable branch (like other OSS). I also see no problem releasing 4.1 Alpha that is less stable than 4.0 Beta -- isn't that what you would expect. It is logical to release the new Plasma API for testing. I think that the point that people are trying to make is that Plasma development doesn't *seem* to be progressing very well. This may only be how it looks rather than the actual progress made on the internals. But, when basic things still don't work, people will wonder. I am starting to wonder if KDE is making the Vista mistake. The DeskTop is being radically changed. The question is whether users actually want this or if they would be happier with Kicker and KDesktop ported to KDE4. Since Plasma isn't going to be ready for 4.1.0, perhaps we should still consider doing this. The problem is that there are issues with Kicker and KDesktop that would need to be fixed. IAC, I think that there are users that would be much happier if the KDE 3 DeskTop GUI was ported to KDE 4.
Re: wow - Anon - 2008-04-30
Frankly, Plasma is becoming sufficiently powerful, flexible and easy to write for that someone would probably be able to re-implement Kicker and KDesktop using libplasma relatively easily. Heck, once the scripting API is a bit more stabilised, they'll probably be able to re-implement it Python/ Ruby, QtScript if they want, and you'll be able to install it using GetHotNewStuff! The default configuration of your Plasma desktop is going to become more and more of a non-issue as it matures (except for first impressions, that is :))
Re: wow - JRT - 2008-04-30
>Frankly, Plasma is becoming ... You seem to miss the point. If the existing KDE 3 DeskTop had been ported, it would be up and running NOW, not 6 months to a year from now.
Re: wow - Stefan Majewsky - 2008-04-30
Yes, it would be running _now_, but Plasma is being developed to run _now_ and _in the future_. Also, Plasma works great for me and my fellows, for example on openSUSE 11.0 Beta 1. I suspect the problems people are experiencing are due to lack of integration (the distributors need to step in here, just as the openSUSE people do) or simply personal incompetence.
Re: wow - Leo S - 2008-04-30
>> If the existing KDE 3 DeskTop had been ported, it would be up and running NOW, not 6 months to a year from now. And plasma would be developed by the magical development fairies? Yes, there could have been kicker/kdesktop in KDE4. It would have taken a boatload of time, which means that plasma would have been delayed by about a year. So you would have kicker/kdesktop for at least another year (and it would be buggier than the KDE3 version because of the port), and then you wouldn't have a replacement for a long time. Sounds like a fantastic idea. From your posts, it seems like you like to do everything the "proper" way. Rigorous design up front, then seamless migration paths, and stable the first time software. Well all that stuff is fine if you have unlimited resources. Fortunately most kde devs realize that time is limited, resources are limited, and the motivation of devs is limited, so all those things need to be balanced against the development effort. I've seen endless projects fail because they get stuck in endless planning, instead of getting something done.
Re: wow - fred - 2008-04-30
> I would not complain at all if 4.0.0 had been released as either Beta or the unstable branch (like other OSS). I recalled when GNOME released their 2.0, all people cursing GNOME devs for that release (did you remember, they did huge change to GTK and GNOME?), but now it is already very mature so that they think no big architectural changes should be introduced in the next few years. And also 4.0 is not merely for desktop users, we need to attract application developers to start utilizing the new KDE library. > I am starting to wonder if KDE is making the Vista mistake. The DeskTop is being radically changed. The question is whether users actually want this or if they would be happier with Kicker and KDesktop ported to KDE4. Since Plasma isn't going to be ready for 4.1.0, perhaps we should still consider doing this. The problem is that there are issues with Kicker and KDesktop that would need to be fixed. Uhmm... that's what people said when XP was released, MS did mistake by releasing XP at that point. And also when OS X 10.0 was first released. > IAC, I think that there are users that would be much happier if the KDE 3 DeskTop GUI was ported to KDE 4. Yeah, but they'll start bitching again when they see other cool desktops: "Hey, other desktops can do this XYZ cool stuffs, why can't KDE do this? So we will never be able to satisfy all users.
Re: wow - anon - 2008-05-01
JRT, you miss the point completely, you say the Plasma isn't progressing well. It is, it's in development stage just like KDE 4 is. If you want a stable environment use 3.5, which has been told each time people come in here complaining because they do not understand that 4 is not stable and is a work in progress. Port a very old GUI to KDE 4, yeah that would be unwise, as people want something that is continually changing and getting better. So please shut up, or start working on KDE 4 yourself, since you obviously think it is not up to your standards of work being done.
Re: wow - sebas - 2008-04-30
Well, I wrote it because it's a fact. Tagging happened in the middle of the API review porting, and when that happened, it was broken even for most of the Plasma developers -- let alone tested for users. Sure, Plasma got lots of flak in the past, but we're working hard to make it better. The last sentence in the announcement is all about not raising too high expectations for this Alpha, especially if you gauge Plasma. Even if things have settled down considerably by now already, what people that install Alpha1 will see is that Plasma is broken in lots of places. People can have a look into our 'kitchen', but should be able to stand the heat then. That said, the next pre-release will be much, much better with respect to Plasma. Other components, I'm not so worried about. What I'm running right now (latest SVN) looks rockstable already.
Re: wow - David Johnson - 2008-04-30
Widgets on the canvas is a cool feature, but please don't overdo it. Some of us don't have high end video cards. On my laptop's Radeon X1400, it's dog slow. Qt's pad navigator is barely usable and the he embedded dialogs demo is downright painful. It's even worse on my home system. This is with qt-4.4.0 release (commercial). I know this isn't KDE's problem, but Trolltech's, but it's still still going to directly impact us. I'm not going to throw away a perfectly good two year old laptop just to run the KDE desktop!
Re: wow - Aaron Seigo - 2008-04-30
> Some of us don't have high end video cards there haven't been performance degradataion associated with our use of WoC. to use your words, we haven't overdone it. thank you for your concern, i just hope this doesn't turn into another piece of FUD for me to have to deal with now.
Re: wow - David Johnson - 2008-04-30
It's not happening on my coworker's system, but it is happening on mine. Trying to move the slider on the pad navigator example shows a significant lag, and that's a pretty simple widget. The embedded dialogs demo is completely unusable. It's not a crappy video card and easily handles most things compiz throws at it with ease. (But even with a high end card, remote desktop access is still a frequent use case for me). I'll report this to Trolltech as a bug. p.s. I've tried making a screen capture with xvidcap, but it's not capturing the widgets.
Re: wow - mat69 - 2008-05-01
Maybe it has something to do with the drivers of your video card. E.g. I did not have good experiences with my X1600 AGP -- in other words it sucks -> no OpenGL ;) -- while I was able to run KDE 4 from trunk on an onboard intel chip without _any_ problems. If that was the case putting the presure on the KDE team to work around driver bugs or generall messy drivers would be the wrong way imo.
Re: wow - David Johnson - 2008-05-01
I'm not meaning to put pressure on the KDE developers, as it is a Trolltech bug. I am only alerting KDE developers to a problem that many users will face.
Re: wow - me - 2008-05-01
it's not a trolltech bug as these effects work good with on board intel cards which are less than or as powerful as your Radeon card.
Re: wow - David Johnson - 2008-05-01
Well it's somebody's bug because it doesn't work! I should add that the bug is not as pronounced on my Radeon 9000, which is a much older and less powerful card than the X1400. Also, I get great results under Windows with the same card. So it's definitely in the driver. I say this is a Trolltech bug because Trolltech has made this feature dependent on specific driver capabilities without specifying what they are. At least with antialiasing Trolltech will tell you that you need XRender. But what do I need for Plasma to work? I have no clue because Trolltech hasn't disclosed the requirements of WoC. Maybe it's something simple like one line added to my xorg.conf, maybe it's applying a well known patch to my driver, or something like that. I'm hoping it doesn't mean I have to get a new video card, because this is a *laptop*!
Re: wow - Stefan Majewsky - 2008-05-03
> At least with antialiasing Trolltech will tell you that you need XRender. But what do I need for Plasma to work? I have no clue because Trolltech hasn't disclosed the requirements of WoC. On the technical side, the whole trick about WoC is that a QWidget has QPaintDevice as its base class. That means that a QWidget can be "drawed" on every painting base (such as a display, a printed document, or a QGraphicsView which the Plasma desktop is derived of). The technical requirements for the drawing process depend on the render hints set by the application (for example: antialiasing and bilinear filtering) and, of course, on the implementation of the drawing process (for example: which external libraries are used). All of these requirements are set by Trolltech through the implementation of Qt. To come back to your question: A QWidget is essentially the same as a rectangle or an image (= an object that can be drawed on some display). If your machine can paint rectangles or images on the Plasma desktop, it will definitely also be able to paint widgets on the desktop.
Re: wow - lee - 2008-04-30
Is that really the most constructive thing you can say? It's almost like you're being paid by MS to try to stir up trouble or something.
Re: wow - Anon - 2008-04-30
Can we drop this "Someone says something bad about FOSS - OMG they *must* be paid by M$!11"? It's stupid and childish. ac is quite clearly a common-or-garden troll (or just one of these idiotic "armchair software developers" who, incomprehensibly, seem compelled to post on subjects they know nothing about) rather than a Microsoft shill.
Re: wow - lee - 2008-04-30
The fact that it's an annoying comparison is exactly why I pointed out the possibility of comparison. Most Free Software people who act in a way that could be mistaken for a Microsoft shill might actually want to rethink their behaviour once they realise this. I could take further issue with what you said above, but I'll leave it there for the sake of reducing negativity around an article about great news.
Re: wow - T. J. Brumfield - 2008-05-01
I think you're dead wrong. Openly praising bad ideas isn't helpful in the least. I love KDE on the whole, and honestly, it looks like I'll be waiting until 4.2 to switch to the 4 series at the earliest now. I'm not upset that the KDE team is taking this direction, but I can see why others are. Everyone has said, "wait for KDE 4.1, and then you'll have the stable desktop with the common features people are looking for." I was already worried since they are adding so many new features. New features do not go hand in hand with stability. Refactoring plasma at the last minute as well does not bode well for stability either. This will blow up and give more negative PR to KDE. 4.0 got good press, but it also got bad press. If 4.1 isn't stable, it will only feed the cynics and haters more. I think the real solution here is to move to something like git, where plasma breakage can happen in a seperate repository. Refactor it there, and then test some builds with it. If it works, then include it in 4.1, but what is happening now, is that people are breaking plasma in SVN, and talking about changing things up even more. Not to mention, the QT 4.4 changes have to be taken into consideration. I have little faith that KDE 4.1 will be more stable than KDE 4.0 at this point.
Re: wow - Jonathan Thomas - 2008-05-01
From the Aseigoborg: "There seems to be some concern amongst users about the massive surgery we did on libplasma this past month. The concern stems from the idea that these changes will work against the stabilization of libplasma and result in prolonging a "beta" quality to plasma itself. It's important to first understand that these changes were planned, even before 4.0. We knew that "widgets on canvas" was coming and so we could eventually remove our own layouting and QWidget bridges at some point for something that was more robust and less of a hack. We also knew that being a first revision of a library API (application programmer's interface) that would see a lot of usage, it was highly likely that changes would come to be needed or wanted. It's nearly impossible to foretell exactly what will be used and required in such an API, and it's really unrealistic to hope that the first draft of the semantics in an API will be optimal any more than it is to expect the first draft of a novel to not need any editing and revising. So before 4.0 came out I told everyone that libplasma would not be binary compatible between 4.0 and 4.1 so that we could reshape the API as needed to make it last longer. I told everyone that we'd be porting to widgets on canvas when we could begin using Qt 4.4. I told everyone that we'd be replacing the icons-on-desktop implementation with something more robust that offered access to the same features. This was all known and planned for before 4.0 was released. None of them could be done in 4.0 for various reasons (such as Qt 4.4 not being available to us), and so we lived with various hacks and bodges. Moving to the development of 4.1, we executed on these changes. Right now plasma is approximately as stable and in most areas a bit more featureful than what is in 4.0.4, even with all those backports we did to catch up the 4.0 branch. There are a few regressions that remain in the development tree right now, but they are disappearing with rapidity. But being able to finally see things happen that we always imagined, such as the device notifier expanding from an icon to the full view when dropped onto the desktop (aka "adjusting the visualization in response to the form factor"), is very rewarding to watch happen. There has been one downside to the massive changes: it took time away from creating more new features. So some of the plasmoids I wanted to have working for 4.1 may not happen and get punted to 4.2 instead. Thankfully with all this work done, features that do get worked on from here out should be easier to accomplish than when working with the 4.0 API. Thankfully we will not have to repeat this process again during the 4.x time frame. We will be able to move forward with keeping the API in place. We will add to it as needed, which isn't disruptive, while modifications such as these ones for 4.1 simply won't be on the table. So if you are concerned about the recent changes made impacting stability, I thank you for your concern and empathize with how one could arrive at such a conclusion. Thankfully, these changes have been made specifically to answer your concerns, as well as mine, about stability and feature completeness both in 4.1 and beyond. I hope that clears up a few things. If not, you may wish to track the betas and release candidates as they begin to appear near the end of May and see for yourself." From: http://aseigo.blogspot.com/2008/04/on-recent-libplasma-changes.html [My commentary now] This API refactoring was planned even before 4.0, and 4.1 is still in the alpha stage; nowhere near to release. It's still another 3 months until final release, which is half the dev cycle, with the latter part of the cycle dedicated to bugfixing. And hey, right now, a mere week after tagging alpha1, Plasma is pretty much stable again. :)
Re: wow - T. J. Brumfield - 2008-05-01
Plasma still has some serious breakage as of yesterday from what I understand. Yet, the QT 4.4 changes were only the start. Now even more changes are planned. Even if they are finished soon, those changes are being made in the 4.1 trunk. The big problem with that, is that the 4.1 trunk isn't going to get much use for bug-testing and stabilization. We'll have 4.0.4, 4.0.5, etc, and if this rate of a new release every few weeks, we'll get tons of releases from the 4.0 branch. The 4.0 branch is becoming fairly stable. When 4.1 comes out, I fear it won't be as stable because of the changes. Even if you plan months in advance that you will eventually move and rewrite things, you need time to test, bug hunt, debug, etc.
Re: wow - Sebastian Sauer - 2008-05-01
Well, we will also have 4.1.4, 4.1.5, etc. :) btw, at the time KDE 3.0.0 was published I didn't switched to it either before 3.1.something cause things where not as stable as I would like to have them for my productive system. Anyway, that KDE4 does follow the "release early, release often" rule is at the end an advantage for me. So, let's wait till 4.1.0 and probably even till 4.1.1, 4.1.2, etc. to see if KDE4 is finally stable enough for productive-systems like imho 3.1.x was :)
Re: wow - Aaron Seigo - 2008-05-02
a) where do you think the plasma features in 4.0 came from? b) we have a deadline (the 20th) after which no new features can be added, giving us a forced period of testing, bug hunting, etc. to work on stabilization for 4.1.
Re: wow - Anon Reloaded - 2008-05-01
"I think you're dead wrong. Openly praising bad ideas isn't helpful in the least." Agreed. "Everyone has said, "wait for KDE 4.1, and then you'll have the stable desktop with the common features people are looking for." Then they've spoken out of turn, or are being very optimistic. You don't bring a huge departure like 4.0.0 into something near-perfect in just 6 months. "Refactoring plasma at the last minute as well does not bode well for stability either" "3 months before scheduled release" or "one month before feature freeze" or "just after half way through the dev cycle" (take your pick) != "at the last minute". Get some perspective, please. "If 4.1 isn't stable, it will only feed the cynics and haters more." Cynics and haters don't need feeding - if 4.1 rules everything in the world, they will continue to hate. And anyway, so what? "I think the real solution here is to move to something like git, where plasma breakage can happen in a seperate repository. Refactor it there, and then test some builds with it." Agreed - I'd like to see more and more devs using Git. It seems to be an excellent way of easily managing branches. "If it works, then include it in 4.1" Disagree - there's no point having another 6 months of third parties writing against outdated APIs. The new API should be in 4.1, full-stop. And it seems it does work, anyway, so the point is moot. "but what is happening now, is that people are breaking plasma in SVN, and talking about changing things up even more." Major changes happen in trunk three months before release! - sky is falling, etc. This is basically what is supposed to happen. Frankly, I'd be worried about the future of KDE if it weren't.
Well done! - Tom - 2008-04-30
Plasma will just get stronger ;) Really happy about KDE4 so far. Thanks!
Can't wait! - Kit - 2008-04-30
I'm really looking forward to 4.1. I tried 4.0.0/1 and found it mostly stable but lacked many of the features I've been spoiled by in KDE 3.5 (in the future maybe you shouldn't make such a good desktop environment? ;) so I haven't switched full time (though I _love_ using Okular and the 4 version of KSudoku taught me how to play and love it as well). 4.1 is supposed to have many of the missing features from 3.5 (mouse scroll wheel switching desktops was one of those little things that annoyed me but I've seen added since) so I plan on trying to move again later. I hope KDevelop 4 is released around then as well (either its Dev's are quiet or I'm just not very observant... possibly both), since I'm hoping to convert my current project, a QtWebKit based browser, to being a full fledged KDE4 application (QTabWidget -> KTabWidget and QIcon -> KIcon I imagine will greatly help, the former for the scroll wheel switching and hover-close button, the latter for the ability to simply use the system's default icons instead of hard coding specific ones in or other ugly hacks). The tutorial's I've read on Techbase have been more so about working on applications that already are set up to use cmake and didn't really seem to cover how you'd convert from qmake (although I should admit I haven't looked very hard, trying to break things until they work is always my favorite way of learning things :P) After reading Aaron's blog I also believe the changes to Plasma are definitely for the best; but like KDE4 itself, there's going to be growing pains before you can have the amazing final product (remember the old adages like 'Rome wasn't built in a day' ;)
Re: Can't wait! - Will Stephenson - 2008-04-30
Mouse wheel on pager works here on 4.0.4, openSUSE.
Re: Can't wait! - Kit - 2008-04-30
I remember reading about that being backported (I'm also using openSUSE, although I only have 4.0.3, although I think thats new enough), though I haven't really tried much since 4.0.0 and 4.0.1. Next time I try moving I should take some time and write down my annoyances and any missing features I find then make sure they're documented somewhere, I'm sure theres probably a wiki page that people have already made for that (or b.k.o as a last resort). Then again I could always try my hand at implimenting the features myself (although the last time I did that another developer fixed it in SVN/CVS at around the same time I attached my patch to the bug report... curses you for stealing my thunder! :P)
Re: Can't wait! - Jonathan Thomas - 2008-04-30
Mousewheel on pager works here in Kubuntu w/ KDE 4.0.3.
Windows ports? - T. J. Brumfield - 2008-04-30
What is the status of the Windows ports? Are people working on them, or are devs needed? If so, can we put the call out? I dual-boot at home, and use Windows predominately at work (though I'm getting a new laptop at work and intend to make that a dual-boot beast as well). I'd love to use KDE apps on both. I would love to see a better installer that includes a start menu group. I'm also wondering if plasma moves into kdelibs (or a large chunk of it) if we'd possibly see more desktop components (containments, perhaps a taskbar replacement, plasmoids, etc) on Windows then.
Re: Windows ports? - Andreas Braml - 2008-04-30
I can't wait for the day when Okular, KMail, Konqueror, Dolphin, Amarok, Krita and all those other killer apps will be available on http://portableapps.com/ so that anyone can use them, even at those "install new software and you will be banned" sites. KDE4 already rocks (using 4.0.3 here), keep up the astonishing work, both in code and in honest PR on the dot and on developers' blogs.
Re: Windows port - AMAROK!!!!! :) - M - 2008-05-01
I second. ++++++++++ I can't wait for Amarok on Windows! It'll be what Firefox was to the internet browser world. :)
Re: Windows ports? - Ralf Habacker - 2008-04-30
> I would love to see a better installer that includes a start menu group. In the kdebase-runtime package there is a tool named kwinstartmenu included which makes it able to creates/update/delete start menu entries. After an installation it could be started by hand.
Re: Windows ports? - T. J. Brumfield - 2008-04-30
Thanks!
Interesting - anon - 2008-04-30
On the openSUSE news site, one of their people have stated that they wont delay 11 for KDE 4.1 because there is a chance that 4.1 will be delayed, and that it wont include some of the popular applications. I guess this comment from them is false?
Re: Interesting - Erunno - 2008-04-30
I'm not aware of any concrete plans for delaying 4.1 but there's no guarantee that it will ship on time either. If major bugs are discovered during the beta / rc cycle additional unscheduled test releases might become necessary. My guess would be that the openSUSE developers are just taking the possibility of a delay into account and don't want to take the risk of having delay their own release just to get 4.1 in (I reckon that they also have to plan for advertisement, producing the boxed version and other things which need a more stable schedule).
Re: Interesting - Iuri Fiedoruk - 2008-04-30
Also, there is no concrete plan to port for 4.1 apps like k3b, amarok and others. There is a plenty of old and good software for KDE3 that is not being worked anymore, so when distros actually abandon kdelibs3 we will loose them (but I don't belive kdelibs3 will be dropped before 10 years or more). This is really sad when good apps are not updated, can we please have a longer ABI compatibility even when qt5 is released? Niiiiiiiice please?
Re: Interesting - have a look - 2008-04-30
The porting of Amarok and k3b is ongoing. See here for details: http://polishlinux.org/kde/kde-4-rev-802150-work-in-progress/
Re: Interesting - Iuri Fiedoruk - 2008-04-30
I know, I did not meant that they will *not* be ported, but that there is no plan to follow KDE team release schedule. So opensuse guys probally tought they could not be ready for KDE 4.1 and just will wait for next release to ibnclude KDE4.
Re: Interesting - Adrian - 2008-05-01
openSUSE 11.0 will have KDE 4, just 4.0.x and not 4.1.
Re: Interesting - Iuri Fiedoruk - 2008-05-01
Yes, but will it have KDE4 only, or KDE3 as satable and 4 as an option for the brave ones?
Re: Interesting - Kit - 2008-05-02
I doubt any major distros will stop shipping KDE3 anytime soon (as in, probably 3-5 years at the soonest). I haven't read much about 11, but I'd be very shocked if they dropped 3.
Re: Interesting - binner - 2008-05-03
You don't consider Fedora major? :-) openSUSE 11.0 will have KDE 3.5.9 and KDE 4.0.4: http://en.opensuse.org/Image:OS11.0beta2-inst6.jpg
Re: Interesting - Stefan Majewsky - 2008-05-03
I guess that distributors will in 2009 stop to ship KDE 3.5 in 2009 (with the appearance of KDE 4.2 and KDE 4.3). KDE 3.5 will of course continue its life in long-life areas (LTS and enterprise distributions), four years are realistic here. If you do not believe this, take the following into account: If the KDE 3 -> KDE 4 transition takes as long as the KDE 2 -> KDE 3 transition, it would have needed about three to five years for KDE 2 to disappear from distributions. In this case, KDE 2 would have been shipped until 2007. The big news on Slashdot would then have been: "Kubuntu 7.04 to abandon KDE 2.2.205" (sounds like a legacy kernel version number).
Re: Interesting - Ian Monroe - 2008-05-01
Amarok and K3B have never followed the KDE release schedule. KDE3 apps run on KDE4 fine, OpenSUSE made sure of this, so I doubt that's an issue.
Re: Interesting - Mark Kretschmann - 2008-04-30
Amarok 2 depends on KDE 4.1, and it's progressing nicely.
Re: Interesting - Stefan Majewsky - 2008-05-03
By the way, does a release schedule exist for Amarok 2 (I could not locate one in the Amarok wiki), or is there at least an estimated release date? How far have you already come (not only on the optical, but also on the technical side)? There is not much to see about Amarok 2 in the blogs, except for nice screenshots.
Re: Interesting - apokryphos - 2008-05-01
Please don't mention this out of context, because in fact there were several reasons given -- the others being that we don't want a 10/11 month release cycle, but an ~8 month one, that 4.1 will not fix all known problems, and that other projects depend upon us adhering to our general release cycle (like SUSE Linux Enterprise). And yes, the chance of KDE 4.1 being delayed cannot be ruled out as an impossibility yet, even if we hope it will not happen.
mac edition - mac asylum - 2008-04-30
from the announce: "KDE 4.1 will also be available on Windows, Mac OS X and OpenSolaris. The ports are not yet completely finished yet, but good for a first preview nevertheless" just yesterday I installed the mac version from mac.kde.org which is from january actually and not even good for a first preview. I think the mac/win editions shouldn't be promoted in such a way because I can distinguish between a preview and a released version but I'm not sure if the average mac/win user can
Re: mac edition - anon - 2008-04-30
perhaps it is just a case of wording. To me a preview just means a glimpse at what is coming. To me I would never use anything that is advertised as a preview, because that is not a stable product, but a glimpse
Re: mac edition - Chaoswind - 2008-04-30
I think, the average mac/win-user won't find his way to news about an alpha-version of an unix-environment.
Re: mac edition - Morty - 2008-04-30
If you installed a version from january, it's obviously not KDE 4.1(alpha 1 or anything close to it). You are basing your comment about preview on ancient version not related to the anouncemet at all. And it sould have been rater obvious since the release anoncement is dated April 29, that it does not describe a version thats over 4 months old. If you are going to argue if it's a good first previev or not, the minimal requirement should be to base it on the version described as such.
Re: mac edition - illogic-al - 2008-04-30
Well in that case, it doesn't work any better now than it did in january. Happy now?
Re: mac edition - fred - 2008-04-30
Pretty sad :(, but only limited developers have Macs, 99% of them still loyal to Linux. I guess even KDE-windows team has slightly more people. P.S: 99% is only a rough number :D
Re: mac edition - hmmm - 2008-05-01
Good thing, too. Free Software platform should always remain the focus. That, and more windows and mac users is good only if it brings in more devs.
Re: mac edition - Morty - 2008-04-30
Are you basing that on having tried KDE 4.1 Alpha 1 on Mac OS X, or are you trying to be funny. In any case the parents statement makes just as much sense as claiming how unstable XP was when it was released, based on testing windows 98.
Akonadi and full MySQL-server in workstation? - Tuju - 2008-04-30
As discussed here: http://techbase.kde.org/index.php?title=Projects/PIM/Akonadi akonadi will run its own mysql-server instance in every workstation host, which sounds quite overkill if you ask me. Is this really going to remain so?
Re: Akonadi and full MySQL-server in workstation? - NabLa - 2008-04-30
Amarok2 when launched may run mysql embedded too. Well, it makes sense, mysql is a reliable and fast storage method for data...
Re: Akonadi and full MySQL-server in workstation? - Tuju - 2008-04-30
> Well, it makes sense, mysql is a reliable and fast > storage method for data... ...with that you also get constant breakage in their binary format - which actually is okay as you never should not upgrade RDBMS without dump+reload cycle and that will cause that you can't do regular backups from your /home anymore. Not to mention that you can't have NFS homes anymore, even I have that at home office, not to mention companies. This is yet-another-piece of bloat to the desktop, when kde4 with new qt was supposed to run faster than kde3. Don't get me wrong. I've been looking forward to get Akonadi and think it's the killer feature of kde4, but full mysql-server instance in workstation sounds too heavy and comes with all kind of headache.
Re: Akonadi and full MySQL-server in workstation? - JS - 2008-04-30
Don't worry, KDE4 is being optimized. Of course this is based on what profiler reports as CPU hog, not just on 'sounding too heavy'.
Re: Akonadi and full MySQL-server in workstation? - Tuju - 2008-04-30
> Of course this is based on what profiler reports as CPU hog, I wish it would be just buying-more-cpu-solution. But this is going to introduce complete new set of problems and force to create in-house solutions to overcome those. What about shared NFS homes (if those would somehow magically work), and multiple KDE versions in big enterprises? Not everybody can upgrade in one night and I thought KDE was trying to be more appealing for http://enterprise.kde.org/ right? Those sometimes incompatible dotfiles cause already trouble, I can imagine what the mysql binary blob does.
Re: Akonadi and full MySQL-server in workstation? - Ego - 2008-04-30
Later optimizations are not always effective if the base design is to heavy-weight. So general considerations are not completely out of place. Akonadis multi-process client-server architecture indeed sounds to heavy for my Eee PC.
Re: Akonadi and full MySQL-server in workstation? - lee - 2008-04-30
Hmm, I don't think that makes much sense at all actually, given that Soprano and Nepomuk will be used in Amarok2, and that these essentially provide a triple store for data.
Re: Akonadi and full MySQL-server in workstation? - NabLa - 2008-04-30
Not just yet as far as I've been reading on the IRC for amarok. A2 will be launched with its own collection scanner and database, I believe they will be integrating step by step with those technologies.
Re: Akonadi and full MySQL-server in workstation? - Anon - 2008-04-30
From the same link: "No. There has to be one Akonadi server instance per user. *However, it is possible to use a shared database server*." [emphasis mine] So I suspect that the FAQ item (to which I'm guessing you are referring) : " Do I need a running MySQL server? No. Akonadi starts it's own local MySQL server. All you need is having the 'mysqld' binary installed at runtime (usually found in the mysql-server package of your distribution)." is wrongly phrased and should be: "No. *If* Akonadi detects no shared server, *then* Akonadi starts it's own local MySQL server. All you need is having the 'mysqld' binary installed at runtime (usually found in the mysql-server package of your distribution)." This is speculation on my part, though: it would be nice to have one of the PIM fellows weigh in :)
Re: Akonadi and full MySQL-server in workstation? - Kevin Krammer - 2008-04-30
The FAQ is probably not fully up to date. I think someone already contributed code which allows postgresql to be used instead of mysql and code which allows to use a system wide DB daemon instead of a user-local one. Assuming my memory is correct on these items, it should be possible to use another database engine in case the other two cannot be used, as long as it has the necessary features, e.g. transaction support.
Re: Akonadi and full MySQL-server in workstation? - Tuju - 2008-04-30
> I think someone already contributed code which allows postgresql > to be used instead of mysql and code which allows to use a > system wide DB daemon instead of a user-local one. I don't see how postgresql would solve those listed problems. I would understand sqlite somehow as it's known to be quite simple and even its binaries are named with version (at least in fedora), thus less likely to cause version related problems. Anyway, why that STORAGE is needed anyway? I thought Akonadi was supposed to provide API to actual storage (IMAP,LDAP,Exchange): http://pim.kde.org/akonadi/ ...well, I guess I thought wrong.
Re: Akonadi and full MySQL-server in workstation? - Kevin Krammer - 2008-04-30
> I don't see how postgresql would solve those listed problems. It means that the database access is not mysql specific, thus other database backend options could be added as well, assuming the respective technology supports all the required features. > Anyway, why that STORAGE is needed anyway? Akonadi needs to store the mapping of its IDs to the ones used by remote storage systems and some place to store metadata like MIME types, cached data, etc. > I thought Akonadi was supposed to provide API to actual storage (IMAP,LDAP,Exchange) Yes, this parts are called resources. Akonadi clients, e.g. a mail client, gets the PIM data from Akonadi server, which in turn requests it from the resources unless it already has it (cached data). One advantage of this approach is that resource developers do not have to re-implement caching functionality multiple times, e.g. the user can tell Akonadi to cache only headers of a local IMAP server but to cache full emails from a remote one. Both cases can be handled by the same resource code, without its developer having to think about caching at all, e.g. where to store data, in which format to store it, etc. > ...well, I guess I thought wrong. No, you're correct, but it takes a while to understand how all the pieces work together.
Re: Akonadi and full MySQL-server in workstation? - winter - 2008-04-30
Shock! OK now that I'm calmed down, how about sqlite? I hope the MySQL server is not happening. If it is, I think we should see some figures to back up how much lighter it is than other methods.
Re: Akonadi and full MySQL-server in workstation? - Bille - 2008-04-30
http://techbase.kde.org/Projects/PIM/Akonadi#Akonadi_FAQ Having said that I hear that latest versions of sqlite have much better concurrency behaviour. Unless need for transactions blocks it, it should be possible to use that for a smaller footprint. It's also worth pointing out that the Akonadi team are talking to MySQL via their community manager to optimise MySQL for this usage.
Re: Akonadi and full MySQL-server in workstation? - T. J. Brumfield - 2008-05-01
I'm worried that an internal packaging of MySQL will be really wasted, especially if Amarok is doing the same. Will KDE 4.2 users be running two seperate engines of MySQL on their desktop? I'm curious why they didn't go with sqlite, and whether it is possible to tie together various internal uses into one engine. For instance, Firefox uses sqlite. I'd rather have the database server running once.
Re: Akonadi and full MySQL-server in workstation? - Sebastian Sauer - 2008-05-01
> Will KDE 4.2 users be running two seperate engines of MySQL on their desktop? I don't know if they like too. They can but don't need to :) > I'm curious why they didn't go with sqlite As the akonadi FAQ says, SQLite doesn't handle concurrent access very well yet. But I am sure that once it's done, we will also see a SQLite-backend since SQLite rocks :)
Re: Akonadi and full MySQL-server in workstation? - Kevin Krammer - 2008-05-01
> I'm worried that an internal packaging of MySQL will be really wasted I am not sure what you mean with "internal packaging", but just in case you mean shipping MySQL as part of the Akonadi package, we won't do that. > Will KDE 4.2 users be running two seperate engines of MySQL on their desktop? As far as I know Amarok is more likely to use the embedded variant of MySQL, however in the case that they are also going to use a separately running MySQL daemon, it can be shared. I.e. Akonadi's server config can be adjusted to point to a different database daemon and won't start its own.
Re: Akonadi and full MySQL-server in workstation? - T. J. Brumfield - 2008-05-01
Thanks for clearing that up!
Re: Akonadi and full MySQL-server in workstation? - Tuju - 2008-05-02
1. How backups should be taken care as full RDBMS should not be backed up from filesystem binary files? 2. What will happen to KDE users who use NFS /home? 3. Will this make cross-version + networked /home use more complex and incompatible? Big sites with large installations will need time to upgrade. Kevin Krammer on Wednesday 30/Apr/2008, @12:51 > It means that the database access is not mysql specific, > thus other database backend options could be added as > well, assuming the respective technology supports all > the required features. and when the Akonadi currently requires more than sqlite can provide, it means a) full-featured RDBMS b) above problems. > Thanks for clearing that up! I think nothing is cleared in this matter yet. Preventing NFS home users from upgrading to KDE4 is not a small issue.
Re: Akonadi and full MySQL-server in workstation? - Kevin Krammer - 2008-05-02
> How backups should be taken care as full RDBMS should not be backed up from filesystem binary files? Backing up the actual database files can be an option, some database systems even have a special mode of operation for that. Anyway, we are working on that. > What will happen to KDE users who use NFS /home? One possibility I could think of is using a local database location, e.g. /tmp/akonadi-$USER Since the PIM data is always loaded and stored through resource agents, the database basically just contains Akonadi internal state data and cached data. At startup this would behave similar to the current situation, where data is loaded from its actual location right into the applications, but the users still get all the Akonadi features during runtime. > Will this make cross-version + networked /home use more complex and incompatible? cross-version setups usually already use different directories, e.g. different .kde directories to avoid version conflicts, they can do the same for Akonadi directories. > and when the Akonadi currently requires more than sqlite can provide, it means a) full-featured RDBMS b) above problems. I am afraid I don't understand the intention of this statement. If sqlite does not yet provide the required features it is obviously not a candidate, but this doesn't imply needing a full-features RDBMS, any database available through a QSql plugin with the required feature set can be used, independent of how it is implemented. > Preventing NFS home users from upgrading to KDE4 is not a small issue. We are not going to do that and we quite some time available to work on solutions since KDE 4.2, the version when KDE PIM apps will have been ported to Akonadi, will be release around January 2009.
Re: Akonadi and full MySQL-server in workstation? - Ego - 2008-05-02
>> and when the Akonadi currently requires more than sqlite can provide, >> it means a) full-featured RDBMS b) above problems. > > I am afraid I don't understand the intention of this statement. If sqlite > does not yet provide the required features it is obviously not a candidate, > but this doesn't imply needing a full-features RDBMS [..] He obviously questions your definition of "required". Are the "required" features excluding sqlite really mandatory for Akonadi's purpose or are they only convenient? (No question, "concurrency" in some way is mandatory).
Re: Akonadi and full MySQL-server in workstation? - Kevin Krammer - 2008-05-04
> He obviously questions your definition of "required". Ah, ok. Since I have not been working on that part of Akonadi myself, my guess is that most these features are required in the sense that it would not work without and some in the sense that it would be a lot of work, e.g. basically creating workarounds around limitations in the software stack below.
Re: Akonadi and full MySQL-server in workstation? - Ego - 2008-05-05
I have just browsed the sources via websvn and found this interesting comment to the Akonadi::DataStore class " Use @c General/Driver to select the QSql driver to use for databse access. The following drivers are currently supported, other might work but are untested: - QMYSQL - QMYSQL_EMBEDDED - QSQLITE " After all, you seem to use throughout the QtSql module and SQLite is clearly supported by this framework.
Re: Akonadi and full MySQL-server in workstation? - Kevin Krammer - 2008-05-05
While it is true that the intention is to be able to use any database backend supported by QSql, the API docs comment is a bit outdated. Currently only QMYSQL is well tested and I think there is working but less tested support for QPSQL. Of course anyone testing new versions of sqlite and the associated QSql plugin is welcome to let us know when we can add it as well. Btw, FAQ will be updated to address the questions which came up here on the dot
Re: Akonadi and full MySQL-server in workstation? - Tuju - 2008-05-05
Kevin Krammer on Monday 05/May/2008, @00:21 wrote: > Currently only QMYSQL is well tested and I think > there is working but less tested support for QPSQL. > > Of course anyone testing new versions of sqlite > and the associated QSql plugin is welcome to > let us know when we can add it as well. Okay, thank you for the clarification in this matter. Considering that: - rdbms will be mandatory requirement - there will be more than one supported backend - it cannot be run over NFS /home - /var/cache/akonadi should be used few questions pops into mind: - how will this be handled in distro packaging and deps? Requires: some-heavy-rdbms (actually a distro problem) - how the configuration will done, assuming that user has already selected one backend and that selection has been configured into kde dotfiles which might be shared with NFS between hosts? akonadi will depend on mysql-server,postgresql-server,etc? - will akonadi be able to switch the configuration by itself and start over the cache if it finds a new backend? - will there be any *real* data or just cached stuff? assuming that in one host user had mysql and next host a postgresql, akonadi would then start caching over with postgresql. Would data be lost? - if a networked, central backed is used, how the configuration will be done to find it, manually?
Re: Akonadi and full MySQL-server in workstation? - Kevin Krammer - 2008-05-05
> rdbms will be mandatory requirement At the moment it looks like none of the alternatives (or at least not the versions that have been tested with) can provide what is needed. Since the alternatives are continuously enhanced as well, any newer version might > /var/cache/akonadi should be used For user specific data? No, that is what $XDG_CACHE_HOME would be for. We actually use $XDG_DATA_HOME, since the database can include additional metadata, e.g. application specific annotations. > how will this be handled in distro packaging and deps? I guess for now they will add a dependency on their mysql package. > how the configuration will done $XDG_CONFIG_HOME/akonadi/akonadiserverrc INI-style config file > will akonadi be able to switch the configuration by itself and start over the cache if it finds a new backend? I am not sure what you mean by "by itself". If you change the configuration to a different backend or different location and restart Akonadi, it will initialize the backend/location like on every first startup and retrieve PIM data from the resources whenever told to do so by either a applications or cache policies. > will there be any *real* data or just cached stuff? There can be additional metadata, like threading information discovered by some analysis tool, application specific annotations, etc. For PIM data (contacts, calendars, emails, etc) there is always a "host" resource > if a networked, central backed is used, how the configuration will be done to find it, manually? See above, akonadiserverrc in $xdg_config_dirs/akonadi, see also http://standards.freedesktop.org/basedir-spec/latest/
Re: Akonadi and full MySQL-server in workstation? - Ian Monroe - 2008-05-02
You seem to be arguing for sqlite, but you know it can't be stored on a NFS partition right (like any database really; I consider this to be a NFS problem)?
Re: Akonadi and full MySQL-server in workstation? - Tuju - 2008-05-05
> You seem to be arguing for sqlite, Other projects have managed do with that and it's not that bloat, as the name says. It doesn't have net interface, user management nor other complex features which are not needed in akonadi either. It's not that sexy project that would break KDE in every release like mysql does. If devs tell that there is no other way than mysql to acehive this, I'm personally fine with that. But if there is, I think we're asking for trouble for wrong reasons. > but you know > it can't be stored on a NFS partition right (like > any database really; I consider this to be a NFS problem)? $ sqlite3 test.db SQLite version 3.4.2 Enter ".help" for instructions sqlite> CREATE TABLE fish (i INT, a VARCHAR(8), b VARCHAR(8) ) ; sqlite> INSERT INTO fish (i,a,b) VALUES (1,'pike','tasty'); sqlite> SELECT * FROM fish; 1|pike|tasty sqlite> .quit $ sqlite3 test.db SQLite version 3.4.2 Enter ".help" for instructions sqlite> SELECT * FROM fish; 1|pike|tasty sqlite> .quit $ pwd /home/tuju $ mount |grep home server:/srv/home on /home type nfs (rw,soft,intr,addr=172.16.1.1) It can. The locking is the one that *may* cause trouble. http://www.sqlite.org/faq.html#q5 > But use caution: this locking mechanism might not work > correctly if the database file is kept on an NFS filesystem. > This is because fcntl() file locking is broken on many > NFS implementations. Client's probably will have recent Linux NFS anyway as they will be running fresh distro with KDE4. The question is what the server provides, some enterprise filer might not have all the bells and whistles. Anyway, as long this *really* is about caching, it should be put under /var me thinks.
KDE 4.1 Alpha 1 LiveCD - Abu.Assar - 2008-04-30
... is available here : http://home.kde.org/~binner/kde-four-live/ based on openSuse.
Re: KDE 4.1 Alpha 1 LiveCD - anon - 2008-04-30
does it work and what version Opensuse is it 10.3 or 11? OpenSUSE's 11 beta 1 live cd's don't install due to bugs.
Re: KDE 4.1 Alpha 1 LiveCD - binner - 2008-04-30
It's based on openSUSE 10.3.
Re: KDE 4.1 Alpha 1 LiveCD - anon - 2008-04-30
thanks, I'll wait then. KDE 4 in 11 looks so much better than the raw KDE packages. The Opensuse tweaks are so much better looking.
Re: KDE 4.1 Alpha 1 LiveCD - Gerry - 2008-04-30
Alas, following 10.3 update, I get kicked straight out of KDE4.1 Alpha back to log-in. Suppose I'll just have to wait. Not complaining, just instant-gratification deficient :(
I got this LiveCD - it's great. - From Brasil - 2008-05-02
Hy, thanks for this information. I downloaded this LiveCD and I can say: "it's really a great upgrade over the last LiveCD I got with KDE 4.0 Now it's possible to use the system without hanging or freezes, this is impressive. I got some issues, but all related with the LiveCD system and the small amount of software packaged there. But the new KDE is great.
Spread the good news - Gluon - 2008-04-30
On digg: http://digg.com/linux_unix/KDE_4_1_Alpha1_released http://digg.com/linux_unix/PolishLinux_KDE_4_1_Preview_Rev_802150 http://digg.com/linux_unix/Something_to_Really_Bake_Your_Noodle_A_KDE4_Plasma_Review On reddit: http://reddit.com/info/6hkpk/comments/ http://reddit.com/info/6hkx7/comments/ http://reddit.com/info/6h7pt/comments/
Thanks folks. - Martin Fitzpatrick - 2008-04-30
The alpha is pretty sweet and has me looking forward to seeing the finished 4.1. I've been using KDE4 as my main desktop since 4.0.3. I went on a bug-hunt for the first few weeks, but everything I reported was already fixed already. Now it's settled in, a few quirks and annoyances but it's not like I'd have to use 4.x if I didn't want to, is it? Keep up the good work and thanks for all you've done so far! Much appreciated.
Re: Thanks folks. - Flavio - 2008-04-30
Yeah, thank you so much, hackers! I'm still using 3.5.9 but will surely check 4.1 out. Keep up your incredibly good work! We love you.
I miss Kaffeine - NJ Hewitt - 2008-04-30
Dragon's okay at what it does, but KDE 4.0 didn't have a DVB tuner app, and it looks like 4.1 won't either. I fully realise this falls under the category of pet feature requests, perhaps only with niche appeal, but Kaffeine was the killer app for me in 2003 that brought me to Linux full-time. Well, that and hideous DVB software on Windows.
Re: I miss Kaffeine - Erunno - 2008-04-30
Kaffeine has its own release schedule and while work on the KDE 4 version has been announced about 2 months ago there's no ETA yet. It may very well be that a new Kaffeine version will be released during the 4.1 lifecycle and in the meantime Kaffeine 3 still works I presume :-)
Re: I miss Kaffeine - Just Some Guy - 2008-04-30
Yes, Kaffeine 3.x still works, and works quite brilliantly in KDE 4 (compared to crap like mplayer, the difference is night and day). But you already knew that. ;-)
Re: I miss Kaffeine - Joe - 2008-04-30
Crap like mplayer? Think you could explain your ignorance?
Re: I miss Kaffeine - T. J. Brumfield - 2008-05-01
I absolutely love mplayer personally. There are a variety of front-ends for it, but the engine is great!
Re: I miss Kaffeine - Bobby - 2008-05-01
I agree with you concerning Mplayer's engine. There are things that Mplayer manage much better than Xine but Kaffeine has the most beautiful frontend IMO. I use both but I would love a Kaffeine that can do both what Mplayer and Xine can.
Re: I miss Kaffeine - anon - 2008-05-01
I've never used mplayer, but if you believe it is carp perhaps you can work on it and improve it. That or not judge the applications people make freely available to you. I am sure many people prefer mplayer over the rest.
Re: I miss Kaffeine - Johhny Awkward - 2008-05-01
Hey, if you think mplayer is crap and kaffeine is better, why should you work on improving mplayer? Just because it's provided to you for free doesn't mean you have to like it! I'd just leave it and use kaffeine.
Re: I miss Kaffeine - Iuri Fiedoruk - 2008-05-01
Yes, most KDE3 apps are slow in the conversion, the reasons I do not know. It could be that they see no stable KDE so are waiting or the task is big. And running kde3 apps inside kde4 is not the same as running a full converted program, it's more like running a pure-qt or gtk app. Anyway, I miss kaffeine, k3b, amarok, quanta+, kdevelop... Did anyone else noticed the list IS BIG? :-( I wonder what could be done to help porting those apps to qt4/kde4. Maybe a good tutorial/howto?
Re: I miss Kaffeine - Boudewijn Rempt - 2008-05-01
People are working on all those applications and more and are making lots of progress. Working against a permanently shifting KDE api and an often shifting Qt4 api has cost lots of time. Hopefully we're past that hurdle now. What is needed are hands. Hackers. Developers. More people who are prepared to spend a few dozen hours a week of their leisure time doing the actual work.
Re: I miss Kaffeine - Ian Monroe - 2008-05-02
Porting is a big job, and I bet Amarok isn't alone in using this opportunity to refactor our code.
Missing in Feature Plan for me - Iuri Fiedoruk - 2008-04-30
- port quanta+ to KDE4 (there are two items about quanta, but it does not seems like a kde4 will be made soon) - bluetooth support in phonon Also, hoping for some items to be made before 41 final as gstreamer support.
Re: Missing in Feature Plan for me - Erunno - 2008-04-30
Bluetooth supports sounds like it would fall into the domain of Solid (hardware abstraction) and not Phonon (multimedia abstraction).
Re: Missing in Feature Plan for me - Noname - 2008-04-30
...which is only a semantic problem, but the wishlist is nevertheless valid... especially Bluetooth. I'm missing this, too!
Re: Missing in Feature Plan for me - Iuri Fiedoruk - 2008-04-30
Duh, indeed. Thanks for the correction :)
Re: Missing in Feature Plan for me - Andras Mantia - 2008-05-01
There is plan to port Quanta, but well, we would need some extra developers to make it in time. Maybe I should blog or post a separate article...
Further comments on multiprocessing - JRT - 2008-04-30
I find that there is a project to port LINDA: http://en.wikipedia.org/wiki/Linda_(coordination_language) to C++: https://sourceforge.net/projects/cpplinda/ for Linux. LINDA does explicitly what a compiler designed to run code on a multiprocessor system would do implicitly. It is not the same as multiple threads because it will automatically scale for any number of processors.
I don't get it - Uwe Thiem - 2008-04-30
It's an alpha 1 release, right? People complain that it isn't working right out of the box. People complain not every bug report has been seen to it, yet. People complain about rough edges. What the fuck! Have your parents never taught you manners? Did it never occur to you that a preview is - a preview? What is your reason to be around here? Certainly not to provide criticism that leads to enhancing KDE. Stroking your own personality? Maybe. You know, drag yourself out of OSS and go hunt deer. Or count your toes. Or watch TV, especially soapies. Don't go to a music concert - you won't understand that either. Uwe
Re: I don't get it - anon - 2008-05-01
it's the me, me, me generation. People want, they are impatient, and never give, they just take.
Re: I don't get it - T. J. Brumfield - 2008-05-01
Actually, I don't think most of the people complaining have downloaded, built or installed Alpha 1 yet. The complaints aren't that Alpha 1 isn't working yet. The complaints are about the direction for 4.1, which is supposed to be in stabilize mode, but instead is in major-shakeup mode. Will the shakeup help KDE 4 in the long run? Likely. Will 4.1 be more stable than 4.0.3 today? Perhaps not. That is what people are upset about.
Re: I don't get it - anon - 2008-05-01
It's not in shake up mode. It is in Alpha mode. Alpha's are not meant to be stable, nor are beta's.
Re: I don't get it - Johhny Awkward - 2008-05-01
I'm just pleased it's called an alpha this time, instead of just releasing it as 4.1.0
Re: I don't get it - Jonathan Thomas - 2008-05-01
KDE 4.0.0 had an alpha too. This isn't the final release of KDE 4.1.0, 4.1.0 will be released in July.
Re: I don't get it - Jonathan Thomas - 2008-05-01
4.1, as of today, is about as stable as 4.0.4, according to Aaron Seigo. It took them a little over a week to get from API-refactoring to this point. There are still several months to be spent bugfixing before 4.1 is released. I wouldn't be worried or be upset about a thing.
Re: I don't get it - Stefan Majewsky - 2008-05-03
Plasma != KDE
Re: I don't get it - Vide - 2008-05-01
TJ: *please* *stop* *screaming* about plasma refactoring. Really. Please stop.
Re: I don't get it - T. J. Brumfield - 2008-05-01
Screaming? I used terms like "perhaps not", and explained the vantage points of others to clear up miscommunication.
Re: I don't get it - Vide - 2008-05-02
Yes, screaming like a child, that's what passes from your posts. Plasma refactor was a planned and needed breakage which put an instability which will be debugged and corrected for sure before 4.1 final release, which will sport a more robust and flexible plasma than 4.0's. And you can see this just by compiling current SVN code and comparing it to 4.0.3 release (or 4.0.4 which has already been tagged, IIRC). You're spreading FUD about plasma being refactored in a such way that will be for sure instable and work-in-progress when KDE 4.1.0 will be released. Instead, I'm pretty confident that 4.1 will be a fantastic plasma release, to be honest, the first "real" plasma release (I do see 4.0 as a work-in-progress release). I mean, Plasma in 4.0-alpha1 was simply a joke (i think there weren't even a working panel). Currently, 4.1-alpha1 IMO is more usable than 4.0.3, so...
Re: I don't get it - T. J. Brumfield - 2008-05-02
Someone is most certainly overreacting like a child here. >Plasma in 4.0-alpha1 was simply a joke Here is the funny thing. Anyone who was critical of beta builds and pointed out bugs was attacked. People insisted that the 4.0 release would be better, and you shouldn't judge progress on beta builds. Yet, most of the complaints that stemmed from beta builds were still quite valid when 4.0 launched. Many of those complaints are still valid today. I've said (and attempted to clarify) that people aren't upset with the current 4.1 alpha status, but rather the rush to continue to make changes at this stage. I'm eager to get to a fully-featured KDE 4 desktop as the next guy. I don't think it is prudent to push for more changes, when you've already added a ton of features on top of 4.0, and you need to finish fleshing out the QT 4.4 changes. Many popular/code KDE apps still haven't even been ported to QT4/KDE4. KDE 4 was in and of itself a major refactoring. I think it is prudent to take some time to assess the situation, squash bugs, stabilize, etc. Again, in git, you could have changes and new features more easily handled in other areas, while the main trunk is being stabilized.
Re: I don't get it - Stefan Majewsky - 2008-05-03
> Yet, most of the complaints that stemmed from beta builds were still quite valid when 4.0 launched. Many of those complaints are still valid today. Which complaints exactly? Like I said earlier, I haven't had any crashes with Plasma since KDE 4.0 Beta (and only one minor layouting bug with an exotic configuration which is already reported). Unless you say which complaints you are meaning, your post is just FUD [1]. [1] yet another entry for my dot.kde.org buzzword bingo ;-)
Thanks - Raul - 2008-05-01
I just admire KDE developers for the courage in challenging what everyone takes for granted: The application launcher problem: Kickoff, Lancelot and maybe later Raptor, The Desktop paradigm: Plasma, The way of interacting with your computer: Nepomuk and the social desktop. It's Amazing to me that after seeing all this advances, people that have no clue of what is going on in the development just come here to trash about the release. What's more surprising is that this people (that for their comments is clear that haven't even read Planet KDE blogs or done anything to know what's going with KDE) thinks that they know better what's best for KDE and what the developers should do for the next release... I just hope that developers understand that most of this people have no idea of what they are talking about and that they keep their motivation high so that they can continue with all this exciting new ideas.
And as always... PolishLinux does it again. - Alejandro Nova - 2008-05-01
http://polishlinux.org/kde/kde-4-rev-802150-work-in-progress/ A nice preview of KDE 4.1 alpha 1. Check it out.
Re: And as always... PolishLinux does it again. - M - 2008-05-01
Niiiice!!!!! Looking forward to the screenshot tour!! I'm going to have really nice dreams tonight. :D
Just good wishes !! - From Pakistan - 2008-05-01
KDE Devs,please don't be discouraged by the comments that come from moronic not-knowing-what-they-say corners. Thrust on with all your energy. Our good wishes are always with you !!
Re: Just good wishes !! - peter - 2008-05-01
I'm looking forward to 4.1 as well, Go Go Devs we love youuuu!
Somewhat OT: KDE4 Live CDs - Luca Beltrame - 2008-05-01
As far as I understand, the KDE Four LIve is updated whenever a milestone of KDE release cycle is reached. I'd like to know if there are similar alternatives with a slightly more frequent update (like the now discontinued daily image). My home PC is way too underpowered to do constant compilations from SVN, and I'd like to see recent snapshots so I can start including KDE4.1-aware items in the Plasma FAQ. Thanks a lot.
Re: Somewhat OT: KDE4 Live CDs - Jens Uhlenbrock - 2008-05-01
Well, it's not a live-cd but the opensuse guys are constantly updating their kde 4.1 snapshots. So you just need an opensuse installation, enter the kde4 unstable paths to your package manager and constantly do updates. They have new packages at least once a week, usually more often. So no need to compile yourself.
Re: Somewhat OT: KDE4 Live CDs - SSJ - 2008-05-01
All being well, KDE4Daily - 4.1 Edition will be up and running in the next couple of weeks or so - I've mainly been waiting for Hardy Heron (which will serve as the base, so we can get lots of up-to-date versions of dependencies) to come out and for the Plasma dust (or other particles(?)) to settle :)
Re: Somewhat OT: KDE4 Live CDs - Luca Beltrame - 2008-05-02
That would be awesome! I hope you're going to submit a story on the Dot when that happens.
OpenSUSE's build service - Ian Monroe - 2008-05-01
I installed OpenSUSE on my underpowered laptop specifically for the KDE 4 trunk build service that they run. The builds aren't daily, but they do stay up to date.
Such is life - Evan "JabberWokky" E. - 2008-05-01
Thank you for doing open development (both to the devs and the people publishing the news). Quite a few of us understand what it is and are excited about the future, not dismayed into ignorant attacks.
All right - P. - 2008-05-03
Cool! :) Congratulations to all, especially to the developers!
Applause - Stefan Majewsky - 2008-05-03
Nearly all comments have to do with Plasma and Akonadi, but KDE 4 is much more. On behalf of all developers, artists, translators and other people working on KDE 4.1 I say thank you to some developers I have noticed in the last weeks: Thank you, Vladimir Kuznetsov, for the physics simulator Step. Thank you, Ian Wadham, for the rubic's cube game Kubrick. (By the way, Ian has just celebrated its 70th birthday.) Thank you, Ralf Habacker, Christian Ehrlicher, and many others for your effort to bring KDE goodness to Windows users. (This also applies to all other platform people, for example Adrian de Groot for Solaris.) Thank you, Pino Toscano, for a great document viewer. Thank you, KOffice people. (Just too many to list them all.) Thank you, Albert Astals Cid, for managing our translations (and inserting messages scripts virtually everywhere). Thank you, KDE developers, for the <personalopinion>best computing experience on earth</personalopinion>