Page 1 of 1
RC1: Batch rename: "Duplicate..." button
Posted: Wed Jan 18, 2006 8:57 pm
by helmut
I find the "Duplicate..." button irritating. It sounds as if you could duplicate something, in fact you control the handling of name clashs. I think a better (=clearer) name for this button should be found.
XnView 1.82 <x>
An idea
Posted: Wed Jan 18, 2006 9:27 pm
by Clo
• Hi !
- Maybe “ManageNames” should be appropriate, alas, it's pretty long in English…
- Better in French (the same) : "GérerNoms" is a bit shorter…
- "NamenHandhaben" ? Long too…
G.
Claude
Clo
Posted: Wed Jan 18, 2006 9:34 pm
by marsh
"If duplicate"? There might not be a good name.
Posted: Wed Jan 18, 2006 9:35 pm
by helmut
Perhaps "Double names..." would be clearer. A bit longer but not too bad.
Posted: Wed Jan 18, 2006 10:38 pm
by ckv
helmut wrote:Perhaps "Double names..." would be clearer. A bit longer but not too bad.
"Double names..." or similar (Duplicate names...?) is good, but it's too long for current dialog design. Though there are space for bigger button.
Posted: Thu Jan 19, 2006 12:03 am
by Dreamer
I think there is no space for clearer name (esp. for all languages).
I suggest "Options". In the next version this option could be moved to "Options" window and Options button would open this category in options. Same as Options button in Batch convert dialog for formats.
Another advantage of this solution is that 'we' could add more less used options there in the future.
Posted: Thu Jan 19, 2006 8:49 am
by Xyzzy
Me and Olivier_G think that options that refer to feature with it's own distinct dialog should stay in this dialog (or subdialog). 'Options' dialog is for features that have no natural ability to handle their own options.
Following your way of thinking, why not put most of fe. Slide Show or Web page dialog in Options, leaving only a few fields that really change at every run?
BTW, Postponed, GUI freezed in RC.
X.
Posted: Thu Jan 19, 2006 6:54 pm
by Olivier_G
Xyzzy wrote:Me and Olivier_G think that options that refer to feature with it's own distinct dialog should stay in this dialog.
I confirm: I see no advantage in putting settings in the main Options window if they specifically belong to an existing dialog: it only increases clutter/complexity in the Options window.
Olivier
Posted: Fri Jan 20, 2006 12:33 am
by Dreamer
Olivier_G wrote:Xyzzy wrote:Me and Olivier_G think that options that refer to feature with it's own distinct dialog should stay in this dialog.
I confirm: I see no advantage in putting settings in the main Options window if they specifically belong to an existing dialog: it only increases clutter/complexity in the Options window.
Olivier
But normal user opens Options window just once or few times, I think "processing" dialogs should be more clear, they are more important, since user uses them every day.
We could use "advanced options mode" for Options.
And users could setup all settings at once, then just use clearer "processing" dialogs and - they still coould change these settings in these dialogs with Options button(s).
Posted: Fri Jan 20, 2006 8:42 am
by Xyzzy
Options can be added on Options button inside such dialog (as a sub-dialog). You get dialog clarity and uncluttered Options at the same time.
X.
Posted: Sat Jan 21, 2006 12:06 am
by Dreamer
Xyzzy wrote:Options can be added on Options button inside such dialog (as a sub-dialog). You get dialog clarity and uncluttered Options at the same time.
X.
Yes, but with my idea, I could setup all options at once and I don't need to setup several options later. And with another feature "Basic options mode" Options window will be still clear.
