|
|
Confirmed on r19483 |
|
|
no can not create the object on the same name |
|
|
aliyousuf, what OS plaform, Scribus version, and Scribus revision did you test this on ? |
|
|
aliyousuf, I see 2 identical names in the Outline window. See screenshot OSX 10.10.5 1.5.1svn r20478 |
|
|
2-objects-w-same-name.png (19,186 bytes) |
|
|
I work on ubuntu 14.04 and Scribus version Scribus Version 1.5.1.svn 09 October 2015 Build ID: C-C-T-F-C1.13.1-64bit Using Ghostscript version 9.10 |
|
|
aliyousuf, how are you building Scribus ? from source? PPA ? |
|
|
please see the image that i attach it is same problem or not it cannot accept the same name of other object please explain if you mean some thing else |
|
|
Dawood, Doesn't look like you are following the step to reproduce. Did you do these steps? 1. Open a new document 2. Create a text frame. The default name is “Text1”. Change this name to “Text2”. 3. Create another text frame. Result: Scribus will name this text frame also “Text2”. Edit: see 1st screenshot showing this result |
|
|
thank you kunda I produce the bug I will try to see the problem also it is not in windows only I produce it in win and Ubuntu |
|
|
hello I found the problem of assigning default name of any new object The responsible for this is a Variable called AnName which is located in PageItem. This variable is Qstring value generated with merging the type of object and the number of items created in this document. what I add is a loop to check the name if it is exist or not and will change the name I test The Patch and its work fine with me so I hope you confirm its working or not. |
|
|
dublicateName.diff (567 bytes) |
|
|
more information about AnName its a protected variable but it have a getter called itemName() this variable will be initialized and generated in the constructor of pageitem.cpp |
|
|
up to test |
|
|
Patch works with r20542 Cannot reproduce duplicate textbox/img/randompolygon/arc etc... |
|
|
Devs, please review patch |
|
|
kunda : I attached the "patch-tested-ok" tag because you said "patch works". I hope you mean that you tested it and it fixes the issues. When not, then please delete the tag. |
|
|
Yes, patch tested and it works. Thanks Jluc |
|
|
jghali, would this patch create a slow-down issue? |
|
|
somehow, i keep on having the feeling that the names that scribus uses internally should not be exposed through the UI. by default frames should not have a visible name. if somebody wants to define one, she should be free to do so. but scribus should not have problems if somebody uses the same name twice. of course, having the same name in the UI and in the SLA helps those few people who are manually editing sla files, but we have had multiple bugs (even some long standing ones!) that are related to the naming of resources in scribus (most of the time in relationship with translation). so, in my eyes, the real solution should very different :-) that being said, the patch is not brilliant but looks ok and the performance hit is probably not noticeable in most cases. a way to improve the performance could be to keep a document parameter saying if any frame of this type (or any frame at all) has ever had its name changed. most people never change the names and when importing complex vector shapes, the check could start having an impact on the performance. |
|
|
Three points here: 1. Why is this patch not yet in svn? So I have made useless fixing and reporting work again. 2. For bigger python projects names of objects are very valuable. In contrast to numeric IDs you can assign static attributes to objects using names. (For example non-printed "GlobalSettings_textframe" when the scripts are to read some first settings.) Of course for fast access some kind of numeric IDs make sense. 3. The line "uniqueNr = m_Doc->TotalItems;" may create numbers which aren't unique if you delete some other object, am I right? I guess the one number which is unique is the memory address of every PageItem. |
|
|
1. Basically no developer paid attention to his issue until now. I've committed a more complete version of the proposed patch by also modifying the copy constructor. 3. TotalItems represent the number of items created during an editing session. That numbers never goes down. So if you delete an object, this variable does not change. So it's perfectly fine to use TotalItems to generate PageItem's uniqueNr. |
|
|
>> somehow, i keep on having the feeling that the names that scribus uses internally should not be exposed through the UI @ale, names are necessary for dialogs such as Outline window and features such as PDF forms. If we remove names completely, we have to remove both. |
|
|
@u ltd thank you for your efforts. it takes time for patches to be reviewed. Scribus core crew is verrrrry small ! Please keep on cooperation, answer requests, improve patches when required. Write on lists or come on IRC in the evening and try talking to jghali or MrB - might help sometime. @jghali it could be u ltd refers to other patches he has also proposed : As for naming issues he proposed 0015133 And for other not related issues : - 0015030 Python 3 scripter update - 0015131 Add fast & precise duplicate to core+scripter - 0015028 Symlinked plugins are not loaded |
|
|
@jghali: there should be names that are internally used, untranslatable, not visible for the user *and* unique! this is valid for all resources like the colors and the frame names. and then there can be names that are visible to the user. they can be translatable, scribus might try to keep them unique, but issues with the names that are visible (and editable) should not lead to issues in the way scribus works. in the case of the frames: by default the frame would not have any visible name. but the user can define one if they need, as an example for scripting. the outline could show the first few letters in text frame and the filename in the images... the type of shape for shapes and so on... that would be even be more useful that what is shown now. (on the other side, removing pdf forms would be a great idea! but that's a different topic) |
- Anonymous
