Two days later than initially planned, "Codename" (or more traditionally KDE 4.1.2) was released just a few minutes ago. The delay was caused by binary incompatibility issues in the branch. Those have been resolved so we are now looking at a stable release. 4.1.2 is another one of those monthly bug fix and translation updates. No new features are allowed into the 4.x/ branches, so no new features went into KDE 4.1.2, but some nice bug fixes instead. David Faure has fixed a long-standing and annoying performance issue when deleting files using KIO, so you can now accidentally delete your home directory 32 times faster For the more faint-hearted, it will also work well with other files. You can read about all the changes that went into Codename in the changelog which offers links to the comprehensive SVN log files.
KDE 4.1.2 is a recommended upgrade for everybody running KDE 4. The next feature release of the KDE workspace and applications will be in January 2009 when 4.2.0 will be upon you.

Well, as one of the silent majority of KDE users who have already switched to Firefox (judging from my friends; but also from all "desktop Linux votings" which showed KDE as favorite DE, but by far Firefox as favorite browser), your comment encouraged me once again to try out KHTML. Well, what should I say - I'm still using (i.e. forced to use:( ) Firefox :-/.

Dear KDE and KHTML devs, I appreciate your work, often enough done in your free time for no money at all! Especially when hearing that there are only three active KHTML devs, it's astonishing that KHTML is still in a reasonably good state. But, let's face the fact, the WWW is rapidly evolving and other browser engines pour resources (devs and money) into the development at a rate that obviously can't be matched by volunteer-driven KDE.

You say you need more devs - fair enough. But let's face it - WebKit (backed by glamourous Google and trendy Apple) and Mozilla are probably simply more "sexy". Considering the fact that Qt 4.5 and present Plasma already incorporate WebKit, KHTML might also have - despite the official KDE stance - the mental label "legacy" for many devs (and users - e.g. me).

You say you need more bug reports - also fair enough.But see e.g. that infamous "Ebay" bug #141907. First reported over 1 1/2 years ago - still not fixed. First developer response only a few days ago! It's obvious that the problem is one of manpower, however, considering this response time to bug reports (of major sites!), you cannot blame users for not taking the time to report all the other bugs.

I also cannot understand the animosity against WebKit. For me, WebKit, evolved from the KDE technology KHTML, is one of the (many) great success of the KDE project. The fact that major corporations switched to a KDE technology instead of e.g. Mozilla shows the quality of code you KDE devs are producing. So re-integrating WebKit for me "psychologically" (if not technically, OK) would only be "bringing home again" native KDE technology. KDE has a great history of integrating community- and corporate backed technologies (Qt!!!!) and creating a free desktop experience out of the best of both worlds. What would be wrong of doing it again - WebKit will never legally be less free than the KHTML code it was originally based on!

I inititally didn't plan to write that much, sorry if it sounds like a rant to KHTML developpers. As I said before - I appreciate all your work and the time you invest in this project. However, maybe it's time for a re-evalutation..

> But, let's face the fact, the WWW is rapidly evolving and other browser
> engines pour resources (devs and money) into the development at a rate that
> obviously can't be matched by volunteer-driven KDE.

we have had idle bystanders express that kind of "let's face it" argument since very early in the project.
I know it's hard to understand for non-developers, but it simply does not work like that. Development 'speed' does not simply correlate to the number of developers, as is examplified by the fact that we are still lively and kicking after ten years of development with an average of 3 active developppers at any point in time.

> You say you need more bug reports - also fair enough.But see e.g. that
> infamous "Ebay" bug #141907.

there is no such "infamous" bug, because the incriminated menu works fine,
as is stated in the Bug Report comments, should you care to even read them.

the bug remained open because noone cared to close it yet.
Done, thanks.

> First reported over 1 1/2 years ago - still not fixed.

do you have any idea of what the time frame is for 'fixing' a bug that's not even been confirmed, and does not come with a test case?
do you have even an idea how absurd a metric that is?

I'll give you a glimpse : as of today, the number of bugs created on or before 1 and 1/2 years ago that remains open in the WebKit project is 999!

that must show obviously that webkit developers don't care about their users? ;-)

> I also cannot understand the animosity against WebKit. For me, WebKit,
> evolved from the KDE technology KHTML

and that is why you are wrong, there is absolutely no fundamental animosity against WebKit - it is another project and we don't have the same goals, that's all.

The fact that it evolved from the same initial code base is irrelevant... similarly, mice and humans share 80 percent of their DNA code base, and that doesn't make for any special relationship between the two species.

If anything, the animosity has always been the other way around.
As most corporate baked projects - especially Apple's (!!), WebKit strives more toward software monoculture. It is making aggressive moves for instance to threatens Mozilla's Gecko on their own grounds.

KHTML doesn't have any problem with software diversity, so it doesn't have a problem with WebKit's existence.

You make two assumptions:
1) That KHTML will always be behind other engines: KHTML is moving at a very quick pace, considering that it only has about three developers actively working on it. KHTML also is not burdened by various things that take up Gecko and WebKit developer time (think platform ports).

2) That Konqueror will only use KHTML: Konqueror (as a testament to KDE technology) supports hot-swappable engines (for example, Konqueror will use Okular to render PDFs). A Konqueror engine (KPart) for WebKit is currently being developed and already displays and navigates web pages.

Note: KHTML is really _just_ an HTML rendering engine. WebKit encompasses WebCore (KHTML), JavaScriptCore (KJS), and KWQ (the other assorted KDELibs and Qt libraries KHTML uses). I identify the KDE web stack as WebKDE throughout the rest of this comment. Maybe a better name could be developed by the KDE Marketing Team ;). Obviously, I'll use the terms WebCore, JavaScriptCore, KHTML, and KJS to identify the respective parts of the respective web technology stacks.

> that must show obviously that webkit developers don't care about their users? ;-)
WebKit has many more users than KHTML does. Therefore, WebKit will have more reported bugs. Also, WebKit probably has quite a bit of "fixed but nobody bothered to close" bugs as well ;).

> and that is why you are wrong, there is absolutely no fundamental animosity against WebKit - it is another project and we don't have the same goals, that's all.
As some examples:
1) WebKit is made up of a set of ports. To move the burden of porting off of the rendering engine-developer's back (where it does not belong), the WebKDE developers chose one (portable) toolkit and stuck with it.
2) WebKDE sticks to a strict KISS design, whereas WebKit does not. Ironically, Apple chose WebKDE for their base exactly because the code base was so simple and easy to hack.

> If anything, the animosity has always been the other way around... KHTML doesn't have any problem with software diversity, so it doesn't have a problem with WebKit's existence.
Well, except that may WebKit threaten WebKDE's existence, since WebKit inherits many of WebKDE's advantages (speed, relative simplicity, good design, etc) and has been ported to Qt.

> there is no such "infamous" bug, because the incriminated menu works fine,
> as is stated in the Bug Report comments, should you care to even read them.
> the bug remained open because noone cared to close it yet.
> Done, thanks.

Well, it's still there for me (only gone when using an alternative Ebay layout still considered "beta" by ebay).

The way you deal with this bug is symptomatic.... no dev ever cared to ask the reporter about details or about possible test case, the only answers where "works for me" or "i don't want to create an ebay account". And now it's simply closed.

> The way you deal with this bug is symptomatic.... no dev ever cared to ask the
> reporter about details or about possible test case, the only answers where
> "works for me" or "i don't want to create an ebay account". And now it's
> simply closed.

right, no one cared... the trolling is becoming completely silly here ;(

- comment #8 will tell you that I went all the way to *buy an actual object* on
the ebay site to check if the bug existed. It did not!

- I then obviously asked for a test case in comment #10 or may be I don't know
how to read.

- eventually comment #11 confirms my findings, that the bug is no longer
reproducible on the incriminated site, and does not speak in anyway of a beta
interface of any kind.

- So no problem? Good, closing with a comment asking to reopen if a real
instance of the bug is observed or a test case is provided!

So my question now is : have you been trolling here about this bug report for a week under various identities because you have an actual problem with this bug?

in which case you are taking the wrong approach, you should reopen the bug and fill it with the details that you apparently have and that we don't.

No I'm not trolling under different names... maybe there are more people out there encountering difficulties, you know, after all, we are talking about EBay ;). I just took this bug because the bugs of KHTML with (at least German) Ebay got on my nerves, too, and some other poster in another thread identified the bug ID and therefore it was easy to reference.

Don't take it personal, but see it from the end user perspective: The thing is, I, as a normal user, see that a bug making a popular page which is often used by me, completely unusable can persist in the bug database for over a year without any activity.

I switched then, sadly and hating it, to Firefox, because in this and other cases I saw no progress.

I appreciate that you can't do anything and many bugs, seemingly this one, too, are really difficult to track down. But, e.g. you asked for a test case. I must admit that I really would not know what you mean with that, or how I, an user not into web programming, could you provide with that! Maybe therefore no more feedback came, because the reporters of this bug didn't get a clue how they could help the programmers in fixing this bug and looked for alternatives?

But no need for further discussion, this always ends in flaming. I tried to put my criticism in better words and better founded than "KHTML sucks" - which it does not.

A testcase for a browser is usually just a URL, but in cases like this where cookies and sessions are involved, you probably have to give both a URL and step-by-step instructions of how to get from the URL to the bug.

Well, since that question was a reply to the message written by "Uset" you are at least using 3 (two in this thread and one in the report) different names for one topic within a short time. Don't take it personal, but...

if you want autohide panel, and icons on desktop ala kde3.5 way, and a lot of improvement to the plasma workspace, all you have to do is just installing kde4.1.2 from opensuse, see http://en.opensuse.org/KDE4 for further information.

And I want to say big thanks you for the kde developers, as a user who use exclusively kde trunk ( thanks for the suse build service) I have remarked with a great satisfaction that the trunk branch is very usable, and it is no more a place where developers make experimental codes ;)

Thanks really for your work, and thanks sebastian for this sentence “ The next feature release of the KDE workspace and applications “ I hope someday we will use instead “ The next feature release of the plasma workspace and kde applications”

Fedora Rawhide now has it, we're currently evaluating if it will stay for the Fedora 10 release and if it's good enough to push out as a Fedora 9 update. (A Fedora 9 build of kdebase-workspace with autohide (kdebase-workspace-4.1.2-4.fc9) is sitting in our build system "Koji" and getting some testing too.)

Where KDE (and just about every other project) has stable branches to avoid introducing bugs and regressions, SuSE then puts various features in there which are not even stabalized for release for 4.2 ?

Do I understand that correctly? If thats indeed what is happening and users find bugs in there (and they will!) I just hope its not going to be held against KDE.

All distros customize packages to some degree, which can include backports. They also maintain these backports, so that if there's a problem, they can put out a fix right away. They all encourage users to file bugs with the distro first. This system has been working pretty well for quite a while now.

Ok, all distros do "some" customization of "some" packages somewhere, but Slackware for example tries to keep it to an absolute minimum and ships almost 100% what they get from upstream.
This is actually a *very* nice thing since you get the exact behaviour that upstream developers expect you to get and when you find bugs and report them the bugreports are always relevant since it's never due to some distro patch that stuff broke, and generally things "just work". I've always wondered why so many distros patch so much stuff when upstream un-modified usually just works...
I wish more distros would do what Slackware does.

btw in the case of opensuse it just backported a snapshot of plasma trunk, just to provide some urgent features for people who use kde4.1.x, anyway as long as they ship the same kde4.1.2 platform ( kdelibs, kdesupport, kderuntime, qt etc) all the other modules are just apps. a newer version never heart anybody ;)

openSUSE customize stuff. AFAIK, they always did. They started Kickoff for instance, which is the default menu in KDE 4 right now.

They have their own usability folks and want to give the user their own, sometimes slightly different, experience.

Distributions have the benefit to be right between the user and the developer, hence they can do small adjustments to fit their needs. I wouldn't think the dot and planet reader or kde mailing list subscriber is the average KDE user - only the tech freaks. Your average everyday n00b goes to the openSUSE forums and complains about missing autohide there.

To sum this up: I think it is very important that they offer highly demanded features before upstream does, at least if they do it with their own time and money, and respond to bugs themselves. The main reason why I use openSUSE is the unmatched KDE 4 support and the clever customization. If I wanted vanilla, I'd use LFS or, you name it, Slackware. I don't.

Yeah, pretty much I am with you and there have been instances in the past where KDE developers have discovered that bugs reported to them have in fact been introduced by distros messing with the code.

Having said that, openSUSE have the manpower and expertise to generally do a fairly good job of their tweaks and backports - I say this as a former (although not current) suser. Unfortunately my experience has been that Kubuntu tweaks/backports have introduced more issues and there was an interesting issue with Amarok and Fedora a while ago where Fedora made an unstable backend the default (they had their reasons and this has since been resolved). But generally It think following close to upstream has advantages - as Slackware, Arch (without KDEmod) and, increasingly, Fedora are tending to do.

OpenSUSE is jsut like every other distro, it has it's good and minor points, but the attitude of people like the previous poster and yourself is what stinks about the linux community. This complete divison between distro's where certain twats just troll to give negaitve comments about distor's. Really it is time people like you grow up and realise while you do this, you harm the entire linux community, and the amazing work that each distro puts into not only their distro's but into the kernal, the desktop environments and every piece of linux

But when compared to Debian, can you just imagine that - perhaps - even the power user just doesn't always want to manually tweak 10,000 things before everything works? This was really a problem with the non-stable Debian releases (where some up-to-date hardware required some new sub-systems Debian stable didn't have).

That piece of crap seems to be whipping a lot of asses, even in the Linux world. There must be a reason why it's No. 2 on Distrowatch.
I bet you are an Ubuntu user. I just hate this type of self-discrimination among Linux users.

I happen to think bikesheds are important and a key factor in a complicated issue, namely that of congestion and the question how livable a city is. :-) A great codename for the next KDE release, IMHO!

(Yes, I understand the bikeshed argument, but I choose not to apply it)