View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008373 | Scribus | Graphics / Image Frames | public | 2009-08-23 01:07 | 2020-11-04 10:03 |
| Reporter | jghali | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | confirmed | Resolution | open | ||
| Platform | linux | OS | Fedora | OS Version | 10 |
| Product Version | 1.3.5 | ||||
| Target Version | 1.5.4 | ||||
| Summary | 0008373: After deleting page containing inline frame, frame remains in saved doc | ||||
| Description | [remaining frame part of issue 0008369] If I create a page with an inline image frame, and then delete the page, the frame remains in the .sla document with no apparent way to delete it. | ||||
| Steps To Reproduce | 1. Start scribus and create a new blank document. 2. Add a new page (page 2). 3. On page 2, insert an image frame with any old pdf image. 4. Also on page 2, insert a text frame. 5. Copy the image frame from step 3 and paste it in to the text frame as an inline image. 6. Delete the original image frame. 7. Save the document. The modified document still contains the FRAMEOBJECT item corresponding to the inline image, even though it is no longer referenced anywhere. | ||||
| Tags | inline | ||||
| Patch | |||||
|
|
Adding Franz to CC.. Franz, with your recent 1.5 work on inline text frames, do you think you can fix this in 1.4.1.svn without risk of destabilising inline frames |
|
|
I've already fixed that in 1.5.0svn for Drag'n'Drop of objects. These fixes can safely backported to 1.4.x without breaking anything. |
|
|
0011522 : same issue about PDF Effects between pages. |
|
|
Can recreate on OSX 10.8.5 1.5svn r19309 |
|
|
a/ no need to have a look at the .sla, the item is in the "inline items" window b/ currently, inline items are not deleted when a "surrounding" text frame is deleted (so, it's not deleted when a page is deleted, either) c/ since you can insert one single inline item in multiple text frames this behavior is coherent. but: d/ we probably should not have an "inline items" window e/ the inline items could be shown as sub items of a text frame in the outline window f/ it should not be possible to insert one single inline item in multiple text frames so, this bug should probably be closed... but i would welcome a feature request for the points d/ to f/ :-) |
|
|
I'm not sure for d) and f) f) depends how items behaviours relate to other scribus objects behaviours : notably scrapbook objects, symbols and one of the type of cezary's marks (that are text-bits that can be used in multiple places). When inline items could be inserted only in a single place, it would bring less versatility, less design options, but more UI and code simplicity (KISS way). d) depends on the status of inline objects. As long as they can be inlined into multiple frames, they are very independant objects, and as such it' probably usefull to have a dedicated window for them. Even if inline objects become very basic it could be usefull to list them and access to anyone, for maintenance sake (For example : At one point, if SLA gets too large, user might want to change some inline images into external files and will need to find/browse them) Beside, this window could propose other operations, like import / export inline items... As for c), it could evolve toward : c2) Garbage collector : as long as inline items can be inlined in multiple frames, they should only be deleted when their last insertion point is being deleted. When such a situation occurs, either the inline object is simply deleted, either the UI asks whether the item should be deleted or kept for future use. [edited] |
|
|
In 0016248 (closed as duplicate) i proposed that a warning should somehow be issued when an embeded object isnt used anymore : - with a dialog when removing the last embeded object's inserting point - with some red text or warning icon in the "Embeded objects" palette - in the preflight checker (as other out-of-page-image warnings) |
|
|
i repeat my self: what is the use of inserting the same inline item multiple times? imo this problem should simple not exist and is triggered by a feature nobody asked for and almost nobody uses (if somebody ever used it). really, if you want to reuse an item, we have symbols. we don't need a garbage collector or warnings in the verifier for inline items. we just need to strongly link the inline items with the only frame they are inserted in. |
|
|
@ale I dont use symbols or very rarely. I dont know how different they are to other items or tools (inlined items, symbols + clipboard album). This is not clear to me. Providing these different tools requires good UI and documenting + converting tools because user could want to convert inlined item into symbol or bring it into the clipboard album and the same for any of them to any other type (convert a clipboard album item into symbol usw). |
|
|
symbols = clipboard items with a link to the original. (you edit one, all change) inline items are items that are inside of a text frame. the "symbols" name is imo bad but one get used to it... |
|
|
It doesnt help discovering scribus to have so widely different namings for so closely related items, all the more when the tools are totaly different and not linked to each other. Clipboard items, inlined items and symbols are very much the same : parts of a document. Inlining an item is just a way to use it. Having it in a clipboard is just a way to share it amongst document Naming it a symbol is just a way to be able to propagate its changes to all its use places. The UI should better reflect this. |
|
|
no, inline items are not the same. even if they might be stored in a .sla in a similar way. they are simply non-text items that have been pasted inside of a text frame. or, at least, they should just be just that. no need at all to have an inline items dialog or even to have them as a name in scribus. scrapbook is imo a good name. symbols are badly named. symbols should probably just be scrapbook items and depending on the way you drop them into the document the link to the original is kept or not. there is probably no need for the name "symbols" to be shown in the UI. there should only be scrapbook items. it's the way you link them in the document that should make the difference, not the way you add them in the scrapbook. the clipboard is a completely different thing. even if the scrapbook can be seen as some sort of permanent clipboard. discovering that there can be a link between the two makes me sad. (really? who wants the clipboard to be automatically added to the scrapbook?) imo, not because something is technically similar, that it should be shown as the same thing to the user or provide the same features. and not because two things are (partially) implemented in a same way, that they should share parts of the UI. btw, you forgot patterns! really, scribus should start caring more about the way things are used and avoid leaking details about how things work behind the scene or are stored in a .sla. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-08-23 01:07 | jghali | New Issue | |
| 2009-08-23 01:07 | jghali | Issue generated from: 0008369 | |
| 2009-08-23 01:07 | jghali | Relationship added | related to 0008369 |
| 2009-08-23 01:10 | jghali | Summary | After deleting page containing inline frame, frame remains => After deleting page containing inline frame, frame remains in saved doc |
| 2009-08-23 01:10 | jghali | Description Updated | |
| 2009-08-23 01:10 | jghali | Steps to Reproduce Updated | |
| 2009-08-26 21:17 | jghali | Severity | crash => minor |
| 2009-10-04 22:15 | cbradney | Target Version | => 1.3.6 |
| 2010-01-06 23:22 | cbradney | Target Version | 1.3.6 => 1.3.7 |
| 2010-05-26 22:30 | cbradney | Target Version | 1.3.7 => 1.3.8 |
| 2010-07-17 20:51 | cbradney | Target Version | 1.3.8 => 1.3.9 |
| 2010-11-23 20:14 | cbradney | Target Version | 1.3.9 => 1.4.0 |
| 2011-04-16 10:02 | cbradney | Target Version | 1.4.0 => 1.4.1 |
| 2012-01-03 20:02 | cbradney | Note Added: 0027442 | |
| 2012-01-03 20:44 | fschmid | Note Added: 0027446 | |
| 2012-04-29 21:13 | cbradney | Target Version | 1.4.1 => 1.4.2 |
| 2013-01-13 21:32 | cbradney | Target Version | 1.4.2 => 1.4.3 |
| 2013-07-04 20:24 | cbradney | Target Version | 1.4.3 => 1.5.0 |
| 2013-07-12 17:38 | JLuc | Note Added: 0030436 | |
| 2014-07-03 05:16 | Kunda | Note Added: 0032424 | |
| 2014-07-03 12:06 | ale | Note Added: 0032425 | |
| 2014-07-03 12:09 | Kunda | Note Edited: 0032424 | |
| 2014-07-03 12:55 | JLuc | Note Added: 0032429 | |
| 2014-07-03 12:57 | JLuc | Note Edited: 0032429 | |
| 2014-07-03 12:57 | JLuc | Note Edited: 0032429 | |
| 2014-07-03 12:59 | JLuc | Note Edited: 0032429 | |
| 2014-07-03 13:00 | JLuc | Note Edited: 0032429 | |
| 2014-07-03 14:16 | Kunda | Target Version | 1.5.0 => 1.5.1 |
| 2015-09-17 20:10 | Kunda | Category | Graphics / Image Frames => Graphics/Img Frames |
| 2015-09-17 20:11 | Kunda | Category | Graphics/Img Frames => Graphics / Image Frames |
| 2016-01-23 17:17 | cbradney | Target Version | 1.5.1 => 1.5.3 |
| 2016-05-12 12:53 | Kunda | Tag Attached: inline | |
| 2016-05-12 17:10 | Kunda | Status | new => confirmed |
| 2016-12-08 22:04 | Kunda | Target Version | 1.5.3 => 1.5.4 |
| 2020-09-24 00:16 | jghali | Relationship added | has duplicate 0016248 |
| 2020-09-24 05:03 | JLuc | Note Added: 0048093 | |
| 2020-09-24 05:04 | JLuc | Note Edited: 0048093 | |
| 2020-09-24 06:08 | JLuc | Note Edited: 0048093 | |
| 2020-09-24 06:35 | ale | Note Edited: 0032425 | |
| 2020-09-24 06:41 | ale | Note Added: 0048094 | |
| 2020-09-24 07:59 | JLuc | Note Added: 0048096 | |
| 2020-09-24 10:17 | ale | Note Added: 0048098 | |
| 2020-09-25 16:22 | JLuc | Note Added: 0048102 | |
| 2020-09-28 08:58 | ale | Note Added: 0048109 | |
| 2020-11-04 10:03 | ale | Relationship added | related to 0016313 |
