View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0015586 | Scribus | Graphics / Image Frames | public | 2019-03-05 07:58 | 2019-03-05 12:07 |
Reporter | ale | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | new | Resolution | open | ||
Product Version | 1.5.5.svn | ||||
Summary | 0015586: use a specific scale type for images that cannot be manual scaled | ||||
Description | currently, the code is "full" of exception for images that are not images (render frame, ...). instead of checking if an image frame is not a real image, we should add a new state in ScaleType / m_scaleMode. currently, for those images you can move and rotate the content but not scale it. personally, i think that no item edit should be possible, but i don't use those type of frames, so i'd like to ear the opinion of those who do... we can name the state after the feature it enables (or does not enable) or after the type of frame. of course, this type would not be shown in the image tab of the properties table (as it is now: all options are grayed out in the PP when i select a render frame) | ||||
Tags | No tags attached. | ||||
Patch | No | ||||
|
>> instead of checking if an image frame is not a real image, we should add a new state in ScaleType / m_scaleMode If you can do so with other pageitem attributes, that means you most likely don't need another state. Adding another state means you will need to handle this new value in all part of the code which use ScaleType / m_scaleMode and also ensure its consistency with the other attributes which were previously used to check for this "state". So basically you will in the end add even more code to keep things working correctly. |
|
just fyi, my next patch removes ScaleType and introduces an enum for the scale modes. i don't have the feeling, that adding a fourth state will then mean more code... soon, i will be uploading the patch for the "fill mode" and we can then re-discuss this... |