View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010947 | Scribus | Graphics / Image Frames | public | 2012-07-25 22:31 | 2016-01-23 16:45 |
| Reporter | JLuc | Assigned To | Chelen | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | assigned | Resolution | open | ||
| Product Version | 1.5.0svn | ||||
| Summary | 0010947: multiple image import cannot create frame in non empty space + consistency + option | ||||
| Description | When importing more than one image at once, following images require to create a new frame or use an existing one. Creating new frames during this "multiple creation" require the user to click and draw the frame. But this is only possible on empty part of page. Instead of this, trying to draw a new frame on top of a text frame does nothing, and trying to draw a new frame on top of an image frame replaces existing image with new imported one. ** Not being able to create an image import frame on top of a text frame is "a bug". As for the "inserting imported image in clicked image frame, even if it allready contains an image" feature, i feel it is at least deceiving and potentially dangerous. I'm not sure about the best way to deal with this since there is a conflict between 2 possible needs : 1) create new frame 2) insert image in existing frame. Maybe this feature could be triggered only if image frame is empty ? And if not, create new frame as usual. Search for consistency could lead to a solution for this "image frame selection or creation" choice. 1- File > Import > Image is only active if an image frame is selected. However, there is no need for a selected image frame afterward (for all but the first image) That's not consistent. So : ** File > Import > Image action should be active whether an image frame is selected beforehand or not (if not, it waits for an image frame to be drawn) 2- as-is behaviour is different in case click is on empty space or on image frame. That's a bit more complex than if behaviour is allways same and it is sometime deceiving and dangerous. Why favour "replacing image" versus "creating new frame" ? It's a new functionnality but it impairs the "creating new frame" functionnality. It's still possible to create a new frame on an empty place of the page, and move it later. OK. But if a big size image frame covers whole page, then this is not possible anymore. ** As a conclusion, i think the import image should stick to the simplest possible default behaviour : create frames for each imported image, whether the click and move happens on a text frame, on an image frame or on an empty space. ** As an option when creating a new frame is not required, CTRL modifier might be used to select existing frame and insert image there, replacing existing image when necessary. | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
i don't see anything dangerous here :-) undo is your friend... while i don't think that the "magical ctrl key" will of much help here, i believe that when the feature is ready, we will have to check its use cases and make sure that it's good for them! (well, this should have been done before starting coding... but that's life...) what could be interesting is to mark the frame as "selectable" when the mouse hovers a frame that can load the current resource (draw a red border around it, without handles: like the one shown when you select an image frame and start the multiple load). at the end, i think that we need to shrink the four entries in "file > import >" into one "file > load resource" which will behave according to the current selection (we could even rename the menu entry depending on what is selected...): - if an image frame is selected, only allow to load one singe image file in the current frame - if a text frame is selected, only allow to load one single "text" file in the current frame - if anything else is selected, let the user choose any number of any type of "loadable" resources and let her put the resources one after the other in existing frames or create a frame to contain it (for each type of resource a default type of frame is defined... it may be possible to override the choice by typing I, T, ...) the raw functionality is in... we need some fine tuning :-) |
|
|
<jluc> well : simplest is having same behaviour in every situation <a-l-e> or clearly show that multiple behaviors are possible? what we should indeed avoid is to have different behaviors that look the same... so it's important to show to the user what will happen before she triggers the action. and the action triggered should be as close as possible to what she's expecting (an exact matching is not always possible... since everybody has different expectations) |
|
|
I agree with "avoiding different behaviors that look the same..." I disagree with "Undo is your friend" since undo ability should not become an excuse for bad ergonomy (not too much !). As for this feature, UI choices should take into account - the interest of having a new feature (import into existing frames) versus - the disavantadge of loosing or degrading a feature (create frames and import into them). Complexity of having to use CTRL key has to be balanced with complexity of getting used to a UI that changes behaviour depending on situation of click. IMO, Use of CTRL key seems - as far as now - the way to not loose any of the features with the minimal complexity cost. |
|
|
... since begining user dont see that CTRL key complexity : for begining user, its very easy to use only "import multiple images a create frame for each". On the contrary, begining user is stopped by as-it-is now complex behaviour, and even more repelled when sHe has no choice. When user becomes a power user, sHe comes to use keyboard modifiers that are usefull for his-Her tasks, and that efficiency is a pleasure because it fits hisHer needs, and because its a choice to learn it. |
|
|
I will wait that everything is clear about what should be done before working on it. - I agree that we should be able to create an image frame on top of a textframe I would like to refer to the bug report about multiple image import: 0010701 As you can see, he asks to click on a frame to link the image to this frame. Imagine you have a full document, you know the size of each picture but they are not yet available. When you get images, you just want to import them in the selected frame. -Something that could be done is : if user move the mouse after clicking on an image frame, it create a new image frame. If it is a single click, it load the image in the image frame under the cursor. It may be disturbing for user to have different behaviour in these case whereas he is doing almost the same action. I don't really like the idea of : If the image is empty. Using the same example as above, if images you get were not correct and someone sent to you another set of images, you will not be able to reload them easily. -for File->Import->Image, I can't activate this as the shortcut CTRL+I is the same for import text. I can delete this shortcut but it will be disturbing for user to have another shortcut (or not at all). The solution is a-l-e idea : make only ONE import action for everything. If the idea about this is correct and everybody agree please assign it to me and I will try to implement this. As a-l-e, I really don't like modifier. There are a lot of modifier in scribus code and nobody know they exist because they may have been implemented long time ago and the personn which was using them doesn't use scribus anymore or something like this .... Do you know there is a modifier to move the image in the image frame without selecting the image frame or going in edit mode? I really don't know why but it exists... BTW jluc there are no disadvantage with this new feature as user can use import image as before without any difference (create frames and import into them) |
|
|
There are no detailed specs in 0010701. Both as-is behaviour and here-proposed behaviour adequatly fit this 10701 request. As for modifiers, i see that 0010701 mentions possible use of a modifier, so modifiers are within the range of accepted possibilities ! But IMO using "plain click" to insert-or-replace image in existing image-frame and click'n'move to create and draw new image frame looks like a possible alternative to CTRL Modifier (even if it is more complex for newcomer user). So it might be the way to go. As for general Import : why not. That should probably be another mantis request, but as for text import : it would also benefit of same bulk import ! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-07-25 22:31 | JLuc | New Issue | |
| 2012-07-26 05:32 | ale | Note Added: 0028633 | |
| 2012-07-26 06:31 | ale | Note Added: 0028636 | |
| 2012-07-26 07:39 | JLuc | Note Added: 0028637 | |
| 2012-07-26 07:48 | JLuc | Note Added: 0028638 | |
| 2012-07-26 07:53 | Chelen | Assigned To | => Chelen |
| 2012-07-26 07:53 | Chelen | Status | new => assigned |
| 2012-07-26 14:05 | Chelen | Note Added: 0028647 | |
| 2012-07-27 13:11 | JLuc | Note Added: 0028666 | |
| 2015-09-17 20:10 | Kunda | Category | Graphics / Image Frames => Graphics/Img Frames |
| 2015-09-17 20:11 | Kunda | Category | Graphics/Img Frames => Graphics / Image Frames |
| 2016-01-23 16:38 | Kunda | Note Edited: 0028647 | |
| 2016-01-23 16:44 | Kunda | Relationship added | related to 0012015 |
| 2016-01-23 16:44 | Kunda | Relationship added | related to 0011626 |
| 2016-01-23 16:45 | Kunda | Relationship added | related to 0010908 |
