View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0009944 | Scribus | Styles | public | 2011-04-20 08:30 | 2014-07-19 18:18 |
Reporter | ale | Assigned To | jghali | ||
Priority | normal | Severity | minor | Reproducibility | sometimes |
Status | closed | Resolution | fixed | ||
Product Version | 1.4.0svn | ||||
Fixed in Version | 1.5.0svn | ||||
Summary | 0009944: renaming an existing style scrambles the styles hierarchy | ||||
Description | after renaming a style, some existing styles are modified and defined as based on it. | ||||
Steps To Reproduce | create 3 styles based on no style: - abcd - defg - hijk - rename "hijk" to "blah blah" now "abcd" and "defg" are based on "blah blah" | ||||
Tags | #tobeclosed | ||||
Patch | |||||
related to | 0010457 | new | Imported Paragraph Styles loose their "based on" Properties (not character styles) | |
related to | 0011047 | closed | Creating a new paragraph style is creating a mess in the style hierarchy | |
related to | 0007946 | closed | jghali | style not cloned under right parent when cloning paragraph style |
has duplicate | 0011711 | closed | christoph_s | Adding new style in style manager breaks the style hierarchy |
|
|
|
it possibly has to do with the space in the renamed style... |
|
Unable to reproduce on OSX 10.6.6 and Windows |
|
it happens on AkhIL's computer with russian GUI (as shown in the screencast) and i could reproduce it on my computer with 1.4RC3 on debian testing... |
|
not all the time... |
|
Unable to reproduce this in 1.4.1.svn that ubuntu VM just installed, or my 1.4.2.svn on OSX. |
|
just happened! you may try a bit harder :-) (i've attached a screencast where i had to try very hard until it has happened. empty file, newly created on fresh 1.4 from svn) |
|
|
|
Those that have the bug need to find the bug :) |
|
i wanted to ask you if you can give me a hint, how to track it... personally, i would put a break point somewhere and try to understand from where it gets triggered... but what is a good place to set the break point? |
|
See void StyleManager::slotNameChanged(const QString& name) ... but that code runs for every rename you have done in your video.. and then it calls the style renames.. which has also run.. so there is something very specific triggering it. |
|
Also, what Qt are you running? |
|
qt 4.8.1 from debian testing... |
|
(related with http://bugs.scribus.net/view.php?id=10457) |
|
Related issue : http://bugs.scribus.net/view.php?id=11047 |
|
Related issue: http://bugs.scribus.net/view.php?id=7946 |
|
nathan reports that the scrambling may happen at the very moment the style name is blanked. he will add more details as soon as he can get an account for the bug tracker. |
|
To replicate this bug reliably, follow the instructions reported originally with one caveat: when renaming "hjkl" to "blah blah", delete "hjkl" leaving the name blank, then insert "blah blah". This links the styles even though 'Apply' has not been pressed. It appears that having the name blank, even for a moment, is the cause of this bug. This has been tested with 1.4.3 on Mac OS Mavericks (10.9.1) and on 1.5.0svn (8 December 2013) on Lubuntu 13.10. |
|
I confirm. AMOF It's as if not-based-on-another-style styles were based on a with-empty-name style. And all styles that are NOT based on any other style become "hooked" to the renamed style, as soon as the operator as emptied the name as a first step for renaming it. An existing test allready detects when the operator inputs an allready existing style and the message "choose a unique name for the style" is issued... and prevents also other styles based on the same-name style to be hooked to the being-renamed style. Another similar test would fix this bug : this test would detect when the operator empties the style name and warns too : "dont choose an empty name for the style" and prevent also other not-based-on-a-style styles to be hooked to the being-renamed style. |
|
It's in scribus/ui/stylemanager.cpp around line 994, function void StyleManager::slotNameChanged(const QString& name) After testing for allready existing names, there is (line 1011) : if (m_item) It should be replaced with if (m_item && !name.isEmpty()) |
|
if nobody sees any obvious bug introduced by jluc's patch, i think it should be applied (since it can avoid a full scrambling of the styles, which is very bad!) but i wonder if it would not be better to avoid updating the style name on change and prefer to update it on blur + apply/close. |
|
I've applied a patch for this empty name case. However it does not fix completely the issue. I still see weirds things happening when renaming successively several styles, especially when a style get renamed with the name of a previously deleted style. |
|
@jghali thanks for pushing patch. I have not been able to reproduce the issue you describe. |
|
Changing status to feedback because beside jluc we haven't heard back from jghali or ale about reproducing this bug. |
|
Changing status to resolved as I cannot reproduce the issue on 1.5.0.svn (19354). If someone can 100% confirm the fix it can be closed. |
|
Reminder sent to: ale Cannot reproduce on OSX 10.8.5 1.5.0svn r19352 Sending reminder to ale and if I could to Jluc (but he's not on the list) |
|
i could not reproduce it, no... |
Date Modified | Username | Field | Change |
---|---|---|---|
2011-04-20 08:30 | ale | New Issue | |
2011-04-20 08:30 | ale | File Added: scribus_bug.ogv | |
2011-04-20 08:31 | ale | Note Added: 0026114 | |
2011-04-20 11:34 | jghali | Note Added: 0026116 | |
2011-04-20 11:42 | ale | Note Added: 0026118 | |
2011-04-20 11:57 | ale | Reproducibility | always => sometimes |
2011-04-20 15:28 | ale | Note Added: 0026119 | |
2012-06-14 22:03 | cbradney | Note Added: 0028141 | |
2012-06-14 22:03 | cbradney | Status | new => resolved |
2012-06-14 22:03 | cbradney | Resolution | open => fixed |
2012-06-14 22:03 | cbradney | Assigned To | => cbradney |
2012-06-15 06:12 | ale | Note Added: 0028145 | |
2012-06-15 06:24 | ale | File Added: scribus_bug_9944.webm | |
2012-06-15 06:25 | ale | Note Edited: 0028145 | |
2012-06-15 06:25 | ale | Assigned To | cbradney => |
2012-06-15 06:25 | ale | Status | resolved => new |
2012-06-16 09:46 | cbradney | Note Added: 0028154 | |
2012-06-16 14:02 | ale | Note Added: 0028160 | |
2012-06-16 14:07 | cbradney | Note Added: 0028162 | |
2012-06-16 14:10 | cbradney | Note Edited: 0028162 | |
2012-06-16 14:10 | cbradney | Note Added: 0028163 | |
2012-06-18 05:51 | ale | Note Added: 0028176 | |
2012-06-20 08:12 | JLuc | Note Added: 0028227 | |
2012-06-20 09:08 | ale | Relationship added | related to 0010457 |
2012-08-24 13:26 | jegaudin | Note Added: 0028864 | |
2012-08-25 05:03 | ale | Relationship added | related to 0011047 |
2012-08-25 15:37 | Mike | Note Added: 0028869 | |
2012-08-25 21:30 | ale | Relationship added | related to 0007946 |
2013-09-02 20:18 | jghali | Relationship added | has duplicate 0011711 |
2013-12-21 13:16 | ale | Note Added: 0030936 | |
2013-12-21 15:43 | nasfarley88 | Note Added: 0030937 | |
2013-12-21 22:02 | JLuc | Note Added: 0030939 | |
2013-12-21 22:03 | JLuc | Note Edited: 0030939 | |
2013-12-28 21:37 | JLuc | Note Edited: 0030939 | |
2013-12-28 21:41 | JLuc | Note Edited: 0030939 | |
2013-12-28 22:21 | JLuc | Note Added: 0030960 | |
2013-12-28 22:21 | JLuc | Note Edited: 0030960 | |
2013-12-28 22:22 | JLuc | Note Edited: 0030960 | |
2013-12-29 22:33 | JLuc | Note Edited: 0030960 | |
2013-12-30 08:44 | ale | Note Added: 0030965 | |
2014-01-06 20:51 | jghali | Note Added: 0030987 | |
2014-01-10 09:22 | JLuc | Note Added: 0031011 | |
2014-02-23 19:36 | JLuc | Note Edited: 0031011 | |
2014-02-27 09:07 | JLuc | Tag Attached: #tobeclosed | |
2014-07-08 17:38 | Kunda | Note Added: 0032601 | |
2014-07-08 17:38 | Kunda | Status | new => feedback |
2014-07-19 04:02 | FirasH | Note Added: 0032828 | |
2014-07-19 04:02 | FirasH | Status | feedback => resolved |
2014-07-19 04:02 | FirasH | Assigned To | => FirasH |
2014-07-19 04:03 | FirasH | Assigned To | FirasH => |
2014-07-19 13:03 | Kunda | Note Added: 0032834 | |
2014-07-19 13:31 | ale | Note Added: 0032835 | |
2014-07-19 18:18 | FirasH | Status | resolved => closed |
2014-07-19 18:18 | FirasH | Assigned To | => jghali |
2014-07-19 18:18 | FirasH | Fixed in Version | => 1.5.0svn |