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 361633 - Save Articles dialog does not remember Priority
Save Articles dialog does not remember Priority
Status: RESOLVED DUPLICATE of bug 395475
Product: Pan
Classification: Other
Component: general
pre-1.0 betas
Other Linux
: Normal normal
: 1.0
Assigned To: Charles Kerr
Pan QA Team
Depends on:
Blocks:
 
 
Reported: 2006-10-12 07:17 UTC by Adrian Yee
Modified: 2007-01-16 16:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Adrian Yee 2006-10-12 07:17:33 UTC
For bug 350530, you changed it so that it remembered the Path setting, and for bug 361389, the patch remembers the Save Text and Save Attachments setting.  Only thing left is the Priority setting.
Comment 1 Charles Kerr 2006-10-18 18:22:30 UTC
I'm not sure it makes sense to remember this -- just because you add
something to the top of the list one time doesn't mean you want to
add everything to the top of the list.
Comment 2 Adrian Yee 2006-10-19 07:02:55 UTC
It makes sense if you don't use the default of Add to queue sorted by age (I prefer to add things to the back of the queue).
Comment 3 Charles Kerr 2006-10-19 20:52:37 UTC
Hm, that's valid.  Maybe there could be a default save position
in the preferences dialog... or maybe the save dialog could just
remember the setting if it's either 'back' or 'age'.
Comment 4 Christophe Lambin 2006-10-19 21:25:50 UTC
alternatively, the save dialog could have a checkbox stating 'remember this setting'.
Comment 5 Adrian Yee 2006-10-22 21:18:48 UTC
The remember this setting would work.  It should also probably apply to the Files setting as well, since I've accidentally saved as text instead of files a few times after it remembered my previous setting.
Comment 6 Charles Kerr 2007-01-16 16:38:38 UTC
fixed in svn.

*** This bug has been marked as a duplicate of 395475 ***