Seif has done some very neat work on Zeitgeist lately. I’ve been away from coding in order to take care of personal work, but here are a few of the items on my TODO list:
1. Implicit tagging of files/documents- There are endless mountains of information on the user’s computer and on the web that can give us hints about a user’s files. I’d like to use some of this information in order to automatically sort and tag files. (E.g. Popular Delicious tags can be used to automatically label a user’s bookmarks.)
2. Automatic grouping of documents based on tags and the time they were accessed.
3. A new database design.
4. Better Open File dialogs- I’d like to display file suggestions to users based on their past file history and the list of currently open files.
Two months ago, I began working on GNOME Zeitgeist with Seif Lotfy. We were frustrated about usability problems with the current GNOME desktop, and we had several ideas about how we wanted to fix them. Under guidance from Thorsten Prante and Federico Mena-Quintero, we began programming a Python prototype.
Over time, we experimented with different interface designs as well as the underlying architecture. We played around with the journal-like interface that Federico suggested, added support for tagging, and switched to a sqlite database.
Right now, we have a basic architecture in place. From here, we’re going to move on to more interesting elements. Over the next two weeks, I’m going to do some work with Seif on implicit tagging and user contexts. Both the backend and frontend have major rewrites planned.
If you have any ideas for Zeitgeist, feel free to drop either Seif or myself an email.
I just saw this email on GNOME’s Desktop Development mailing list:
Then we can build on top of that to provide locations so you can switch the usage profile, the proxy configuration, VPN settings and other stuff basing on where you sit (and get bonus points for detecting locations basing on stuff like current wireless network). Anyway that’s a whole different story and does not belong in this thread. This sounds a lot like Marco Polo for MacOS, which I started cloning as Shackleton (http://burtonini.com/bzr/shackleton/). Ross Burton
For those of you who don’t know, Marco Polo tracks your computer usage and will automatically update locations and configurations based on your environment.
Ross, I’m looking forward to it!
At the GNOME Summit, Owen suggested the following:
Before I focus on the advantages of using multiple languages for applet development, I’d like to review a few of the key philosophies that drive GNOME Development:
- Software should be easy and simple to use for new users.
- Software shouldn’t have a large learning curve.
- Different pieces of software for the same platform should use consistent interface elements and share design decisions. Users shouldn’t need to learn new skills in order to use new applications.
When these same philosophies are applied to development and placed in a GNOME specific context their implications are:
- There should be GNOME frameworks that allow developers to easily write applications, even if they have no prior experience with GNOME.
- Developers shouldn’t have to learn many new skills in order to develop their first GNOME application. When possible, they should be able to use their existing knowledge from other platforms.
- Different pieces of software for the same platform should use the same technologies. A developer working on one GNOME application should be able to quickly jump in and contribute to a fellow GNOME developer’s application without needing to learn anything new.
The implications of 2 and 3 are problematic and contradictory. If we allow developers to jump into GNOME Development using all of their existing skills (including intimate knowledge of languages and toolkits), how can we still create a united platform that uses one set of standard and familiar GNOME technologies? More importantly, how can we create a platform with an interface that’s consistent for users?
The solution that’s been followed for the past 11 years is a simple one- Wherever giving developers extra freedom will not hurt the user experience, freedom should be given. In other words, development in multiple languages is fine, but using multiple toolkits is not fine.
This strategy has worked amazingly well. There are a wealth of applications that have been written in C, C++, Python, Mono, and a few other languages. If GNOME had begun with an ironset rule that applications may only be developed in C, we would still be in the dark ages of desktop development with all development done by a few hardcore C junkies. Heck, even if applications were allowed to be written in one “high level” language like Perl- or even the fledgling Python of 1997, for that matter- we would still never be where we are today. All of the goodness that has come out of Mono- and most likely everything that uses pygtk, as well- would have been lost in the curves and twists of a what-if history of GNOME.
The reason GNOME is so diverse and powerful today is because of it’s flexibility with regard to languages and even technologies. We’ve always embraced the new and hot, most recently with Clutter. We’ve also always allowed developers to use as many of their existing coding skills as possible. We’ve taken in developers from just about everywhere- Windows, Mac OS X, the Web, etc- and they‘re the reason that GNOME rocks so much today.