Right now it is geared towards Fedora packagers but in the future we hope to be adding a lot more functionality. Since the concept revolves around small applications running in a dashboard the possibilities are endless. Think live server status for sysadmins or up to date Fedora news for users. As always, because Fedora stands for Freedom and Community we will be emphasizing upstream collaboration which we owe a great debt for making all of Fedora possible, and Fedora Community’s code will always be licensed under AGPLv3 and compatible licenses.
To learn more you can grab the podcasts (in ogg vorbis format of course) or go to our project page.
KICK ASS!
The package maintenance profile view is going to be super useful.
Are there plans to try to tie in a view of recent bugzilla activity to the package maintenance profile summary view about my packages?
This is pretty damn hot.
I wonder, would a different dashboard organization view like this help spin maintainers?
And have you talked to the transifex folk about this dashboard tech as a translations portal?
-jef
Comment by Jef Spaleta — June 10, 2009 @ 6:02 pm
@Jef
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.
Comment by J5 — June 10, 2009 @ 6:15 pm
So…how far can this dashboard concept be abstracted?
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?
Comment by Jef Spaleta — June 10, 2009 @ 6:22 pm
This is really tremendous, John. Congratulations!
Comment by Max — June 10, 2009 @ 6:25 pm
@ Max
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.
Comment by J5 — June 10, 2009 @ 7:05 pm
The site doesn’t work at all in Konqueror, it looks from your comment #5 that you’re aware of that, so how come you even consider it releasable? The site is completely useless in the default browser of one of our own spins, this is extremely embarassing, not to mention it won’t facilitate my workflow at all.
Comment by Kevin Kofler — June 11, 2009 @ 1:33 am
Sorry Kevin, but Konq’s javacript engine just doesn’t meet standards (It fails to run the simplest jQuery queries and doesn’t have any decent JavaScript debugger). The site works fine in WebKit but the Konq developers have decided not to move to WebKit. I will support standards but I’m not going to hold the project back when two of the three major open source browsers engines work fine.
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.
Comment by J5 — June 11, 2009 @ 9:13 am
Yet web developers all around the world make their sites work with things like IE 5 which are a lot less standards-complaint than Konqueror is… It’s the site’s job to work in the user’s browser.
Comment by Kevin Kofler — June 11, 2009 @ 3:42 pm
I mean “standards-compliant”, of course.
Comment by Kevin Kofler — June 11, 2009 @ 3:43 pm
Hmmm, why is my original comment held for moderation and my correction not?
Comment by Kevin Kofler — June 11, 2009 @ 3:45 pm
IE has a very good javascript debugger. Note we don’t work with IE either yet because I don’t have a windows machine though I might borrow my roommates. I would love to support Konq but they make it hard for me to help out. It is like saying I have to support Links because it is an open source browser that some people use. It is one thing if the issue is minor incompatibilities like we had with WebKit, it is quite another if you can’t even run a regex on 32k of data before Konq pops up a resource limit dialog. File a bug with them.
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…”
Comment by J5 — June 11, 2009 @ 4:24 pm