View Issue Details

IDProjectCategoryView StatusLast Update
0011623ScribusUsabilitypublic2020-09-06 19:18
ReporterJLuc Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
Status newResolutionreopened 
Product Version1.5.0svn 
Summary0011623: Snapping in 2 colums text frames
DescriptionAs is now, scribus snaps to the middle of the width of a text frame, even when its a 2 colums (or more) text frame.

In a multicolumns text frame, the snap should happen on the border of the gut / that is on each sides of each text column.
TagsNo tags attached.
PatchNo

Relationships

related to 0016233 closedale when snap to element is active, also snap to columns 
related to 0013597 new [Feature] Snap to same gap or size 

Activities

jghali

2013-06-23 13:53

administrator   ~0030328

If you want to align to middle of a text frame and the middle of an image, the proposed behavior does not make much sense.

JLuc

2013-06-23 14:12

developer   ~0030331

Last edited: 2013-06-23 14:28

you are right

but aligning the border of an image to the middle of a 2 column frame does not make much sense neither.

So snapping lines should be different depending on which part of the object is tested ?

Or simply the "borders of columns" should be also active as snapping places ?

If the # of proposed snaps guides is not to be moved, then more smartness can be introduced :

In a 2 columns frame, snapping the middle of an object to the middle of global frame is fine, but snapping the border of an object to the middle of the global frame could be not proposed : not because it never happens, but because snapping the border of the frame to the border of the column will be more often the desired placement.

JLuc

2013-06-24 09:07

developer   ~0030340

Last edited: 2013-06-24 09:16

During IRC talk some ideas emerged :

1)
In the Preference pane, propose more options for Snapping Preference :
[X] snap on items in a group
[X] snap on column borders

2)
Add a CTRL+SHIFT modifier that includes all snapping possibilities
(opposite to SHIFT modifier that includes none)

3)
Add AI to the snapping tool and have a smart politic in the snapping relationships betwen items and possible snapping places.

Like : snap the center of a frame to the center of a 2 column text frame,
but dont snap the border of a frame to that same center because column borders are more relevant.

And : snap the left border of a frame to the left border of the 2nd column's text frame, and snap the right border of a frame to the right border of the 1st column, but dont snap other parts.

Each possible relationship could be awarded a likelyness to be usefull.

Scribus could even LEARN from user's action : record most user-used snapping relationships and include them in the normal snap propositions. The never used or less used relationships being relegated to the CTRL+SHIFT modifier. This memory could be recored for future document or reset when begining a totaly new work.

;-)

JLuc

2014-07-02 19:27

developer   ~0032412

since its possible to add magnetic guides, and make them fit the columns borders, i close this bug

JLuc

2017-03-22 12:43

developer   ~0043654

I reopen because, as n4mu says on irc, « indeed, "snap to column" would solve many issues, less maths, less guides.. :] »

ale

2017-03-22 14:30

manager   ~0043655

i don't know, if you want flexible columns you should create one frame per column.
and if somebody feels uncomfortable with creating multiple frames we should improve scribus to make it more comfortable.

the difference being, that improvements to the in-frame columns only improve that small part of scribus, while improvements to the frame-bases columns can probably profit to the whole frames and items management.

ale

2020-09-06 19:18

manager   ~0048038

since the columns are there, they are in almost every tutorial, and we now have snapping to items, we should also have the items snap to them.

i'm still convinced that we should rather improve the way frames can be put together. but if columns are here to stay and are so prominent, the should at least work well.

Issue History

Date Modified Username Field Change
2013-06-23 10:50 JLuc New Issue
2013-06-23 13:53 jghali Note Added: 0030328
2013-06-23 14:12 JLuc Note Added: 0030331
2013-06-23 14:13 JLuc Note Edited: 0030331
2013-06-23 14:15 JLuc Note Edited: 0030331
2013-06-23 14:20 JLuc Note Edited: 0030331
2013-06-23 14:26 JLuc Note Edited: 0030331
2013-06-23 14:26 JLuc Note Edited: 0030331
2013-06-23 14:27 JLuc Note Edited: 0030331
2013-06-23 14:28 JLuc Note Edited: 0030331
2013-06-24 09:07 JLuc Note Added: 0030340
2013-06-24 09:09 JLuc Note Edited: 0030340
2013-06-24 09:09 JLuc Note Edited: 0030340
2013-06-24 09:16 JLuc Note Edited: 0030340
2014-07-02 19:27 JLuc Note Added: 0032412
2014-07-02 19:27 JLuc Tag Attached: ideas
2014-07-02 19:28 JLuc Status new => closed
2014-07-02 19:28 JLuc Resolution open => won't fix
2014-10-11 18:38 Kunda Tag Detached: ideas
2017-03-22 12:43 JLuc Assigned To => JLuc
2017-03-22 12:43 JLuc Status closed => feedback
2017-03-22 12:43 JLuc Resolution won't fix => reopened
2017-03-22 12:43 JLuc Note Added: 0043654
2017-03-22 12:43 JLuc Status feedback => new
2017-03-22 12:43 JLuc Patch => No
2017-03-22 14:30 ale Note Added: 0043655
2017-04-02 16:43 JLuc Assigned To JLuc =>
2020-09-06 10:47 JLuc Relationship added related to 0013597
2020-09-06 10:47 JLuc Relationship added related to 0016233
2020-09-06 19:18 ale Note Added: 0048038