View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011623 | Scribus | Usability | public | 2013-06-23 10:50 | 2020-09-06 19:18 |
| Reporter | JLuc | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | new | Resolution | reopened | ||
| Product Version | 1.5.0svn | ||||
| Summary | 0011623: Snapping in 2 colums text frames | ||||
| Description | As 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. | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
|
|
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. |
|
|
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. |
|
|
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. ;-) |
|
|
since its possible to add magnetic guides, and make them fit the columns borders, i close this bug |
|
|
I reopen because, as n4mu says on irc, « indeed, "snap to column" would solve many issues, less maths, less guides.. :] » |
|
|
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. |
|
|
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. |
| 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 |
