View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009024 | Scribus | Usability | public | 2010-04-16 10:06 | 2016-03-31 16:59 |
| Reporter | subeditor | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Product Version | 1.3.6 | ||||
| Summary | 0009024: Allow to resize frames while editing content | ||||
| Description | For now you have switch to "select object" mode any time you want resize box, and switch back to continue editing content. Is the any reason for this (beside possible technical issues)? Suggestion: make resize points of frame always visible and active. | ||||
| Tags | discussion | ||||
| Patch | |||||
|
|
The reasons are mainly technical. That possibility, available in 1.3.3.x, was removed : - the way it was implemented was causing unintentional behaviors, especially frame resize while editing (see #issue 0007411) - it was causing bugs and still has the potential to (see 0007413) The possibility will be reintroduced when we will be able to do it properly. For now using Escape key allows to switch from edit content mode to select mode in the most efficient way. |
|
|
BTW: you can always resize with the Properties Palette, even in Edit Mode. |
|
|
Shure I can, but when I need snap frame to guide or align it somehow with another object resizing by mouse is much more convenient cause you can't catch it position in mm or inches with your eye. About http://bugs.scribus.net/view.php?id=7411. I don't understand what is "bad" in ability to resize in a case of linking frames. Select first frame, select "link" tool, click on next frame. How red handlers messed with it? |
|
|
>> About http://bugs.scribus.net/view.php?id=7411. [^] I don't understand what is "bad" in ability to resize in a case of linking frames. Select first frame, select "link" tool, click on next frame. How red handlers messed with it? The problem is that this can lead to *unwanted* resize. And in the code that create an ugly mess. |
|
|
Jean and Franz, I got you perfectly. But this needs to be fixed. There is no reason that can stand here. It’s broken. Period. We’ve got to admit it. So, basically, if the code is bad, if it produces other kind of bugs, then my opinion on this is: document the other bugs and leave the expected behavior as is. Taking away what was already working even not perfectly, is a sub-optimal solution, don’t you think? We could say that the fix is uglier than the problem it’s trying to get by (not even solve, here). About bug 7413, in all respect to the poster, "flip vertical" is certainly not a manipulation we expect users to do on a large scale. It’s just that: a wrong decision. Please revert to what it was and if not then let’s hope we’re not loosing too many people. This behaviour alone is enough to drive away a lot of people. That said in all respect for the developers! Cheers! |
|
|
added 'discussion' tag |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-04-16 10:06 | subeditor | New Issue | |
| 2010-04-16 13:52 | jghali | Note Added: 0023710 | |
| 2010-04-16 14:05 | jghali | Note Edited: 0023710 | |
| 2010-04-16 18:18 | fschmid | Note Added: 0023711 | |
| 2010-04-16 21:19 | subeditor | Note Added: 0023712 | |
| 2010-04-16 22:12 | jghali | Note Added: 0023713 | |
| 2010-04-16 22:13 | jghali | Note Edited: 0023713 | |
| 2010-06-25 01:38 | louisdesjardins | Note Added: 0024208 | |
| 2016-03-31 16:59 | Kunda | Tag Attached: discussion | |
| 2016-03-31 16:59 | Kunda | Note Added: 0039632 |
