Re: Linking 'Activities' and recent documents



On Tue, 2009-01-13 at 19:05 +0100, Milan Bouchet-Valat wrote:
> Le mardi 13 janvier 2009 à 11:53 -0500, Owen Taylor a écrit :
> > I think modifying the data in the overlay to take into account the
> > current activity is a pretty neat idea. I'd certainly like to see
> > someone do some prototyping around the idea of activities being more
> > than just workspaces.
> > 
> > We also had the idea in a discussion yesterday that you could
> > potentially do the same thing for web browser history ... especially if
> > "recent pages" or "recent sites" was integrated into the overlay in some
> > fashion.
> I have no clue about how this could be implemented. I guess
> Firefox/Epiphany extensions would do the trick. But from gnome-shell
> itself, not much can be done.
> 
> This is where the hard part starts: if you want to link Activities to
> things other than launchers, bookmarks and recent files, you have to
> change code inside applications. This in turn requires you to have a
> precise idea of a standard Activities implementation. We can start from
> recent documents and see how this works, so that later things can be
> extended.

I don't think it's competetely impossible to do without modification:
you could imagine keeping a timeline of what workspace was active at
what time ... by correlating that with an external history list, you
could figure out what URLs were accessed from what workspace.

But certainly recent documents is a good place to start.

> > Modifying GTK+ to write in the current workspace or activity for each
> > document would certainly be an approach, but since the whole idea of
> > activities isn't really worked out yet, its maybe a bit premature...
> > that is, to have to modify GTK+ just to prototype this out will make it
> > hard to try things out.
> Sure. While this Activites framework should not be too complex, we'll
> likely need to experiment with it first.
> 
> > A different approach would be for the shell to observe bookmarks being
> > added to recently-used.xbel and to either keep a look-aside database 
> > or edit the history to include extra metadata about the current
> > workspace.
> >
> > (See the connection to the 'changed' signal of recentManager for where
> > you would hook in when new documents get added.)
> 
> That's what I proposed in my last mail:
> > Your proposal using a _NET_WM_CURRENT_ACTIVITY property could be nice
> > to complete the bookmarks after they have been saved. The problem is
> > still: apps won't save their window name in the bookmarks. How can you
> > distinguish between two instances of GEdit running at the same time on
> > two Activities? Or you may assume only one Activity is active (sic) at
> > the one time?
> I'm OK to investigate this way, it shouldn't be too hard. But either we
> must work around this window identification problem, or we need to
> assume that only the current Activity is adding recent documents. What
> if a program in the background (from another Activity) saves a file? How
> can you know which one of several running instances of an app is doing
> that? This may be a corner case, though. What do you think?

I think it's going to be necessary to make the user interface robust
about mistakes ... that is, the user isn't going to perfectly segment
their work between their activities ... they might open
a document on the wrong workspace and then move it, say.

Thus, it needs to be easy and obvious how to switch from a "narrowed"
recent documents (only those documents relevant to all activities) to
all recent documents. With that in mind, I don't think it matters a
lot if we get some obscure cases wrong.

You could also build extra cleverness into the shell. One thing you
could do:

If someone uses File/Open to open a document and it takes very long
time and the user has switched to a different workspace in the mean
time, the shell can look at the same timestamp that is used for focus
stealing prevention and say "this window w"as opened as a result of
activity 10 seconds ago. 10 seconds ago activity X was active"

- Owen




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]