On Sat, 2010-04-10 at 09:10 +0200, Johannes Schmid wrote: > Hi! > > > 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. > > The pinning should be done automatically and the files should stay in > the place I saved them (e.g. a firefox download should end up in > ~/Downloads and OO.o should default to ~/Documents. The recent files > should be stored by pinning on the "Desktop".
What, if anything, gets pinned automatically is an interesting question - there's a pretty strong case if I create a new word processing document it should automatically get pinned. But if I save an email attachment, probably not? If everything is pinned, that's pretty much the same as pinning nothing. Pinning something to the desktop is making a "todo" item - it's something that you think you'll need to attend to in the future. > > "Timeline view of files" > > > > For items that aren't on the desktop (the "slip") the default view > > is a chronological one with "yesterday", "last week", and so > > forth. So we need to be able to organize user's files this way. > > > > One approach is to keep track of user accesses and edits via > > Zeitgeist (or in simplifed form by ~/.recently-used.xbel) > > > > The other approach would be to treataccess/edit time a > > metadata property, and to use tracker to search over these > > properties. > > > > (Note that the timeline here only includes each item once, > > not once for each usage - I use "timeline" somewhat differently > > below) > > Why would the timeline only include each items once? I really would like > to see the activity journal here as it is so much more like people > remember things. I assume that by "the activity journal" you mean a UI like GNOME Activity Journal, and not the current GNOME Activity Journal? (It wouldn't really be possible, or at least at all easy, to to use a separate pygtk program within the GNOME Shell Overview.) Jon McCann is off enjoying the beaches of Mexico this week, unfortunately for getting deep into the design side, perhaps some of the other designers who participated in the discussions want to chime in. My quick take on the issue is that its a question of density - the GNOME Shell overview is meant to make as much as possible immediately available to hand. Because repeats are shown, and because of the fixed time organization, the "activity journal" presentation is quite low density. This is even more the case when narrowing using cross-cutting filters... if I only want to see the slide presentations, then the vast majority of days in the last year will have no activity at all. But certainly there are cases where using episodic memory, where drawing the connection from one document to a related document is of great use. I probably can find my slides from GCDS pretty easily with search (they are called 'gcds.odp'), but how do I go from there to the SVG source of the illustration 'shell-components.svg'? If I could somehow pop from finding gcds.odp to a calendar/timeline view of all the times I edited that file, then it would be easy to find the SVG file. Ther are some interesting ideas there, and there are also considerable design challenges (a simple one is that there is no way to "select" items in the overview design - it's single click activation. And anything you put into a right click menu might as well not be there for most users.) [ Obviously related: "Search by iterative date comparison" in http://www.gnome.org/~seth/zuhanden-gnome3.pdf ] [...] > > Not much yet - I think it will definitely be hard to implement > > our ideas without something that looks a lot like Tracker, and > > since we have Tracker something that looks a lot like Tracker > > is most likely Tracker :-) Zeitgeist seems less centrally crucial, > > but there is a role for event logging here. > > Some of the more advanced search technologies really need tracker, I > agree here. I am not sure if we want to depend on it hard for 3.0 but > that can be discussed. Would would a soft dependency on Tracker mean? Having tracker-search-tool in the menus isn't the interesting thing. The interesting thing is to be able to do deep integration into the shell. You could have fallbacks similar to the current file search in GNOME Shell - just restrict search and browsing to filenames in ~/.recently-used.xbel. But that's a really degraded experience. If we've designed things with the assumption that you can search and browse through all your files, but you are running without Tracker and it actually is restricted to a subset of recently used files, it's not going to work out well. On the other hand, if there are reasons that Tracker isn't suitable to make a hard dependency, then I'm not sure it makes sense as a soft dependency. If we were talking about Tracker 0.6 rather than Tracker 0.8, would we want to offer users the choice that they can have good search across their files, if they are willing to accept system performance being horribly degraded in some circumstances? (An obvious problem with a hard dependency on Tracker is that the GNOME 2.30 based distributions - Fedora 13, Ubuntu 10.04, etc. - are still shipping tracker-0.6.9x. So, if we hard-depend on Tracker, people developing and testing GNOME 2.31 components will need a newer version of Tracker than shipped on their system - not a blocker, but a bit of a nuisance.) We have to design and build a single thing - that we want reviewers to review, that we want users to use. > But as said above I really want to have the activity journal available > inside the shell as I think it is beside the shell another central point > for 3.0 What the central points of 3.0 are have to be based on how they fit into the overall vision. If an activity-journal like view makes sense in the overview, then we should implement that and market it for 3.0, but we shouldn't be forcing an activity-journal into the overview *just* because it's something that has been discussed in the planning for 3.0. So, if you want an activity-journal than there has to be design-side engagement to figure out how it fits in. If it replaces the current loosely chronological view in the mockups, how does it accomplish the same tasks? How does it relate to the "Desktop"? > Most important would be to come up with a plan what we have in 3.0 and > what we might have in 3.2 as I doubt anything will be ready by the time > 3.0 is released. Certainly. I'm pretty confident we can do some interesting stuff for 3.0, but we clearly can't do everything for 3.0. - Owen _______________________________________________ gnome-shell-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-shell-list
