After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 357398 - Remeber last import settings (and folder)
Remeber last import settings (and folder)
Status: RESOLVED WONTFIX
Product: f-spot
Classification: Other
Component: General
CVS
Other Windows
: Normal enhancement
: ---
Assigned To: F-spot maintainers
F-spot maintainers
gnome[unmaintained]
: 364915 379895 415608 541770 552348 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-09-24 00:36 UTC by Bengt Thuree
Modified: 2018-07-12 00:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to remember state of the checkboxes (2.21 KB, patch)
2007-03-07 14:12 UTC, Patrick Wagstrom
needs-work Details | Review
enhanced patch that remembers the issue by media (3.91 KB, patch)
2007-03-12 19:48 UTC, Patrick Wagstrom
needs-work Details | Review

Description Bengt Thuree 2006-09-24 00:36:37 UTC
The import dialog should remember the last Import File folder, and use this as default for next import session.

This is moved out from bug #338412, and put in its own bug due to a bit more complicated.
Comment 1 Bengt Thuree 2006-09-24 01:43:39 UTC
The reason it was a bit complicated, is that the Import Gui reads the whole subdirectory structure and tries to present thumbnails when the Choose Folder window is started up.
Disabling this, causes some extra problems...

I seem also to recall that the Import structure would be re-written. 
Comment 2 Stephane Delcroix 2006-11-27 20:37:36 UTC
*** Bug 379895 has been marked as a duplicate of this bug. ***
Comment 3 Stephane Delcroix 2006-11-27 20:44:27 UTC
*** Bug 364915 has been marked as a duplicate of this bug. ***
Comment 4 Stephane Delcroix 2006-11-27 20:45:16 UTC
bug 364915 was also about keeping the other import options (copy, ...)
Comment 5 Thomas Van Machelen 2007-03-07 08:23:00 UTC
*** Bug 415608 has been marked as a duplicate of this bug. ***
Comment 6 Thomas Van Machelen 2007-03-07 08:24:28 UTC
changing title to reflect enhancement a bit better.
Comment 7 Patrick Wagstrom 2007-03-07 14:12:23 UTC
Created attachment 84168 [details] [review]
patch to remember state of the checkboxes

here's the patch to implement this feature.
Comment 8 Thomas Van Machelen 2007-03-07 14:17:35 UTC
Patrick(In reply to comment #7)
> Created an attachment (id=84168) [edit]
> patch to remember state of the checkboxes
> 
> here's the patch to implement this feature.
> 

Could you also consider the comment made by Larry?
http://bugzilla.gnome.org/show_bug.cgi?id=364915#c1
Comment 9 Patrick Wagstrom 2007-03-07 14:36:12 UTC
> Could you also consider the comment made by Larry?
> http://bugzilla.gnome.org/show_bug.cgi?id=364915#c1

I'm not certain that's the correct way to do it.  Although conceptually it makes sense, it introduces some user interface problems.  Consider the following scenario:

Joe doesn't like having his photos copied over and on his normal import source he has the checkbox unchecked.

Joe gets a new device, but still does not want the photos copied over.  However, the default, as per the glade file, is to have the copy option on.  So the script checks the checkbox.

Joe, being a normal user, doesn't think that changing a menu item should change checkboxes, so he clicks import for the new device and his files are still copied because now the checkbox is checked.


Of course, this is a silly example, but it illustrates the side-effect of having it set per device in the current scheme -- namely that changing the value of source_option_menu will also change the value of copy_check and recurse_check -- which is not what a user would expect.  As a user, I would expect that my options would remain constant.

I'll see about implementing some of the logic for your suggestion into the patch today, and then we'll let the community decide.  While I like the logic of Larry's comment, I'm not sure it can function properly with the current structure of the import dialog. 

Comment 10 Patrick Wagstrom 2007-03-12 19:48:56 UTC
Created attachment 84443 [details] [review]
enhanced patch that remembers the issue by media

I've gone through and implemented this with an alternate strategy that addresses Larry's issues (http://bugzilla.gnome.org/show_bug.cgi?id=364915#c1) about the media types.  I'll leave it up to everyone else to decide which method is better.

This new patch still has the global settings, which are used by default when you start to import photos or go to a new media device. However, if you change the settings for a media device, that setting will be remembered for that device.

In reality this patch may completely obsolete my old patch, but the functionality is a little different and may cause issues for some users.  I still have a preference for the original patch, however, I'm not opposed to this one, as I always have recursive and copy photos checked off, thus there is no difference in execution to me.
Comment 11 Stephane Delcroix 2007-07-28 09:00:50 UTC
that start smelling good...

some remarks... 
- using the ImportPath as gconf key path as-is will creates a lot of subkeys... I'd prefer an escaped (e.g. replacing '/' by '_') or an hashed (that's my preferred option) ImportPath instead...
- no longer compile with rubenv's latest changes to Preferences, but the missing Get () method could be re-added
- try to follow the HACKING conventions (casing, spacing)
Comment 12 Maxxer 2008-09-15 13:51:07 UTC
*** Bug 552348 has been marked as a duplicate of this bug. ***
Comment 13 Maxxer 2008-09-15 13:53:28 UTC
sorry, I have seen the description had been changed already
Comment 14 Stephane Delcroix 2008-09-15 14:34:49 UTC
*** Bug 541770 has been marked as a duplicate of this bug. ***
Comment 15 Ruben Vermeersch 2010-06-24 14:45:12 UTC
Comment on attachment 84168 [details] [review]
patch to remember state of the checkboxes

Maintenance update: In the past we've been less than stellar in reviewing patches. As such we have a pile of patches in bugzilla which are outdated and don't apply anymore. Am currently marking all of these as "needs-work". My apologies for this.

Since I've become a maintainer of the project, I've set the personal rule of quickly reviewing all patches, to avoid that this happens again. If you (or anyone) wants to go through the trouble of updating this patch, please talk to us to figure out if it fits in the F-Spot long term roadmap.

Should you, in the future, notice a patch lingering around for too long, please notify us immediately and we'll look into it, to avoid situations like these from happening again.

You can filter these mails by searching for ###F-OLDPATCHCLEANUP###
Comment 16 Ruben Vermeersch 2010-06-24 14:45:16 UTC
Comment on attachment 84443 [details] [review]
enhanced patch that remembers the issue by media

Maintenance update: In the past we've been less than stellar in reviewing patches. As such we have a pile of patches in bugzilla which are outdated and don't apply anymore. Am currently marking all of these as "needs-work". My apologies for this.

Since I've become a maintainer of the project, I've set the personal rule of quickly reviewing all patches, to avoid that this happens again. If you (or anyone) wants to go through the trouble of updating this patch, please talk to us to figure out if it fits in the F-Spot long term roadmap.

Should you, in the future, notice a patch lingering around for too long, please notify us immediately and we'll look into it, to avoid situations like these from happening again.

You can filter these mails by searching for ###F-OLDPATCHCLEANUP###
Comment 17 André Klapper 2018-07-12 00:07:51 UTC
F-Spot has moved to https://github.com/f-spot/f-spot/issues

If this Bugzilla ticket is still valid in a recent version of F-Spot, please feel free to post this topic as a ticket in the F-Spot project on GitHub.

Closing this report as WONTFIX as part of Bugzilla Housekeeping as we are planning to shut down GNOME Bugzilla in favor of GNOME Gitlab.