On Fri, 2010-04-09 at 18:09 -0400, Owen Taylor wrote: > I've attempted below to extract out some of the technical bits from > http://live.gnome.org/GnomeShell/Design/Whiteboards/FindingAndReminding > and see how they line up with our current technology. This is just > notes, not yet a concrete plan. > > - Owen > > File management ideas and technology > ==================================== > > "Things can safely fall off the desktop" > > The desktop is reconceptualized as "what you are working on", > "the most relevant items". Getting something off the desktop then > shouldn't require an explicit filing decision by the user. The user > should be able to let items "expire" with attention, or they should be > able "archive" an item to remove it from the desktop. > > There are two basic approaches here - one is to avoid storing > things on the Desktop. Instead of seeing the Desktop as a separate > location in the file selector, you'd have a checkbox: > > [ ] Pin to Desktop > > (or whatever the designers come up with), and that would create > a symlink to the desktop. > > The other approach is when expiring or archiving to move files > from ~/Desktop to an archival location like ~/Documents.
I don't have much time to participate in this discussion atm, but i'd like to point out here that the current implementation of the nautilus desktop is done as a "virtual" location that merges various sources. It would not be hard to let it contain any random set of files given a way to locate them. Of course, this would make the "desktop" folder not very useful, and would need similar work in the file selector. > "User defined tags" > > A completely flat view of all documents doesn't handle all users > or use cases. "Frequent filers" will want to be able to identify > projects and other subsets of files. > > There's not a detailed plan for the user interface right now, but > technically this could be done a couple of ways. > > We could use the traditional method of grouping by using > folders; and just make that look somewhat tag-like in the > UI. (Make selecting a folder show all the files in that folder > and all sub-folders. Allow creating a folder of files without > worrying where it was and automatically creating it in > ~/Documents.) > > Or we could use a real tag-based approach with tags stored in > metadata. (multiple tags per file, tags orthogonal to folders.) Does tracker currently index gvfs/gio metadata? Thats a highly efficient way to set small "non-extracted" metadata on files that will automatically be copied/moved/etc when files are managed with nautilus or other gio apis. > "Adding non-files to Desktop" > > Files won't be the primary interesting thing for all people; > we probably want to provision for at least putting web > bookmarks into the desktop area. (This is also interesting > for people who want to have a GNOME desktop for their users > configured in some particular way.) > > Probably the existing way we do web bookmarks for ~/Desktop will work. Davidz and i have had long discussions about adding a new bookmarks API for gio. Its in bugzilla somewhere and might be helpful for this. > Tracker > ======= > * Using Tracker to extract and index metadata from files is > pretty uncontroversial. Using Tracker as the primary store > of information (such as tags) is more controversial - suddenly > the user's data is dependent on the use of Tracker. I'm personally of the opinion that we should use a separate store for such metadata, and then index this with tracker. Which is why i created the gvfs metadata storage: http://blogs.gnome.org/alexl/2009/06/24/data-about-data/ -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc [email protected] [email protected] He's a benighted umbrella-wielding assassin with a passion for fast cars. She's a strong-willed impetuous archaeologist from the wrong side of the tracks. They fight crime! _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
