View Issue Details

IDProjectCategoryView StatusLast Update
0010082ScribusUser Interfacepublic2012-04-29 10:59
Reporterpygmee Assigned Tocbradney  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionfixed 
PlatformLinuxOSDebianOS VersionLenny
Product Version1.4.0svn 
Target Version1.4.1Fixed in Version1.4.1.svn 
Summary0010082: Pattern must have a unique name
DescriptionThe user can define the name for his custom pattern. Unfortunately when trying to give a name taht already exists for a new pattern, there is no message : only the same valuedialog to give the name, without further information.

There should be a line added before the field like "this name already exists, please choose another one" or give an option to replace the existing pattern if the name is confirmed. "keep name similar to replace pattern"
TagsNo tags attached.
Patch

Activities

ale

2011-06-30 16:30

manager   ~0026501

wouldn't it be easier to add a number to the pattern if the name is already taken?

if i define again a pattern "stripes" i'll get "stripes_001" or the next "stripes_###" available.

when looking at the list of the patterns, the user will notice what happened and accept the naming or rename the pattern (and be more careful in the future).

otherwise, yes, we should take care that the names are unique...

pygmee

2011-07-01 12:23

developer   ~0026505

Incremental naming can be nice for really numerous resources (frames for example) but if we give the user the ability to name some of them, i think it's important he keeps the power on it.The trouble is that sometimes, you hae to make some tests on patterns to find the best, and it might be difficult to recognize them in the list. Having a real custom name can avoid user errors. Anyway, if choice is made to apply a incremental number, i guess the user should be warn of it, be it by a window or a sign in the list.

ale

2011-07-02 08:18

manager   ~0026506

hi pygmee!

i was not suggesting to generally switch to an automatic naming, but to add an incremental number if there is a conflict in the name (and the incremental number will be applied to the name you have chosen)

so, if you want to add a pattern named "stripes" but you already have one with that name you will get "stripes_001".

the user can always rename it further on...

this is imo the fastest way to deal with this problem, even for the user! (since what she wants is probably to index the patterns with the same name!)

no message where the user has to click "ok" should be needed.

plinnell

2011-07-02 22:06

viewer   ~0026517

Ok, This could be a good candidate to fix shortly after 1.4.0 final release.

cbradney

2012-01-03 20:25

administrator   ~0027444

Franz, can you please now fix this in the Version14x tree , now that 1.4.0 is out? Thanks

cbradney

2012-01-23 22:00

administrator   ~0027592

Pygmee.. whats your suggestion here?

pygmee

2012-01-24 09:41

developer   ~0027593

I see no other solution than :
- check when validating in the naming window and display an error message (for example in the naming field) if the name is duplicated
- Or change how it is done : do the naming in the the PP pattern list (ah sorry in the pattern window, but i don't like it so much and always forget it is there)

cbradney

2012-01-25 21:12

administrator   ~0027596

Backported the 1.5.0 code with a few cleanups. It won't let you save now without using an unused name. Further suggestions for name avoidance or other updates could be submitted in a new bug. Resolving this one.

Issue History

Date Modified Username Field Change
2011-06-30 14:56 pygmee New Issue
2011-06-30 16:30 ale Note Added: 0026501
2011-07-01 12:23 pygmee Note Added: 0026505
2011-07-02 08:18 ale Note Added: 0026506
2011-07-02 22:06 plinnell Note Added: 0026517
2011-07-02 22:06 plinnell Assigned To => fschmid
2011-07-02 22:06 plinnell Status new => assigned
2011-07-02 22:06 plinnell Target Version => 1.4.1
2012-01-03 20:25 cbradney Note Added: 0027444
2012-01-23 22:00 cbradney Note Added: 0027592
2012-01-24 09:41 pygmee Note Added: 0027593
2012-01-25 20:28 cbradney Assigned To fschmid => cbradney
2012-01-25 21:11 cbradney Status assigned => resolved
2012-01-25 21:11 cbradney Fixed in Version => 1.4.1.svn
2012-01-25 21:11 cbradney Resolution open => fixed
2012-01-25 21:12 cbradney Note Added: 0027596
2012-04-29 10:59 cbradney Status resolved => closed