[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk-devel
Subject:    Re: file chooser and recently used dirs
From:       Yevgen Muntyan <muntyan () tamu ! edu>
Date:       2007-10-04 23:16:51
Message-ID: 47057463.9060202 () tamu ! edu
[Download RAW message or body]

Emmanuele Bassi wrote:
> On Thu, 2007-10-04 at 15:20 -0500, Yevgen Muntyan wrote:
>
>   
>>> if an application registers a directory inside the recently used
>>> resources list, it will also appear inside the Recently Used shortcut of
>>> the file chooser.
>>>       
>> It'd be bad. "Recent places" is a totally different thing from "Recent
>> files". You don't want to see all the folders with all the files you opened,
>> you want them separate in some way.
>>     
>
> I did not phrase that right. 

I guess that was the problem. I took it as "applications should
register directories in order to get that functionality", e.g.
gedit would register directories to get them in the list along
with text files. Which would suck. Sorry for misunderstanding.

> if an application registers a location with
> the directory MIME type then it will be presented in the recently used
> list like a directory (and sorted first, to offer the least difference
> path between browse, search and recently used modes); obviously, it only
> makes sense for applications that deal with directories. for instance,
> giggle (the git repository viewer) opens repositories, not files, so it
> saves the recently used directories - which makes complete sense for
> that kind of application. that's why the entire "recent files" machinery
> should really (and it is, at least by me and by the documentation that I
> wrote) be called "recently used resources": it stores a URI+MIME
> type(+additional metadata) tuple, and not just files.
>
>   
>> Recent files list may be abused, you can put folders in there (totally
>> ridiculous, by the way), but it's just that - abusing recent files list.
>> Inconvenient and ugly.
>>     
>
> it's not, and if you think about the different use cases per application
> you'll realise that as well. it really depends on what the application
> is opening/saving: either a file or a directory.
>   

Totally agree here. If an application deals with directories,
if it presents directories in the Open dialog, then it's totally
natural and right to have directories in the recent stuff list.

But, it's unrelated to the discussed issue: recent directories
in a dialog for choosing files or filenames.

> +++
>
> and, for the record (and I said so in the bug linked), I don't think
> that saving the recently used folders should be implemented, unless the
> application is already doing it for its own purpose or metaphor. if an
> application is dealing with files, then the directory is of no
> consequence: it can be recovered both by selecting a recently used
> resource in the same path and then changing the actual file name to use,
>   

No. For starters, selecting a recent file should open the file. Next,
it's just an inconvenient workaround - going into a directory is
not and should not be achieved by selecting a file. It's just completely
different things!
An example: I save screenshots to a remote dir over ssh, to desktop,
and to /tmp. That remote dir is the web site directory, I save stuff
(not only screenshots) to there all the time. No way I am going to
select a recent png file (which won't be even present in the text editor
list, if I understand it right) to save a text file. And naturally there
is no fancy metaphor or whatever, it's just some few dirs I use.

> or shortcuts can be used to achieve the same effects.

How many shortcuts? The shortcut panel contains ten bookmarks
here (apart from the default three). All of them bound. That's just
not enough. It's like bookmarking files as a replacement for recent
files list. Could work, but would suck too.


>  personally, saving
> the directories where a resource has been last opened/saved is a waste.
>   

If it were limited (ten, twenty, not hundreds or unlimited), it wouldn't
be a waste.

All in all, there are two points of view: recent dirs list is a nice 
feature,
or it's not a nice feature. I think it's a very nice feature, very badly
needed. You think it's a waste. Both points of view are fine.

But recent files list has nothing to do with it whatsoever. Having
recent files list does *not* make the issue disappear somehow. There
wasn't list of recent directories, and there isn't list of recent 
directories,
and there is no equivalent functionality.

>   
>>> there's a bug open for making the file chooser save the current
>>> directory when in SAVE and SELECT_FOLDER mode[1], but it's missing an
>>> implementation.
>>>       
>> Hopefully it won't break applications which already take care of that,
>> like the sizing stuff did.
>>     
>
> I completely fail to see the relation.
>   

Simple: it's all filechooser, chunk of code which nobody but Federico
understands completely. Here's a plausible scenario: one makes
filechooser go to the last used directory on map(). Breaks applications
which set the directory using some other logic.

Regards,
Yevgen

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]