I have been thinking more lately about Federicos "Document Centric" presentation. Document and file management is by far the hardest thing for users to understand. I kind of feel that considering it's 2008, there is very little hope of that situation improving. So I was checking his mockups on ideas for helping people find their documents. Users tend to cringe on learning something new, or having to go into a new program.
So as a rough proof of concept I wrote a ksh script to convert $HOME/.recently-used documents generated by OpenOffice into a .ics file and then allowed Evolution to load the results. I kind of like all date related items being stored in the same software. Email is open all day, which makes it immediately useful. No clickable links obviously, but at least points them in the right direction. I submitted it to the cron for a few power users to see how it runs. I threw it on an internal webserver and they are now using webcal:// to view the data.
file://, easy to see it's a file. Mouse-over tooltip provides full file name
We know the time of the file touch as well, so we can put it inside a 1 hour window.
Here is the WFM code, no attempt was made to make it pretty and useful to other people:
Edit: The paste of the code failed, some of the tags were picked up as HTML. So created a link
Here is the code
8 comments:
I like this idea a bunch.
The idea of finding files by date is good, but not implemented in this way.
If I recall correctly this was mentioned in Federico's presentation, but for anyone who hasn't actually seen it (you should!), there was another project doing roughly the same thing: http://www.iola.dk/nemo/
I suspect this implementation was done either to avoid C#, provide integration with the calendar people are already likely using anyway, or both. Either way, glad to see multiple approaches to this being worked on.
Oh, the reasons for it were mentioned in the post, I just didn't see it on my too-quick scan through the post. That'll teach me to actually throughly read something if I'm going to bother commenting on it.
Actually what I am testing is the idea of displaying information in this manner vs any attempt at a final design. I am going to try and make my way to the Boston Summit this year, so I'm trying to get myself current on some of the new ideas being kicked around in the GNOME world.
As for nemo: I have seen it. It currently does not connect to Beagle static indexes, so I'm not able to put it into a test mode. We are not watching file system changes in real-time, they are performing nightly and placed into the static databases.
please, don't use the recently-used file: gtk+ is not using that, and any gnome application should use the new XBEL-based recently used file format that gtk+ provides since the 2.10.0 release.
the XBEL format is far superior, giving you a lot more information, and it's easily parseable (python has an xbel module, as well as perl and other languages - and the actual parser is even included inside glib's GBookmarkFile API). the old custom format was the result of copy-and-paste code and was deprecated for a reason.
openoffice should just switch over to the XBEL-based format, if it did not already.
emmanuele: No biases on the file here. :) I just used what was currently being generated from OOo.
nice. looks like what Nemo was build for:
http://www.iola.dk/nemo/
(if only it worked...)
definitely the right direction and gnome should really push this philosophy.
Post a Comment