View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010082 | Scribus | User Interface | public | 2011-06-30 14:56 | 2012-04-29 10:59 |
| Reporter | pygmee | Assigned To | cbradney | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | Linux | OS | Debian | OS Version | Lenny |
| Product Version | 1.4.0svn | ||||
| Target Version | 1.4.1 | Fixed in Version | 1.4.1.svn | ||
| Summary | 0010082: Pattern must have a unique name | ||||
| Description | The 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" | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
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... |
|
|
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. |
|
|
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. |
|
|
Ok, This could be a good candidate to fix shortly after 1.4.0 final release. |
|
|
Franz, can you please now fix this in the Version14x tree , now that 1.4.0 is out? Thanks |
|
|
Pygmee.. whats your suggestion here? |
|
|
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) |
|
|
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. |
| 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 |
|
Note Added: 0026517 | |
| 2011-07-02 22:06 |
|
Assigned To | => fschmid |
| 2011-07-02 22:06 |
|
Status | new => assigned |
| 2011-07-02 22:06 |
|
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 |
