View Issue Details

IDProjectCategoryView StatusLast Update
0012044ScribusStory Editor / Text Framespublic2014-04-21 14:54
ReporterJLuc Assigned Tojghali  
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.5.0svn 
Fixed in Version1.5.0svn 
Summary0012044: 2 frames are linked to same frame
Description- i had a chain of linked text frames D E F G etc
- i wanted to make frame F out of the chain
- i linked the previous frame E to the folowing one G using the link tool
- Scribus asked something i could not understand ; about, i guess, a conflict
it asked whether i wanted to insert some text (dunno which one) before or after (dunno which one neither)
- i answered to my best guess (i dont remember what)

it led to a situation where 2 frames D and F are linked toward the E frame...
It appears F wins the feeding match, but inserting text in D makes the text in E scroll too...

See uploaded screen (not a display refresh issue)
test uploaded sla
TagsNo tags attached.
Patch

Activities

JLuc

2014-02-05 22:27

developer  

dualfeed linked frame.png (214,380 bytes)   
dualfeed linked frame.png (214,380 bytes)   

JLuc

2014-02-05 22:28

developer  

JLuc

2014-02-07 19:01

developer   ~0031281

As a consequence there are 2 requests

- make the popup message explicit and clear as what is the issue and as what are the 2 proposed options.

- avoid to create that "2 different frames are feeding the same linked frame" awkward situation

JLuc

2014-02-13 20:57

developer   ~0031305

Last edited: 2014-02-13 20:59

Ok Jean, i test the fix and I think there still is an issue... or 3.

Rq: It requires that E is NOT linked to F or to any other frame so as to be able to use the chain tool.

I understand now what happens now with this message. As the message says scribus believes 'im "trying to insert a frame into an existing text chain". But this is not what i'm trying to do, and this is NOT the usual action performed with the chain tool.

In all other situations, the chain tool makes the text (of the currently selected frame : E ) flow toward the clicked frame : G.

usual behaviour : choose which frame the texts overflows to.
this special behaviour : loose content text and insert frame in chain
Why should it be totally different in such a situation ?

It would be a bit complex UI but possible and sometime usefull to have that new 'inserting' behaviour only in case the frame being linked (E) is empty, but it should NOT be the case when this frame E is not empty, because this new behaviour *looses* this text content (or at least a strong warning should be issued : 'If you choose to insert before or after, the text of the inserted frame will be lost. If you dont want to loose this text, cancel !')

If you want a complex management of such situation, chain tool might propose, if could-be inserted frame is not empty :
- do you want to empty frame and insert it Before / After destination frame ?
- do you want to cut destination chain before destination frame and chain it as usual ?

BESIDE, there are 2 MORE ISSUES :

1) if the chain tool is used toward a frame that is not empty, no warning is issued, and the text is lost.

2) when no frame is selected first, if i select a frame with existing nextInChain, as E, the 'chain' tool is not available : that's ok, because its allready linked.
BUT when i select a frame not in a chain, or last in a chain, it has no nextInChain, the chain tool becomes active, and if I THEN select a frame in the middle of a chain, with an existing nextInChain, the 'chain' tool keeps being active, when it should become greyed.
(when i use this falsely enabled button, an error message is displayed afterward. Maybe this message becomes useless in case the button is corrrectly greyed when needed)

jghali

2014-02-13 22:42

administrator   ~0031306

>> Why should it be totally different in such a situation ?

Because in all cases, this situations requires breaking a text chain. The operations hence become equivalent to inserting a frame in a text chain. As the first frame in chain owns the text content (and this is not specific to Scribus), inserting an already linked frame into another chain will of course make it display the text of that other text chain. The text previously displayed is still available in the original text chain. If you want to unlink and cut text, you have an appropriate command for that in "Object" menu.

1) if the chain tool is used toward a frame that is not empty, no warning is issued, and the text is lost.

No text is lost. See above. There is a special case when the last frame of a text chain is linked to the first frame of another chain : in this case the content of the second chain is appended to first chain.

2) fixed

JLuc

2014-02-13 23:29

developer   ~0031307

Last edited: 2014-02-15 16:04

I'm not sure i/you understand what you/i wrote. I dont agree with "The operations hence become equivalent to inserting a frame in a text chain." This is what scribus does now, but it is not what i want to achieve.

What scribus does : break origin chain and insert single frame in destination chain.
What could be done instead : preserve origin chain and break destination chain so as to link origin frame (= end of origin chain) toward second part of destination chain, starting on clicked frame. I feel this would be the usual (and hence : expected) behaviour of chain tool in such situation.

PS : fine if no text is not lost.

JLuc

2014-02-14 08:29

developer   ~0031308

The new 'insert' behaviour is usefull too. So it could be reserved to a keyboard variation of the tool.
- a simple CLICK as usual would trigger the usual behaviour, that is : chain origin selected frame toward clicked frame and its following frames (and doing so would require to break the destination chain before the clicked frame)
- a CTRL CLICK or a SHIFT CLICK would trigger the new 'insert' behaviour

JLuc

2014-02-14 13:14

developer   ~0031309

Last edited: 2014-02-15 18:01

When chaining a frame A to a frame B in usual situations, the frame A is allways linked BEFORE the frame B - in simple cases. Issue is in when the frame B is allready part of a chain.

NEW PROP :
Here is a new simple proposition : in such cases, proposition is to keep "A is linked before B" behaviour rule, as when simple. This eliminates the "After" option.
Then, the only question is whether :

- option 1 : Should Scribus break B's chain so as to link A (and A's potential chain of frames being linked before A) to B (and to potential frames being linked after B) ? this is the closest to usual behaviour, and it's easy to understand for the user.

or

- option 2 : Should Scribus insert A before B in B's chain ?
That would grant the (unusual but sometime usefull) behaviour that happens now in such a case.

In this 'new prop', the question to ask would be :
"You are trying to link a frame to a destination frame that is allready part of a chain. Do you want to break that destination chain so as to achieve the link ? Or do you want to insert the frame into the destination chain ?"
And the buttons would be :
- link
- insert
- cancel

In case the originating frame is part of a chain, the message could smartly be adapted (uppercase addition) to : "You are trying to link a LINKED frame to a destination frame that is allready part of a chain. Do you want to break that destination chain so as to achieve the link ? Or do you want to BREAK THE ORIGIN CHAIN AND insert the frame into the destination chain ?"

That keeps it clear and simple and consistant with usual behaviour.

That's it.
==========

Additionnal note leading to NEW PROP - MORE COMPLEX VERSION :

in option 2, we could consider the special case when A is the last part of a chain. 2 behaviours are possible in such a case :
- break A's chain and just insert A frame in B's chain, as is done now,
- or insert whole A's chain into B's chain.
Hence, it would be possible to have another option available in in case the origin A frame is part of a chain.
In such a case, the question would be :
- "You are trying to link THE LAST FRAME OF A CHAIN to a destination frame that is allready part of a chain. Do you want to break that destination chain so as to achieve the link ? Or do you want to insert the WHOLE ORIGIN CHAIN, OR JUST ITS LAST FRAME, into the destination chain ?"
And the buttons would be :
- link
- insert frame
- insert chain
- cancel

I'm not sure this 'new prop more complex version' is really usefull.

Issue History

Date Modified Username Field Change
2014-02-05 22:27 JLuc New Issue
2014-02-05 22:27 JLuc File Added: dualfeed linked frame.png
2014-02-05 22:28 JLuc File Added: dualfeed linked frame.sla
2014-02-07 19:01 JLuc Note Added: 0031281
2014-02-12 21:53 jghali Status new => resolved
2014-02-12 21:53 jghali Fixed in Version => 1.5.0svn
2014-02-12 21:53 jghali Resolution open => fixed
2014-02-12 21:53 jghali Assigned To => jghali
2014-02-13 20:57 JLuc Note Added: 0031305
2014-02-13 20:59 JLuc Note Edited: 0031305
2014-02-13 22:42 jghali Note Added: 0031306
2014-02-13 23:29 JLuc Note Added: 0031307
2014-02-14 08:29 JLuc Note Added: 0031308
2014-02-14 13:14 JLuc Note Added: 0031309
2014-02-14 13:15 JLuc Note Edited: 0031309
2014-02-14 13:16 JLuc Note Edited: 0031309
2014-02-14 22:18 JLuc Note Edited: 0031309
2014-02-14 22:19 JLuc Note Edited: 0031309
2014-02-15 16:04 JLuc Note Edited: 0031307
2014-02-15 17:59 JLuc Note Edited: 0031309
2014-02-15 18:00 JLuc Note Edited: 0031309
2014-02-15 18:01 JLuc Note Edited: 0031309
2014-04-21 14:54 cbradney Status resolved => closed
2015-09-17 20:08 Kunda Category Story Editor / Text Frames => Story Ed/Txt Frames
2015-09-17 20:12 Kunda Category Story Ed/Txt Frames => Story Editor / Text Frames