I didn't think that I'm going to write a blog describing OLS, but I wanted to point out a few things:
Nat's dashboad presentation - horrible. The man curses more than I, or anyone else I've ever seen does. I don't know if that's the way he is or whether he was doing that only for the talk but that still doesn't explain why "fuck dude, shit doesn't work" or "shut the fuck up dude, let me finish" were the leading ideas of his presentation. Other Gnome developers/users present on the talk served the purpose of cheerleaders for Nat. The whole thing was just stupid. The basic idea is good, unfortunately it's pretty much taken from the Microsoft Longhorn. Like Aaron once noted in his blog, the gui for this thing is unacceptable. It's way too intrusive. Also the quering mechanism that Nat & co. are using is pretty much based on broadcasts of clue packets all over the place which simply will have to change at some point or it will become incredibly slow. My favorite quote from the presentation though is : "Dude, we have like 1000000 threads running at a time, we create a thread for string duplication!", which, I think, was a good thing in Nat's eyes. Heh, good luck...
Havoc's freedesktop.org bof - the discussion in itself was limited, but only because the crowd has been mostly composed of kernel hackers who simply don't know that much about the freedesktop.org initiative. After the presentation Havoc, George and I went to a bar to talk a little. I had a horrible headache that day but conclusion I have is : "Havoc is a great guy". You can quote me on that ;) Hopefully we'll see him on n7y
Keith's/Carl's Caito tutorial - in one word "impressive". I do like the idea and implementation. The design is clean and api very friendly. I'll be playing with it today, pretty much because I want to play with it on OS X. Porting Xc to OS X will be fun ;)
In other news I coded a lot during the whole thing. Some of the things I'll commit today or tomorrow include :
AltiVec instruction detection in KCPUInfo,
an icon in the KMail email fetching statusbar notifying users whether the connection is ssl/tls encrypted (that one is for George ;) ),
some accelerator fixes in KMail that we found,
new OSCAR protocol implementation, based on Gaim's libfaim so that Kopete's and Gaim's team can share some code.
Anyway, back to coding...
I'm very keen on hearing Havoc talk about freedesktop.org at n7y. I think having a toolkit independant set of standards we all adhere to will allow us to compete as desktops but not screw the users by being incompatible.
Personally I think the better we define standards there the better we can interoperate without forcing the adoption of each others toolkits or languages.
In the end Gnome and KDE push each other on, and the users will win, they will get the best apps, and they all work together.
wtf is dashboard? a google search give me www.nat.org/dashboard ... but
I get slashdot everytime .... so maybe is just a vaporware written by morons .... ;)
the dashboard concept
The idea is a query based context pannel that updates related information based on the current query.... while a neat idea, the interface has proven unusable over the last 10 years of the ideas existance.
im not sure what the best approach for the UI is, since the backend is trivial to write. Apple and MS have both refined the art of indexing services, and via htdig and glimpse we have come close with at least basic file types... the missing link now is the UI...
the dashboard concept
Isn't this a service that each application would best know how to use? For example, Kmail. Having access to a quick index of all the saved emails would be useful. Currently the search folders are so slow. Too slow to be useful. Any references to email data could be presented by kmail in the best way it knows, ie. search folders. Another example in kmail, the autocompletion of addresses. Having a smarter, faster indexing could make it more powerful. Note that the application could (and does) do it themselves, but an optimized indexing service may have advantages.
Another possiblility is to use bookmarks. They are well developed already, but maybe having a dynamic content in a bookmark would be useful. Something I run into quite often is a repeated google search. What I've looked at is already saved somewhere, as the links are colored differently. How about recognizing the pattern of the search, making a dynamic bookmark folder of some sort with the already visited sites. The information is out of the way, but accessible. Again, any improvements in bookmarks would also extend to the indexed data.
The temptation is to do too much. A little of the right information at the right time would be very useful.
Not Caito but Cairo
Small typo Zack...