I would agree with you if KHTML was the only open source browser engine but it isn’t. We have two that follow standards pretty good which has the added benefit that other standard complaint browsers just work.

BTW we don’t lock you away from any of the data. You can still get to them in the individual tools such as koji, bodhi, pkgdb and fas.

Perhaps I should do another blog posts similar to my Mozilla doesn’t support embedded browser posts. It is cited as one of the reasons some people in GNOME started hacking on WebKit though my original intention was to get Mozilla to start taking embedded seriously (which they eventually did). Lets be honest here, KHTML has a long way to go and they can not rely on others holding back until they catch up. As I said, I will have a talk with the devs and some of my KDE friends like Zack and Aaron at the Desktop Summit. We will see if there is some middle ground or if they can use FComm as a target to help fixing bugs in KHTML.

As for moderation, I have elipses (…) blocked because a lot of spam comments and tracebacks are something like:

John Palmieri had an interesting blog post “The project I’ve been working on…”

The KHTML devs are working on re-factoring WebKit into KHTML from what I hear, so it is there bug to fix. If a KHTML developer wants to look over our site and give us tips that will not cripple the functionality I will welcome that too but without a decent debugger, I’m not going to be able to do anything. But then again I hit resource limits using regex’s so I wouldn’t hold my breath.

Perhaps instead of going on the assault you should consider helping out with the situation. Talk to the KHTML devs, debug and file bug reports so they can fix this issue. I remember talking to a bunch of KDE guys when these issues popped up on an even simpler version of our site, and they pretty much said it was an unfortunate situation but the KHTML guys had their reasons for not switching to WebKit but it shouldn’t hold our project back. I’ll do my part and talk to the KHTML developers who are attending the Desktop Summit in July.

Thanks, it means a lot!

@ Jef

All of our apps are served off of /community/apps with a URI format (e.g. each app has a list of parameters they take). Right now you need to know the name of the apps and their params but we will be cataloging them and adding a config interface. Plazmoids, as long as they aren’t using khtml (webkit works but khtml just can’t handle the javascript) should work fine. Once we get live updates into Fedora Infrastructure via AMQP the plasmoids should update live. This all assumes Plasmoids use standard web technology.

Could we see the development of KDE plasmoid like desktop elements to move some of this dashboard functionality out of the browser window?

Or as distinct element’s in moblin’s “m-zone” browser concept?

Ya we need to talk to the transflex people about providing us with an API for adding projects and querying which packages use transifex.

We hope to add personalized dashboard pages so a user can create their own page and make it public. We need more apps and a configuration interface but dashboard apps have their own mini config language so the storage format is already written. The next step is refining the API and getting people to write apps which means we can expand the scope of Fedora Community a lot faster than just Luke, Maurine and I working on it.