Re: Recently Used Files Proposal

[Emmanuele Bassi]

Hi Alex,

On Wed, 2006-04-26 at 09:54 +0200, Alexander Larsson wrote:
> On Wed, 2006-04-26 at 09:29 +0200, Petr Tomasek wrote:

> > In the menu you have usually only a few "recent files". If you look
> > for something little older it would have sense to have special dialog.
> > 
> > (I hate the fact, that most gnome programs have only 5 recent files
> > in the menu, on the other hand I can understand, that having more
> > would blow them, so a dedicated dialog would be very good thing.
> > You can even have 5 items in the menu followed by "More..." entry,
> > that let you open the dialog...)
> 
> At some point its just more efficient to open the file selector instead
> though. Especially since the old file you were looking for might not be
> in the recent dialog either, causing you to first have to browse through
> that and then open the file selector anyway.

According to the plan, the FileChooser should have recent files support
as soon as the async-branch and the changes Federico has planned go in;
I still don't have a patch, as the code base is a moving target, but the
changes are pretty much straightforward, and I plan to work on them as
soon as I can, in time for 2.10.

Ciao,
 Emmanuele.

-- 
Emmanuele Bassi - <[EMAIL PROTECTED]>
Log: http://log.emmanuelebassi.net

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Murray Cumming]

On Thu, 2006-04-27 at 15:57 +0100, Emmanuele Bassi wrote:
> The email you are replying to is a year old
[snip]

Oh, sorry, I guess I overdid trying to find the top of the thread.

I'm still not convinced that many applications will want to use a dialog
without a menu list, or that there's a big user demand for that, but I
think,
a) If >1 applications need it, the dialog should be in GTK+.
b) It would indeed be nice to have a "more ..." menu item.

-- 
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Alexander Larsson]

On Thu, 2006-04-27 at 16:04 +0100, Emmanuele Bassi wrote:
> 
> The email Murray was replying to was a draft sent a year ago.  It's
> not valid anymore: the UI of the recently used documents has been
> changed since then.
> 
> There are three widgets inside GTK, at the moment: a GtkMenu, useful
> for setting a sub-menu for a GtkMenuItem or a GtkMenuToolButton; an
> embeddable widget showing a list and a GtkDialog with that widget.

Sounds good!

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   [EMAIL PROTECTED][EMAIL PROTECTED] 
He's a world-famous Catholic rock star with a secret. She's a psychotic winged 
schoolgirl living homeless in New York's sewers. They fight crime! 

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Emmanuele Bassi]

Hi Alex,

On 4/26/06, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-04-25 at 08:12 +0200, Murray Cumming wrote:
> > On Thu, 2005-06-02 at 10:19 +0200, Emmanuele Bassi wrote:
> > > I've considered the option of making a menu, but I decided that we
> > > should avoid it for latency reasons; applications might just have a
> > > "Open recently used..." item which launches the dialog (many
> > > applications already use a submenu, there's no difference for the user's
> > > point of view), or we could add the ability to show recently used
> > > resources into the GtkFileChooser, near where we put the bookmarks.
> >
> > Aah, have you changed your mind about this? I haven't seen much
> > discussion of this change of a de-facto UI convention. Not that I
> > personally know what's better.
>
> It sounds like a change for the worse to me. Its very quick to browse
> the menu for the old file you were looking for. Opening a new dialog for
> it is very heavy and slow, and its less likely you'll even see the "Open
> recently used..." menu and understand what it does.
>
> I think much fewer people will use the recent files feature with a ui
> like this.
>

The email Murray was replying to was a draft sent a year ago.  It's
not valid anymore: the UI of the recently used documents has been
changed since then.

There are three widgets inside GTK, at the moment: a GtkMenu, useful
for setting a sub-menu for a GtkMenuItem or a GtkMenuToolButton; an
embeddable widget showing a list and a GtkDialog with that widget.

The treeview-like widget supports multiple filters, and is useful for
showing >15 items; it can be embedded inside a pane (think of gedit
side panes) or the dialog that embeds it automagically can be launched
from a "More..." menu item appended to the RecentChooserMenu.

There is also a plan for a GtkAction for showing recent files inside a
UI built using GtkUIManager; it has been pushed back because I'm
moving and I can't fully work on it until the 4th of May, when I get a
stable internet connection.

For an example of the widgetry, there are a couple of test programs
inside the libegg/recentchooser directory of libegg.

Ciao,
 Emmanuele.

--
It is against the grain of modern education to teach children to program.
What fun is there in making plans, acquiring discipline in organizing
thoughts, devoting attention to detail, and learning to be self-critical?
-- Alan Perlis
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Emmanuele Bassi]

Sorry, I'm moving from Milan to London, and my internet connection is
still sketchy at best.

The rationale for the widgetry is better explained here:

  http://live.gnome.org/RecentFilesAndBookmarks

anyway.

The email you are replying to is a year old, and is part of my
preliminary draft for the recent files design.  In the last year I've
detailed the rationales and the design of the entire architecture and
UI; now that the stuff has been merged is a little late for going
through the design process once again, methinks.

On 4/25/06, Murray Cumming <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-06-02 at 10:19 +0200, Emmanuele Bassi wrote:
> [snip]
> > On the UI side, we should have a GtkRecentChooserDialog and a
> > GtkRecentChooserWidget, for which I have prepared a mockup at the GUADEC
> > Hackfest; you might see it here:
> >
> > http://www.emmanuelebassi.net/images/shots/recent-items-viewer.png
>
> Who is going to use these? Isn't everyone just going to use the menu? Is
> this equivalent to anything that exists in applications today?

Gimp is already using a widget like this for their document history.
Also, the rationale is that the menu is useful for showing <15 recent
documents (as per HIG) so we need a way to display the whole (or a
subset of the) history of recently used documents.

Gimmie, for instance, has a list view, AFAIR.

The panel should show a "More..." item on the Places > Recent Documents menu.

> If this is intended to be used in some system-wide utility then maybe
> the code should be moved out of GTK+.

I really don't understand the rationale for this.  Then the whole
recent documents system could be moved out of the GTK.

> > I've considered the option of making a menu, but I decided that we
> > should avoid it for latency reasons; applications might just have a
> > "Open recently used..." item which launches the dialog (many
> > applications already use a submenu, there's no difference for the user's
> > point of view), or we could add the ability to show recently used
> > resources into the GtkFileChooser, near where we put the bookmarks.
>
> Aah, have you changed your mind about this? I haven't seen much
> discussion of this change of a de-facto UI convention. Not that I
> personally know what's better.

The design has been changed.

See the wiki for more discussions about it.

Ciao,
 Emmanuele.

--
It is against the grain of modern education to teach children to program.
What fun is there in making plans, acquiring discipline in organizing
thoughts, devoting attention to detail, and learning to be self-critical?
-- Alan Perlis
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Alex Graveley]

http://www.beatniksoftware.com/gimmie/img/gimmie-topic-documents.png

Dum de dum... :-)

-Alex

Petr Tomasek wrote:

In the menu you have usually only a few "recent files". If you look
for something little older it would have sense to have special dialog.


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Petr Tomasek]

> > 
> > In the menu you have usually only a few "recent files". If you look
> > for something little older it would have sense to have special dialog.
> > 
> > (I hate the fact, that most gnome programs have only 5 recent files
> > in the menu, on the other hand I can understand, that having more
> > would blow them, so a dedicated dialog would be very good thing.
> > You can even have 5 items in the menu followed by "More..." entry,
> > that let you open the dialog...)
> 
> At some point its just more efficient to open the file selector instead
> though. Especially since the old file you were looking for might not be
> in the recent dialog either, causing you to first have to browse through
> that and then open the file selector anyway.
> 

If you have many files/directories, the file selector is terribly
inefficient (not to talk about that it is terribly slow).

Anyway, why not to let the user choose if he wants to use file chooser
or recent files dialog? If the number of recent files was limited
by combination of fixed number (so you would have at least allways
have xx recent files) and time (e.g. you allways have at least
the files opened since last week let's say), the would know what he
should expect.

P.T.

-- 
Petr Tomasek 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Alexander Larsson]

On Wed, 2006-04-26 at 09:29 +0200, Petr Tomasek wrote:
> > > 
> > > Aah, have you changed your mind about this? I haven't seen much
> > > discussion of this change of a de-facto UI convention. Not that I
> > > personally know what's better.
> > 
> > It sounds like a change for the worse to me. Its very quick to browse
> > the menu for the old file you were looking for. Opening a new dialog for
> > it is very heavy and slow, and its less likely you'll even see the "Open
> > recently used..." menu and understand what it does.
> > 
> 
> In the menu you have usually only a few "recent files". If you look
> for something little older it would have sense to have special dialog.
> 
> (I hate the fact, that most gnome programs have only 5 recent files
> in the menu, on the other hand I can understand, that having more
> would blow them, so a dedicated dialog would be very good thing.
> You can even have 5 items in the menu followed by "More..." entry,
> that let you open the dialog...)

At some point its just more efficient to open the file selector instead
though. Especially since the old file you were looking for might not be
in the recent dialog either, causing you to first have to browse through
that and then open the file selector anyway.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   [EMAIL PROTECTED][EMAIL PROTECTED] 
He's an uncontrollable crooked card sharp with a secret. She's a cold-hearted 
African-American nun with an incredible destiny. They fight crime! 

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Petr Tomasek]

> > 
> > Aah, have you changed your mind about this? I haven't seen much
> > discussion of this change of a de-facto UI convention. Not that I
> > personally know what's better.
> 
> It sounds like a change for the worse to me. Its very quick to browse
> the menu for the old file you were looking for. Opening a new dialog for
> it is very heavy and slow, and its less likely you'll even see the "Open
> recently used..." menu and understand what it does.
> 

In the menu you have usually only a few "recent files". If you look
for something little older it would have sense to have special dialog.

(I hate the fact, that most gnome programs have only 5 recent files
in the menu, on the other hand I can understand, that having more
would blow them, so a dedicated dialog would be very good thing.
You can even have 5 items in the menu followed by "More..." entry,
that let you open the dialog...)

P.T.

-- 
Petr Tomasek 
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Alexander Larsson]

On Tue, 2006-04-25 at 08:12 +0200, Murray Cumming wrote:
> On Thu, 2005-06-02 at 10:19 +0200, Emmanuele Bassi wrote:
> > I've considered the option of making a menu, but I decided that we
> > should avoid it for latency reasons; applications might just have a
> > "Open recently used..." item which launches the dialog (many
> > applications already use a submenu, there's no difference for the user's
> > point of view), or we could add the ability to show recently used
> > resources into the GtkFileChooser, near where we put the bookmarks.
> 
> Aah, have you changed your mind about this? I haven't seen much
> discussion of this change of a de-facto UI convention. Not that I
> personally know what's better.

It sounds like a change for the worse to me. Its very quick to browse
the menu for the old file you were looking for. Opening a new dialog for
it is very heavy and slow, and its less likely you'll even see the "Open
recently used..." menu and understand what it does.

I think much fewer people will use the recent files feature with a ui
like this.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   [EMAIL PROTECTED][EMAIL PROTECTED] 
He's a shy small-town werewolf from the Mississippi delta. She's a mentally 
unstable blonde stripper with the power to see death. They fight crime! 

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Murray Cumming]

On Thu, 2005-06-02 at 10:19 +0200, Emmanuele Bassi wrote:
[snip]
> On the UI side, we should have a GtkRecentChooserDialog and a
> GtkRecentChooserWidget, for which I have prepared a mockup at the GUADEC
> Hackfest; you might see it here:
> 
> http://www.emmanuelebassi.net/images/shots/recent-items-viewer.png

Who is going to use these? Isn't everyone just going to use the menu? Is
this equivalent to anything that exists in applications today?

If this is intended to be used in some system-wide utility then maybe
the code should be moved out of GTK+.

> (It's also a semi-working Perl program, which uses the current
> recent-files implementation and its Perl bindings).
> 
> We could provide more than the filter based on the timestamp, as we do
> for the GtkFileChooser widgets.
> 
> I've considered the option of making a menu, but I decided that we
> should avoid it for latency reasons; applications might just have a
> "Open recently used..." item which launches the dialog (many
> applications already use a submenu, there's no difference for the user's
> point of view), or we could add the ability to show recently used
> resources into the GtkFileChooser, near where we put the bookmarks.

Aah, have you changed your mind about this? I haven't seen much
discussion of this change of a de-facto UI convention. Not that I
personally know what's better.

[snip]

-- 
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Emmanuele Bassi]

Hi all,

* Emmanuele Bassi <[EMAIL PROTECTED]>:

> I have a generic GObject-based parser (which currently doesn't handle
> metadata, at least until I come up with an idea on how to register
> custom objects representing custom metadata), and a GObject-based parser
> specifically designed around my desktop-bookmark spec (linked on the
> wiki), which is what we should use to store recently used items on disk.
> 
> I'll clean them up and upload them.

I finally emerge from the depths of job-related troubles at $ORK.

I've created a GLib interface for my desktop-bookmarks spec (using
GKeyFile as a guideline for its API); it's simple, documented, pretty
much complete (I think we are going to need some sort of file locking,
as the I/O on this kind of files could potentially take some time; maybe
it would be best if GLib itself would offer some locking primitives -
see bug #307131 [1] for instance) and It... works! (BRAOUM! CRASH!).

It would be used for accessing any XBEL data stream using the custom
metadata specified by the desktop-bookmarks spec[2].  It depends only on
glib-2.0 >= 2.6.0 and libxml2 >= 2.0.0;

You can find it here:

http://devel.emmanuelebassi.net/software/desktopbookmarks/libegg-desktopbookmarks.patch

Now, I'm going to work on the EggRecentManager API using this as
the backend.

Regards,
 Emmanuele.

+++

[1] http://bugzilla.gnome.org/show_bug.cgi?id=307131
[2] http://devel.emmanuelebassi.net/papers/bookmark-spec.html - needs
some editing, but basically is there

-- 
Emmanuele Bassi (Zefram) [ http://www.emmanuelebassi.net ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Aschwin van der Woude]

On Wed, 2005-06-08 at 15:35 +0100, Calum Benson wrote:
> On 6 Jun 2005, at 12:57, Aschwin van der Woude wrote:
> >
> > Perhaps I am alone in such situation, but at least for me the "recent
> > files" list is not very useful in most cases.
> > Even if this is more common than my own personal experience, I am not
> > sure what a solution is to this use-case. Perhaps grouping recent- 
> > files
> > per directory or such...  I dunno... I am just pointing out my own
> > observations.
> 
> Sounds like you might want something like either:
> 
> Recent Files > Today >
> Yesterday >
> Monday >
> Sunday >
> Saturday >
> Friday >
> Thursday >
> --
> All Recent Files >
> 
> or
> 
> Recent Files > Documents >
> Pictures >
> Music  >
> Websites >
> .
> .
> .
> ---
> All Recent Files >

Wow! They both sound great! 
Perhaps the latter one might be slightly easier. Or at least *I* would
need to think harder whether I opened a picture on Thursday or some
other day, but would know it was a picture.

BTW the "recent files" submenu is in the bottom of the "Places" menu,
which is quite far down if you have created many bookmarks, devices, or
network-links. I'd say the submenu should be in top, which should also
make it easier on muscular memory as it would be always in the same
place (on screen) and require less movement with the mouse.

-Aschwin

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[David A Knight]

On Thu, 2005-06-09 at 15:09 +0200, Emmanuele Bassi wrote:
> Hi,
> 
> On Wed, 2005-06-08 at 12:28 +0100, David A Knight wrote:
> > On Wed, 2005-06-08 at 10:34 +0200, Emmanuele Bassi wrote:
> > 
> > > The recently used manager is checked by GtkFileChooser: developers need
> > > not to meddle with a RecentManager object directely.  Once a document is
> > > opened or saved using the FileChooser, it is automagically added to the
> > > list.
> > 
> > A nice idea in theory, however it doesn't handle the case of a document
> > being opened via drag/drop, so applications would need to use
> > RecentManager for that.
> 
> Why is that?  For DnD targets we could supply a simple text/uri: any
> RecentChooser implementation should provide it by default.  Unless I'm
> missing something very obvious, here.

For the exact same reason a GtkFileChooser has access to the manager, to
add new items.  

The RecentChooser is an API intending for widgets that allow viewing the
recent items isn't it?  Not adding new items.

Looking at the RecentChooser API the only method that possibly sticks
out to add a new recent item is set_current_uri().  If this is what it
is for, the name isn't entirely obvious, adding a recent item has
nothing to do with setting a current uri, and then requires you to get
the item, then set the mime type etc. which is then exposing parts of
the RecentManager interface.

It seems far more logical to me that an application would just use the
recent manager, which is the underlying model, rather than going through
a view.  My understanding of this could be clouded completly by the
current eggrecent code.


David

-- 
Make your website SCREEM - Site Creating & Editing EnvironMent

URL:  http://www.screem.org/
Mail: [EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Emmanuele Bassi]

Hi,

On Wed, 2005-06-08 at 12:28 +0100, David A Knight wrote:
> On Wed, 2005-06-08 at 10:34 +0200, Emmanuele Bassi wrote:
> 
> > The recently used manager is checked by GtkFileChooser: developers need
> > not to meddle with a RecentManager object directely.  Once a document is
> > opened or saved using the FileChooser, it is automagically added to the
> > list.
> 
> A nice idea in theory, however it doesn't handle the case of a document
> being opened via drag/drop, so applications would need to use
> RecentManager for that.

Why is that?  For DnD targets we could supply a simple text/uri: any
RecentChooser implementation should provide it by default.  Unless I'm
missing something very obvious, here.

Kind regards,
 Emmanuele.

-- 
Emmanuele Bassi <[EMAIL PROTECTED]>
Web site: http://log.emmanuelebassi.net

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Calum Benson]

On 6 Jun 2005, at 12:57, Aschwin van der Woude wrote:


Perhaps I am alone in such situation, but at least for me the "recent
files" list is not very useful in most cases.
Even if this is more common than my own personal experience, I am not
sure what a solution is to this use-case. Perhaps grouping recent- 
files

per directory or such...  I dunno... I am just pointing out my own
observations.


Sounds like you might want something like either:

Recent Files > Today >
   Yesterday >
   Monday >
   Sunday >
   Saturday >
   Friday >
   Thursday >
   --
   All Recent Files >

or

Recent Files > Documents >
   Pictures >
   Music  >
   Websites >
   .
   .
   .
   ---
   All Recent Files >
Cheeri,
Calum.

--
CALUM BENSON, Usability Engineer   Sun Microsystems Ireland
mailto:[EMAIL PROTECTED]Java Desktop System Team
http://ie.sun.com  +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[David A Knight]

On Wed, 2005-06-08 at 10:34 +0200, Emmanuele Bassi wrote:

> The recently used manager is checked by GtkFileChooser: developers need
> not to meddle with a RecentManager object directely.  Once a document is
> opened or saved using the FileChooser, it is automagically added to the
> list.

A nice idea in theory, however it doesn't handle the case of a document
being opened via drag/drop, so applications would need to use
RecentManager for that.



David

-- 
Make your website SCREEM - Site Creating & Editing EnvironMent

URL:  http://www.screem.org/
Mail: [EMAIL PROTECTED]



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Emmanuele Bassi]

Hi,

On Wed, 2005-06-08 at 00:37 -0500, Federico Mena Quintero wrote:
> On Thu, 2005-06-02 at 10:19 +0200, Emmanuele Bassi wrote:
> 
> > I've spoken with Federico at GUADEC about the recently used files
> > handling, and we came up with some ideas for improving the current
> > situation.
> 
> I must say that the huge delay at the crappy restaurant in front of the
> conference center certainly helped us in terms of having enough time for
> our discussion :)

We *definitely* should have stealed/broken something... :-)

> > I've attached a prototype API for GtkRecentItem and GtkRecentManager
> > (already set to live in libegg, for the time being). Let me know what
> > you think of it.
> 
> This looks very good!  I have a few minor comments about the API, which
> I'll post tomorrow if I have time.  In the meantime, I sketched out a
> list of requirements here:
> 
>   http://live.gnome.org/RecentFilesAndBookmarks
> 
> [I moved the old content to a sub-page, for reference.]

Saw it, but interspersed commenting on the wiki is ugly.  I'll comment
here.

+++

Do we need timestamps for both "last visited" and "last modified"? Isn't
one of them enough? 

Short answer: XBEL needs them. :-)
Long answer: "modified" and "visited" are semantically different; a
"recently used" applet should just update the "visited" attribute when
it launches an item, and not the "modified" attribute, which would be
modified when an application register itself or when a group is added or
when the visibility flag is changed.

  * Are the timestamps for the recent item itself, or the
item they point to? (The time the file on disk was
created vs. the time the recent item entry was
created.) 

The "added", "modified" and "visited" timestamps pertain just to the
item; the "timestamp" attribute is used when an application registers
the item.  A "mtime" attribute for the resource pointed by the item
would require another metadata field.

  * When an item can be modified by others as well, the
distinction would enable to answer the question "Has
this item changed since I last looked at it?" 

  * Is "number of times accessed" a single property, or is it
per-application? 

I started with a per-item property, but then switched to a
per-application one, since it would enable a finer-grained filtering and
sorting.

  * Do we need the private flag? What uses it currently? 

Short answer: nobody uses it, but we should keep it.
Long answer: visibility on a per-registration or per-group system would
be tricky; the "Private" flags is just an hint for viewers: it says
"this item should not be visible if you did not register it, or if you
do not belong to any of the groups in it".  Viewers might decide to show
it anyway, but at user option.

  * Icons. This is somewhat up to the caller, I think, as it can
just call gnome_thumbnail_factory_lookup() on an item's URI. If
the thumbnail is missing, it can simply use the icon
corresponding to the item's MIME type. For GtkFileChooser in
particular, the file chooser will certainly call
gtk_file_system_render_icon() internally, which uses an abstract
GtkFilePath (which is, in effect, a URI). 

Agree.

  * Get notification when the items change. 

This would require something inside Gtk to check for changes without
poll()-ing each URI every N milliseconds;  inotify could be the answer,
but Gtk does not depend on it yet.  So I think that this should go into
a platform library, which uses the list from RecentManager and monitors
each item inside it for changes on the resource pointed by the URI.

Need a way to populate the "recently used" part of the File menu. 

  * EggRecentViewGtk lets you specify a GtkMenuItem after
which the items will be inserted 

EggRecentViewGtk is brain damaged: it should be wiped out with fire and
medieval tools.  What we need is a subclass from GtkMenu, to be attached
as a submenu to an 'Open Recent...' stock menu item; this would make
adding items to it painless.

Something like this:

  GtkWidget *r_item;
  GtkWidget *r_submenu;
  GtkRecentFilter *filter;
  
  /* filter on the tuple:
   *   (, , )
   */
  filter = gtk_recent_filter_new ();
  gtk_recent_filter_add_mime_type (filter, application_mime);
  gtk_recent_filter_add_application (filter, application_name);
  gtk_recent_filter_add_group (filter, application_group);
  
  r_item = gtk_image_menu_item_new_from_stock (GTK_STOCK_OPEN_RECENT,
NULL);
  r_submenu = gtk_recent_chooser_menu_new ();
  
  /* filter and sort the recently used files submenu */
  gtk_recent_chooser_set_sort_type (GTK_RECENT_CHOOSER (r_submenu),
GTK_RECENT_SORT_MRU);
  gtk_recent_chooset_set_filter (GTK_RECENT_CHOOSER (r_submenu),
filter);

  /* this fires every time a menu item containing a recent item is
   * activated; the callback sig

Re: Recently Used Files Proposal

[Emmanuele Bassi]

Hi,

On Wed, 2005-06-08 at 00:44 -0500, Federico Mena Quintero wrote:
> On Thu, 2005-06-02 at 10:19 +0200, Emmanuele Bassi wrote:
> 
> > I've attached a prototype API for GtkRecentItem and GtkRecentManager
> > (already set to live in libegg, for the time being). Let me know what
> > you think of it.
> 
> Oh, BTW... to see what other systems do already, I looked at the Win32
> API and Cocoa.

I did look at Win32 APIs.

They use the Registry to store their data, so I came up with a more
generic manager (API attached).

The new RecentManager is an abstract interface, providing simple methods
that accesses a storage system; we could implement the storage of
recently used items using XBEL, GConf, the Registry, etc.; the storage
backend is platform dependent, as we already do with the GtkFileSystem
interface.

The recently used manager is checked by GtkFileChooser: developers need
not to meddle with a RecentManager object directely.  Once a document is
opened or saved using the FileChooser, it is automagically added to the
list.

The list itself is showed using a RecentChooser UI, be it a menu or a
completely new widget.

Ideally, the first time a user instantiates a RecentChooser or a
FileChooser object, a RecentManager is created a set as a global object;
the best idea I came up with is to attach it to the GdkScreen as we
currently do with the IconTheme object - it's convenient, even though it
could yield some notification latency across multiple screens.  Then,
every other FileChooser or RecentChooser would simple have to access
that RecentManager:

  recent_manager = g_object_get_data (screen, "gtk-recent-manager");

This would decrease memory footprint, allow inter-process notification
and also cut off the locking issues we currently have.

> Emmanuele, do you already have a working parser for XBEL using libxml2
> or whatever?  This would be a good start to implement the API for GTK+.

I have a generic GObject-based parser (which currently doesn't handle
metadata, at least until I come up with an idea on how to register
custom objects representing custom metadata), and a GObject-based parser
specifically designed around my desktop-bookmark spec (linked on the
wiki), which is what we should use to store recently used items on disk.

I'll clean them up and upload them.

Kind regards,
 Emmanuele.

P.S.: I've attached the interface for the RecentManager and for the
RecentChooser objects, and an implementation of a 'Open recent' menu
object using the RecentChooser interface.

-- 
Emmanuele Bassi <[EMAIL PROTECTED]>
Web site: http://log.emmanuelebassi.net
/* eggrecentmanager.h: Abstract recent manager interface
 * Copyright (C) 2005 Emmanuele Bassi
 * 
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this library; if not, write to the
 * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 * Boston, MA 02111-1307, USA.
 */

#ifndef __EGG_RECENT_MANAGER_H__
#define __EGG_RECENT_MANAGER_H__

#ifndef EGG_RECENT_MANAGER_ENABLE_UNSUPPORTED
#error "EggRecentManager is not supported API for general use."
#endif

#include 

G_BEGIN_DECLS

typedef gint64 EggRecentTime;

typedef struct _EggRecentItem		EggRecentItem;
typedef struct _EggRecentAppInfo	EggRecentAppInfo;
typedef struct _EggRecentManager	EggRecentManager;
typedef struct _EggRecentManagerIface	EggRecentManagerIface;

/*
 * GError enumeration for EggRecentManager
 */
#define EGG_RECENT_MANAGER_ERROR	(egg_recent_manager_error_quark ())

typedef enum
{
  EGG_RECENT_MANAGER_ERROR_INVALID_URI,
  EGG_RECENT_MANAGER_ERROR_NOT_FOUND,
  EGG_RECENT_MANAGER_ERROR_NOT_REGISTERED,
  EGG_RECENT_MANAGER_ERROR_PARSE,
  EGG_RECENT_MANAGER_ERROR_READ,
  EGG_RECENT_MANAGER_ERROR_WRITE,
  EGG_RECENT_MANAGER_ERROR_FAILED
} EggRecentManagerError;

GQuark	egg_recent_manager_error_quark 	(void);

/*
 * Detailed informations on the application registering a recent item
 */
#define EGG_TYPE_RECENT_APP_INFO	(egg_recent_app_info_get_type ())

GType		  egg_recent_app_info_get_type  (void) G_GNUC_CONST;

EggRecentAppInfo *egg_recent_app_info_new	(void);
EggRecentAppInfo *egg_recent_app_info_copy	(EggRecentAppInfo *info);
void		  egg_recent_app_info_free	(EggRecentAppInfo *info);

G_CONST_RETURN gchar *egg_recent_app_info_get_name  (EggRecentAppInfo *info);
void		  egg_recent_app_info_set_name  (EggRecentAppInfo *info,
		 const gchar  *name);
G_CONST_RETURN gchar *egg_recent_app_info_get_exec 

Re: Recently Used Files Proposal

[Federico Mena Quintero]

On Thu, 2005-06-02 at 10:19 +0200, Emmanuele Bassi wrote:

> I've attached a prototype API for GtkRecentItem and GtkRecentManager
> (already set to live in libegg, for the time being). Let me know what
> you think of it.

Oh, BTW... to see what other systems do already, I looked at the Win32
API and Cocoa.

Win32 has a little set of functions:

SHAddToRecentDocs:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/functions/shaddtorecentdocs.asp

"Most Recently Used" functions:
  CreateMRUListW()
  AddMRUStringW()
  EnumMRUListW()
  FreeMRUList()

These are all pretty trivial; they are really what one would use to
implement the core of your proposed GtkRecentManager, and the rest is
higher-level functions.  So you are on a good track, as they don't
really have anything more exotic than that :)

Cocoa doesn't seem to have much in this regard, or I couldn't find it.
I *think* its recent-files list gets maintained automatically if you use
their NSDocument classes.

Emmanuele, do you already have a working parser for XBEL using libxml2
or whatever?  This would be a good start to implement the API for GTK+.

  Federico

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Federico Mena Quintero]

On Thu, 2005-06-02 at 10:19 +0200, Emmanuele Bassi wrote:

> I've spoken with Federico at GUADEC about the recently used files
> handling, and we came up with some ideas for improving the current
> situation.

I must say that the huge delay at the crappy restaurant in front of the
conference center certainly helped us in terms of having enough time for
our discussion :)

> I've attached a prototype API for GtkRecentItem and GtkRecentManager
> (already set to live in libegg, for the time being). Let me know what
> you think of it.

This looks very good!  I have a few minor comments about the API, which
I'll post tomorrow if I have time.  In the meantime, I sketched out a
list of requirements here:

http://live.gnome.org/RecentFilesAndBookmarks

[I moved the old content to a sub-page, for reference.]

As to your Perl mockup --- do we need such a megawidget inside GTK+?  I
think it would only be necessary if we wanted the main way in apps to
access the recent files to be through such a dialog.  However, if we put
this in the desktop itself (Nautilus or the Panel?), then it should not
be inside GTK+.  I wouldn't worry about it too much right now, except
for sketching out how it would actually use the proposed API to see if
the API makes sense.

Other than that, the mockup looks gorgeous :)  It's a bit cluttered, but
it's a great start.

  Federico

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Aschwin van der Woude]

On Mon, 2005-06-06 at 17:03 +0200, Emmanuele Bassi wrote:
> For this, we should have a more complex UI, paired up with a simplyer
> one, in order to view all the recently used resources.

A always thought it might be handy to easily switch context. E.g. switch
to doing work, photography, etc.
Within one context the recent-files would be different than the next.
But as this is merely a simple thought, I don't know how this would look
like or work in real life. And surely its more of grand-picture idea
than an idea specifically for the recent-files thing.

> Also, the proposed API allows the creation of per-application lists, and
> even meta-classes of applications (recently used items that shows up in
> a class of applications, say Editors or Media Players).

While these are useful they do require to open the app first, and if a
user would have opened a file using nautilus he might not always know
which app it was he used to edit or view the file.


> So, what I am proposing is not just the revamped version of the current
> recent-files code: it's more like a more generic approach to the issue.

I don't mean to shoot down you idea or implementation. I merely wanted
to point out my experiences, in case they make sense beyond my personal
use case.

Thanks,

-Aschwin

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Emmanuele Bassi]

Hi,

On Mon, 2005-06-06 at 14:57 +0300, Aschwin van der Woude wrote:
> On Sat, 2005-06-04 at 08:43 +, DANIELLLANO wrote:
> > Emmanuele Bassi wrote:
> > > What if you want to open a document you edited some time ago (but not
> > > too long), and it went out of the menu?
> > 
> > Then it's not a Recent Document.
> 
> I have always found the "recent files/documents" list kinda useless. I
> use my computer for various tasks, some work related some private. 
> 
> During work I might use a small set of files, or perhaps just even work
> on a single document during the day. In the evening I might pick up my
> digital photography hobby and review a bunch of photographs and perhaps
> even edit them. (Nautilus, eog, gimp)
> 
> The next morning I start working again and want to continue to work on
> the file I was editing the day before. Unfortunately it already fell off
> the "recent files" list, and I will have to dig out that file myself
> again. Which is pretty deeply nested in my cases, as I have lots of
> files to keep around.

For this, we should have a more complex UI, paired up with a simplyer
one, in order to view all the recently used resources.

And I say "recently used resources", not documents/files, since
everything that could be expressed as a resource could be saved into the
recently used list.

Also, the proposed API allows the creation of per-application lists, and
even meta-classes of applications (recently used items that shows up in
a class of applications, say Editors or Media Players).

So, what I am proposing is not just the revamped version of the current
recent-files code: it's more like a more generic approach to the issue.

Kind regards,
 Emmanuele.

-- 
Emmanuele Bassi <[EMAIL PROTECTED]>
Web site: http://log.emmanuelebassi.net

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Mike Emmel]

On 6/6/05, Aschwin van der Woude <[EMAIL PROTECTED]> wrote:
> On Sat, 2005-06-04 at 08:43 +, DANIELLLANO wrote:
> > Emmanuele Bassi wrote:
> > > What if you want to open a document you edited some time ago (but not
> > > too long), and it went out of the menu?
> >
> > Then it's not a Recent Document.
> 
> I have always found the "recent files/documents" list kinda useless. I
> use my computer for various tasks, some work related some private.
> 
> During work I might use a small set of files, or perhaps just even work
> on a single document during the day. In the evening I might pick up my
> digital photography hobby and review a bunch of photographs and perhaps
> even edit them. (Nautilus, eog, gimp)
> 
> The next morning I start working again and want to continue to work on
> the file I was editing the day before. Unfortunately it already fell off
> the "recent files" list, and I will have to dig out that file myself
> again. Which is pretty deeply nested in my cases, as I have lots of
> files to keep around.
> 
> Perhaps I am alone in such situation, but at least for me the "recent
> files" list is not very useful in most cases.
> Even if this is more common than my own personal experience, I am not
> sure what a solution is to this use-case. Perhaps grouping recent-files
> per directory or such...  I dunno... I am just pointing out my own
> observations.
> 
> -Aschwin
> 

A solution to this thats not too invasive and may be possible is to
record the application that opened a file and group by application
first. Next is to notice that multiple applications are being used on
the same file and create the meta group. In general you want to have a
design that allow you to build up a ontology. Too do this I think  its
important for the framework to be able to be extended to add new time
dependent tasks to gather new information and too allow groupings to
be created and saved.  Consider the proposal of a most rececently used
file menu to be one view into this ontology back end.

Another generic use case is lets say your also using documentation or
other urls as you work on something you would like the urls to also be
associated with the current files as current urls.  It seems to me
that one important point is you need to define a top level task to get
the system started. This can be done via some hueristics and would
probably work okay but it makes sense to allow the user to define the
current session and allow them to pick sessions as they change what
there working on.  You could also create anti-sessions that do the
reverse and ensure that no trace of the sessions stays on the
computer.

A use case I'd be intrested in is one where I tend to work via ssh on
a remote server with a web browser up for docs. I'd like to save that
"session" its directories etc.  This would require that the ssh client
report session info back from a remote machine too my session manager.

I'm not saying that you need to do all this stuff but I really think
that the proposal is just one aspect of a bigger problem thats useful
to solve and if done correctly it can provide the framework to build
out  cooler stuff :)

Taking the time to use DBus here in the right places might make a lot
of sense for example.


> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Aschwin van der Woude]

On Sat, 2005-06-04 at 08:43 +, DANIELLLANO wrote:
> Emmanuele Bassi wrote:
> > What if you want to open a document you edited some time ago (but not
> > too long), and it went out of the menu?
> 
> Then it's not a Recent Document.

I have always found the "recent files/documents" list kinda useless. I
use my computer for various tasks, some work related some private. 

During work I might use a small set of files, or perhaps just even work
on a single document during the day. In the evening I might pick up my
digital photography hobby and review a bunch of photographs and perhaps
even edit them. (Nautilus, eog, gimp)

The next morning I start working again and want to continue to work on
the file I was editing the day before. Unfortunately it already fell off
the "recent files" list, and I will have to dig out that file myself
again. Which is pretty deeply nested in my cases, as I have lots of
files to keep around.

Perhaps I am alone in such situation, but at least for me the "recent
files" list is not very useful in most cases.
Even if this is more common than my own personal experience, I am not
sure what a solution is to this use-case. Perhaps grouping recent-files
per directory or such...  I dunno... I am just pointing out my own
observations.

-Aschwin

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Emmanuele Bassi]

Hi,

On Sat, 2005-06-04 at 14:07 +0200, Sven Neumann wrote:
> Hi,
> 
> Emmanuele Bassi <[EMAIL PROTECTED]> writes:
> 
> >> That's it. Very simple, very common. Currently, I can open one menu
> >> (Places->Recent Documents) and 'solve' that user problem.
> >
> > What if you have more than one document with the same name?
> 
> The menu item should have a tooltip with the full filename.

And potentially more - and it should be set up directely in the API, in
order to enforce consistency.

> > What if one is a copy you keep on a network share?
> 
> What's the problem?

As I said in another followup, the network volume could be set read-only
when the user tries to access it; we need a way to let the user know
that the item he's seeing in the list is potentially out of date.

> > What if you want to open a document you edited some time ago (but not
> > too long), and it went out of the menu?
> 
> The menu should feature an item at the bottom that allows the user to
> open the GtkRecentChooserDialog that you suggested. That gives access
> to not so recently used items w/o taking away the possibility to
> access very recently used items as quickly as possible.

Right now, I'm implementing the infrastructure upon which each UI we
choose should be created - much like the GtkFilesystem object is
necessary for the GtkFileChooser widgets to work.

Once I'm done with the infrastructure, the UI could be respond to an
interface - with widgets implementing this interface; at which point, a
menu, a dialog or any other widget could be written in a bunch of lines
of code.

As I said to Luis, I'm not advocating the removal of the "recently used"
menu: I'm saying that it could not be the best idea on the UI side;
nevertheless, implementing a menu should be possible - and giving a
default menu (deriving directly from GtkMenu, so that it could be
extended painlessly) widget should be the right thing to do.

Kind regards,
 Emmanuele.

-- 
Emmanuele Bassi <[EMAIL PROTECTED]>
Web site: http://log.emmanuelebassi.net

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Luis Villa]

On 6/4/05, Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
> I was just saying that a menu, even if commonly used, might not be the
> best way to convey the needed informations.

That's fair. Like you say, things are often poorly named, etc., and we
should certainly try to think outside the box to solve these problems.
But you absolutely shouldn't dismiss the simple, common case and
overcomplicate it just because sometimes there are other problems.
Those problems are not as common as the core problem, and as others
have pointed out, there are much simpler ways to disambiguate.

[By the way, please don't let me discourage you- despite my
disagreements with the proposed UI design we *must* have the
infrastructure before any solution goes forward, and a good
infrastructure that covers your use cases will let us do a variety of
possible solutions and see what fits best.]

Luis
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Sven Neumann]

Hi,

Emmanuele Bassi <[EMAIL PROTECTED]> writes:

>> That's it. Very simple, very common. Currently, I can open one menu
>> (Places->Recent Documents) and 'solve' that user problem.
>
> What if you have more than one document with the same name?

The menu item should have a tooltip with the full filename.

> What if one is a copy you keep on a network share?

What's the problem?

> What if you want to open a document you edited some time ago (but not
> too long), and it went out of the menu?

The menu should feature an item at the bottom that allows the user to
open the GtkRecentChooserDialog that you suggested. That gives access
to not so recently used items w/o taking away the possibility to
access very recently used items as quickly as possible.


Sven
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Emmanuele Bassi]

Hi,

On Sat, 2005-06-04 at 08:43 +, DANIELLLANO wrote:

> > > That's it. Very simple, very common. Currently, I can open one menu
> > > (Places->Recent Documents) and 'solve' that user problem.
> >
> > What if you have more than one document with the same name?
> 
> That's a user problem. He shouldn't have more than one document with the
> same name.

Oh, yes:  this solves every problem.

We ship the new Gtk release, and we also ship a guy named Boris who will
beat the crap out of you if you call two files with the same name.

I'd say that's perfect.

> > What if one is a copy you keep on a network share?
> 
> What's the problem there?

That that network share might be read-only; or it might be not available
at the moment.  How do you know if that file is the right file you wish
to open?

> > What if you want to open a document you edited some time ago (but not
> > too long), and it went out of the menu?
> 
> Then it's not a Recent Document.

And if it is? Maybe it was opened an hour ago, and in the meantime
you've openend another fourteen documents just for taking a reference
from each one to put into that document.

Right now, the Recent Documents menu item is based on timestamp, but
clamped on the list' size; this is *very* sub-optimal.  We define the
list on a delta based on the frequency of save/open actions, instead of
the time passed - which is what "recent" means.

> > But users also don't save their documents with meaningful names;
> 
> That's their problem. Maybe
> http://developer.gnome.org/doc/API/2.0/gtk/GtkFileChooserDialog.html
> should have a quick help or tooltip on how to correctly name files, if
> you don't want to get mad later looking for them.

Maybe we should name the files ourselves, and get rid of the entry
altogether; this would solve every problem.

Please: are you seriously advocating that we put a tutorial in each
file-related dialog?

Kind regards,
 Emmanuele

-- 
Emmanuele Bassi <[EMAIL PROTECTED]>
Web site: http://log.emmanuelebassi.net

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[DANIELLLANO]

Emmanuele Bassi wrote:
> On Fri, 2005-06-03 at 10:14 -0400, Luis Villa wrote:
> > On 6/3/05, Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
> > > On Fri, 2005-06-03 at 03:46 +0400, Nickolay V. Shmyrev wrote:
> > > > Emmanuele, really the best way to provide access to recent items in
> > > > application is menu.
> > >
> > > Even if I could agree, I'm still skeptical about this.  A menu is what
> > > it is used on some platforms, but I don't know if it's indeed the best
> > > way to provide all the data we need to know about a recently used
> > > resource.
> >
> > You're thinking this way, I'd suggest, because your use cases are
> > overly complicated. Consider this ridiculously common use case:
> >
> > * I want to open a file that I know I saved in the recent past.
> >
> > That's it. Very simple, very common. Currently, I can open one menu
> > (Places->Recent Documents) and 'solve' that user problem.
>
> What if you have more than one document with the same name?

That's a user problem. He shouldn't have more than one document with the
same name.

> What if one is a copy you keep on a network share?

What's the problem there?

> What if you want to open a document you edited some time ago (but not
> too long), and it went out of the menu?

Then it's not a Recent Document.

> This is what happens now with the Places -> Recent Documents menu; the
> recently opened documents menu item in the applications File menu
> currently cuts down the list size, but it is limited to a bunch of items
> (some times the limit is customizable, but commonly is hardcoded) - and
> having a menu with fourty items (many of which don't say anything about
> their state/location/whatever) is a complete waste of the user's time.
>
> > Covering that use case is the whole point of every recent file menu on
> > every OS. People don't care what month it was opened, or what day it
> > was opened, they just know that they opened it in the recent past, and
> > they want to open it again without digging into crappy FS hierarchies.
>
> Exactly.
>
> But users also don't save their documents with meaningful names;

That's their problem. Maybe
http://developer.gnome.org/doc/API/2.0/gtk/GtkFileChooserDialog.html
should have a quick help or tooltip on how to correctly name files, if
you don't want to get mad later looking for them.

> sometimes they don't even look where they save their files - and this
> means that they have multiple copies around; they wish to get the file
> that they opened some time ago "surely not today, maybe yesterday or the
> day before"; users don't want to search - sometimes they don't even know
> how to search for a file.
>
> > Covering the more complex user problems is nice, but if you make it
> > too hard to solve this very basic need, you've defeated the point for
> > most users.
>
> I was just saying that a menu, even if commonly used, might not be the
> best way to convey the needed informations.


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Emmanuele Bassi]

Hi,

On Fri, 2005-06-03 at 10:14 -0400, Luis Villa wrote:
> On 6/3/05, Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
> > Hi,
> > 
> > On Fri, 2005-06-03 at 03:46 +0400, Nickolay V. Shmyrev wrote:
> > 

> > > Emmanuele, really the best way to provide access to recent items in
> > > application is menu.
> > 
> > Even if I could agree, I'm still skeptical about this.  A menu is what
> > it is used on some platforms, but I don't know if it's indeed the best
> > way to provide all the data we need to know about a recently used
> > resource.
> 
> You're thinking this way, I'd suggest, because your use cases are
> overly complicated. Consider this ridiculously common use case:
> 
> * I want to open a file that I know I saved in the recent past.
> 
> That's it. Very simple, very common. Currently, I can open one menu
> (Places->Recent Documents) and 'solve' that user problem.

What if you have more than one document with the same name?

What if one is a copy you keep on a network share?

What if you want to open a document you edited some time ago (but not
too long), and it went out of the menu?

This is what happens now with the Places -> Recent Documents menu; the
recently opened documents menu item in the applications File menu
currently cuts down the list size, but it is limited to a bunch of items
(some times the limit is customizable, but commonly is hardcoded) - and
having a menu with fourty items (many of which don't say anything about
their state/location/whatever) is a complete waste of the user's time.

> Covering that use case is the whole point of every recent file menu on
> every OS. People don't care what month it was opened, or what day it
> was opened, they just know that they opened it in the recent past, and
> they want to open it again without digging into crappy FS heirarchies.

Exactely.

But users also don't save their documents with meaningful names;
sometimes they don't even look where they save their files - and this
means that they have multiple copies around; they wish to get the file
that they opened some time ago "surely not today, maybe yesterday or the
day before"; users don't want to search - sometimes they don't even know
how to search for a file.

> Covering the more complex user problems is nice, but if you make it
> too hard to solve this very basic need, you've defeated the point for
> most users.

I was just saying that a menu, even if commonly used, might not be the
best way to convey the needed informations.


Kind regards,
 Emmanuele.

-- 
Emmanuele Bassi <[EMAIL PROTECTED]>
Web site: http://log.emmanuelebassi.net

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Luis Villa]

On 6/3/05, Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> On Fri, 2005-06-03 at 03:46 +0400, Nickolay V. Shmyrev wrote:
> 
> > > A menu would never give enough informations on the recently used
> > > items: apart from an icon associated to the mime type, we won't know
> > > their location, or when they were accessed; so, given that we should
> > > provide a tooltip for each item (with an API for adding custom text,
> > > maybe), a menu could be also implemented.
> > >
> >
> > Emmanuele, really the best way to provide access to recent items in
> > application is menu.
> 
> Even if I could agree, I'm still skeptical about this.  A menu is what
> it is used on some platforms, but I don't know if it's indeed the best
> way to provide all the data we need to know about a recently used
> resource.

You're thinking this way, I'd suggest, because your use cases are
overly complicated. Consider this ridiculously common use case:

* I want to open a file that I know I saved in the recent past.

That's it. Very simple, very common. Currently, I can open one menu
(Places->Recent Documents) and 'solve' that user problem.

Covering that use case is the whole point of every recent file menu on
every OS. People don't care what month it was opened, or what day it
was opened, they just know that they opened it in the recent past, and
they want to open it again without digging into crappy FS heirarchies.
Covering the more complex user problems is nice, but if you make it
too hard to solve this very basic need, you've defeated the point for
most users.

Luis




 
> Consider web browsing; Firefox, Epiphany, Internet Explorer - all show
> the history as a side pane containing a treeview, with each page that
> has been visited put it into a treeview.
> 
> What I am suggesting basically is creating the concept of a "resource
> history", showing what resources the user has recently openend; and if
> the panel registered the menu items it launches, we could also have the
> recently used applications, for instance.
> 
> >  The main idea of recent file is to allow open new
> > file without dialog, while you suggestion is to replace one complex
> > dialog (FileChooser) with another one (RecentChooser).
> 
> The idea is to offer a set of widgets - a dialog, a button, whatever -
> in order to access this data.
> 
> The GtkFileChooser could register an item in save mode, and show the
> recently used items in open mode, so we could scrap the entire "Open
> recent..." menu item altogether, and just use the "Open..." menuitem; it
> could be a viable solution.  But this does not mean that we should not
> provide some other way to access this data.
> 
> Kind regards,
>  Emmanuele.
> 
> 
> 
> --
> Emmanuele Bassi <[EMAIL PROTECTED]>
> Web site: http://log.emmanuelebassi.net
> 
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Emmanuele Bassi]

Hi,

On Fri, 2005-06-03 at 03:46 +0400, Nickolay V. Shmyrev wrote:

> > A menu would never give enough informations on the recently used
> > items: apart from an icon associated to the mime type, we won't know
> > their location, or when they were accessed; so, given that we should
> > provide a tooltip for each item (with an API for adding custom text,
> > maybe), a menu could be also implemented.
> > 
> 
> Emmanuele, really the best way to provide access to recent items in
> application is menu.

Even if I could agree, I'm still skeptical about this.  A menu is what
it is used on some platforms, but I don't know if it's indeed the best
way to provide all the data we need to know about a recently used
resource.

Consider web browsing; Firefox, Epiphany, Internet Explorer - all show
the history as a side pane containing a treeview, with each page that
has been visited put it into a treeview.

What I am suggesting basically is creating the concept of a "resource
history", showing what resources the user has recently openend; and if
the panel registered the menu items it launches, we could also have the
recently used applications, for instance.

>  The main idea of recent file is to allow open new
> file without dialog, while you suggestion is to replace one complex
> dialog (FileChooser) with another one (RecentChooser).

The idea is to offer a set of widgets - a dialog, a button, whatever -
in order to access this data.

The GtkFileChooser could register an item in save mode, and show the
recently used items in open mode, so we could scrap the entire "Open
recent..." menu item altogether, and just use the "Open..." menuitem; it
could be a viable solution.  But this does not mean that we should not
provide some other way to access this data.

Kind regards,
 Emmanuele.



-- 
Emmanuele Bassi <[EMAIL PROTECTED]>
Web site: http://log.emmanuelebassi.net

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Emmanuele Bassi]

Hi,

On Fri, 2005-06-03 at 01:34 +0200, Sven Neumann wrote:

> Hi,
> 
> Emmanuele Bassi <[EMAIL PROTECTED]> writes:
> 
> >> Sorry, but what are the latency reasons involved here?
> >
> > Parsing could be an issue on older machines - even if XML parsing has
> > become way more efficient.  What I was referring to was the check on
> > non-local items: this is currently what takes most of the time when
> > loading the recently used files with the recent-files code, for
> > instance.  We should keep this issue in mind: some of the files might
> > reside on non-local volumes.
> 
> I don't think that parsing the XML will be an issue and there are ways
> to work around the problem of non-local items. The file doesn't need
> to be touched in any way until the associated item is actually visible
> in the treeview. Stating the file and querying the MIME type could be
> done asynchronously from a thread.

The indication for the MIME type could be mandatory for recently used
items: if I'm writing an application, I should already know what MIME
type I'm using.  This would cut down the request for the MIME type.

As for non local items, we need a way to tell the user "hey, this item
is not on your system, so the information we are display could be
outdated"; as I said, an emblem could be useful - as we already show
network volumes.

Kind regards,
 Emmanuele.

-- 
Emmanuele Bassi <[EMAIL PROTECTED]>
Web site: http://log.emmanuelebassi.net

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Emmanuele Bassi]

Hi,

On Fri, 2005-06-03 at 03:46 +0400, Nickolay V. Shmyrev wrote:

> > A menu would never give enough informations on the recently used
> > items: apart from an icon associated to the mime type, we won't know
> > their location, or when they were accessed; so, given that we should
> > provide a tooltip for each item (with an API for adding custom text,
> > maybe), a menu could be also implemented.
> > 
> 
> Emmanuele, really the best way to provide access to recent items in
> application is menu. The main idea of recent file is to allow open new
> file without dialog, while you suggestion is to replace one complex
> dialog (FileChooser) with another one (RecentChooser).
> 
> But in panel menu, such dialog can be useful. What do you think about
> implementation of your proposal as panel applet?

The general idea was exactely to remove the "Recent Documents" item from
the Places menu, and create a ${WIDGET} showing all the recently used
resources; as to where to put this ${WIDGET}, Federico suggested
something like a drawer - and it would be easy to implement with a panel
applet.

Anyway, we need something inside Gtk-bar-some-library to handle those
recently used resources, for applications to register their data.  And a
widget (or a set of widgets) in order to maintain consistency.

Kind regards,
 Emmanuele.

-- 
Emmanuele Bassi <[EMAIL PROTECTED]>
Web site: http://log.emmanuelebassi.net

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Nickolay V. Shmyrev]

> > IMO providing a
> > menu is vital for this proposal to be accepted. Users like the
> > recently-used menu very much and I don't think we should take it away
> > and replace it with an inconvenient popup dialog.
> 
> A menu would never give enough informations on the recently used
> items: apart from an icon associated to the mime type, we won't know
> their location, or when they were accessed; so, given that we should
> provide a tooltip for each item (with an API for adding custom text,
> maybe), a menu could be also implemented.
> 

Emmanuele, really the best way to provide access to recent items in
application is menu. The main idea of recent file is to allow open new
file without dialog, while you suggestion is to replace one complex
dialog (FileChooser) with another one (RecentChooser).

But in panel menu, such dialog can be useful. What do you think about
implementation of your proposal as panel applet?

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Sven Neumann]

Hi,

Emmanuele Bassi <[EMAIL PROTECTED]> writes:

>> Sorry, but what are the latency reasons involved here?
>
> Parsing could be an issue on older machines - even if XML parsing has
> become way more efficient.  What I was referring to was the check on
> non-local items: this is currently what takes most of the time when
> loading the recently used files with the recent-files code, for
> instance.  We should keep this issue in mind: some of the files might
> reside on non-local volumes.

I don't think that parsing the XML will be an issue and there are ways
to work around the problem of non-local items. The file doesn't need
to be touched in any way until the associated item is actually visible
in the treeview. Stating the file and querying the MIME type could be
done asynchronously from a thread.


Sven
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Emmanuele Bassi]

On 6/2/05, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Emmanuele Bassi <[EMAIL PROTECTED]> writes:
> 
> > On the UI side, we should have a GtkRecentChooserDialog and a
> > GtkRecentChooserWidget, for which I have prepared a mockup at the GUADEC
> > Hackfest; you might see it here:
> >
> > http://www.emmanuelebassi.net/images/shots/recent-items-viewer.png
> 
> IMO this dialog is overloaded. There shouldn't be more than three
> lines of text displayed with each item. I also miss previews in your
> proposal. The GtkRecentChooser API should allow applications to
> provide a preview. That's exspecially important for images.

The mockup is a testbed: the MIME type line is redundant, and would be
removed; also, the "not available" emblem (coupled with a "is not
local" emblem) should be enough.

Also, a tooltip could be useful - but we would need the treeview tooltips.

I also agree on your point on the preview.
 
> > I've considered the option of making a menu, but I decided that we
> > should avoid it for latency reasons; applications might just have a
> > "Open recently used..." item which launches the dialog (many
> > applications already use a submenu, there's no difference for the user's
> > point of view), or we could add the ability to show recently used
> > resources into the GtkFileChooser, near where we put the bookmarks.
> 
> Sorry, but what are the latency reasons involved here?

Parsing could be an issue on older machines - even if XML parsing has
become way more efficient.  What I was referring to was the check on
non-local items: this is currently what takes most of the time when
loading the recently used files with the recent-files code, for
instance.  We should keep this issue in mind: some of the files might
reside on non-local volumes.

> IMO providing a
> menu is vital for this proposal to be accepted. Users like the
> recently-used menu very much and I don't think we should take it away
> and replace it with an inconvenient popup dialog.

A menu would never give enough informations on the recently used
items: apart from an icon associated to the mime type, we won't know
their location, or when they were accessed; so, given that we should
provide a tooltip for each item (with an API for adding custom text,
maybe), a menu could be also implemented.

Kind regards,
 Emmanuele.

-- 
It is against the grain of modern education to teach children to program.
What fun is there in making plans, acquiring discipline in organizing
thoughts, devoting attention to detail, and learning to be self-critical?
-- Alan Perlis
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Recently Used Files Proposal

[Sven Neumann]

Hi,

Emmanuele Bassi <[EMAIL PROTECTED]> writes:

> On the UI side, we should have a GtkRecentChooserDialog and a
> GtkRecentChooserWidget, for which I have prepared a mockup at the GUADEC
> Hackfest; you might see it here:
>
> http://www.emmanuelebassi.net/images/shots/recent-items-viewer.png

IMO this dialog is overloaded. There shouldn't be more than three
lines of text displayed with each item. I also miss previews in your
proposal. The GtkRecentChooser API should allow applications to
provide a preview. That's exspecially important for images.

> I've considered the option of making a menu, but I decided that we
> should avoid it for latency reasons; applications might just have a
> "Open recently used..." item which launches the dialog (many
> applications already use a submenu, there's no difference for the user's
> point of view), or we could add the ability to show recently used
> resources into the GtkFileChooser, near where we put the bookmarks.

Sorry, but what are the latency reasons involved here? IMO providing a
menu is vital for this proposal to be accepted. Users like the
recently-used menu very much and I don't think we should take it away
and replace it with an inconvenient popup dialog.


Sven
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list