Bug 135884 - ENHANCEMENT: Add a lock to caption frame; so frame being image (as prevention for unintended changes within the frame)
Summary: ENHANCEMENT: Add a lock to caption frame; so frame being image (as prevention...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-18 15:53 UTC by Telesto
Modified: 2020-10-09 08:47 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-08-18 15:53:09 UTC
Description:
ENHANCEMENT: Add a lock to caption frame; so frame being image (as prevention for unintended changes within the frame)

Steps to Reproduce:
1. Open Writer
2. Insert an image
3. Insert a caption frame

Actual Results:
You have click rather specific on the border of the frame to move the frame. So quite often happen you end up clicking inside the frame. This problematic for dragging & for the right click context menu

Expected Results:
My idea/ global notation is to prevent number of settings being available by default for the image inside an image caption frame. Sort of 'lock' mode/ group.

The lock disables; 'anchoring settings for the frame' alignment settings/ arrange settings/ insert caption (inside caption) in the context menu. As rather pointless to have. 

Also it would be easier to drag/drop an caption frame. Ideally clicking the image, should select the frame (as long as on locked mode).

The only issue.. what to do with compress/save/replace/crop. Is lock can be bit problematic. Same as replace/save.

A solution would be a global unlock all caption frames button


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.1.0.0.alpha0+ (x64)
Build ID: <buildversion>
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 1 Heiko Tietze 2020-09-22 09:49:10 UTC
There is Options > Protect: Contents, Position, Size in the frame's properties dialog. Does this solve your problem?
Comment 2 Telesto 2020-09-22 14:02:11 UTC
(In reply to Heiko Tietze from comment #1)
> There is Options > Protect: Contents, Position, Size in the frame's
> properties dialog. Does this solve your problem?

You do sound like a FAQ bot :-) 

1) Yes, this setting would resolve the issue mostly (the image click isn't converted to frame; which would be 'ideal')
2) But my "problem/ issue"  [both overstating the importance] isn't resolved. In they way I would expect this to happen automatically. 

I assume people will drag frame around. I assume people will misclick once in a while (selecting image instead of frame). I assume this end up in a drag (which clearing does the wrong thing)

Yes, this can be 'resolved' by press CTRL+Z. 
Yes, I dislike things going automatically. So being attempting to be smart, however this might be counterproductive (say people cutting/paste image out of frames; which surprisingly can't move anymore)

So and the one hand I would propose.. Check they position checkbox if image (shapes or whatever) are inserted into a caption frame.

Next best thing would be of course an option in they caption box style to change the setting image position (FWIW: size doesn't currently not work in frame) of the framed image/shape. And of course being able to set the 'default' style (would be most flexible). The setting is present for the frame itself, but not "for frame content"

It's only an idea. Based on my own experience of clicking image instead of frame. But maybe the 'general public' being motorically better equipped/ having better eye sight.. so it's simply me (yes, I use the mouse for selecting; not keyboard); No and not they navigator.. 

It would make life easier on tables/phones etc too; I think. 


Switching to more off-topic
However there are no UX-guidelines about which devices must be taken in consideration (not even screen sizes; for certain topics netbooks appear to be the baseline (so 1024x768?). So no clue if this must be included in the consideration or not. [Sorry, implicitly nagging for some more guidance rules :-]. Would make arguing easier.. And might prevent some mistakes here an there. Would make UX more accessible etc etc. 

You (Heiko) are likely the most equipped person for that; doesn't have to start with full book; simply draft, work in progress etc. Where stuff can be added when it comes up etc. As I really don't known to what's is targeted (and if this is out of scope of UX this must be decided at ESC/BoD) as those are responsible for supported devices etc. 

Same topic is with they Bold/Unbold matter.. Mike and I are simply disagreeing. Mike is might overstating the issue or I'm underestimating the issue (or even both). Bit I dislike it being discussed by only 2 persons. As this doesn't represent the 'public'. I know what Mike his opinion is. I know mine. I know you have to keep on "good terms" with (nearly) everybody. So sometimes not clear if it's your opinion or simply "keeping the peace". 

And of course there is 'some' triviality.. as this nothing surprisingly new (topic around for ... years). So doesn't really need a 'speedy' decision. However some clarity would be nice at some point (but of course a cooling down period doesn't hurt :-). However I love 'more input' on the topic (from more contributors). They Tabbed default is also a hot potato; where probably every decision would come as surprise. Surely no feeling what the result will be if a decision is made (alternative is of course letting it float, because lack of consensus. An ideal that likely never will be reached). So representing 'body' is needed. UX department is in principle right; except the body isn't chosen; has no minimum number of members (etc). So not always feeling 'represented' by UX decisions. So some decisions are 'hard to swallow' and not always feeling of being 'represented' (and lacking clear motivation) Nothing personal though :-). A body could also stick limits on certain topics. So a time where a certain topic is under embargo; so decision is made by elected representatives of TDF UX board. So not open for new debate for 'statutory time frame' and maybe even extended if there are 'reasonable reasons'. But maybe I like governing body's to much; but like clear transparent decisions.
Comment 3 Heiko Tietze 2020-09-22 14:27:53 UTC
(In reply to Telesto from comment #2)
> You do sound like a FAQ bot :-) 

Always in hope you search the bugtracker first :-). We have several about frames either being selected unintentionally when users want to get the object or not the other way around. A quick search revealed bug 78583 and bug 86598 (you might find better suited, I remember Regina arguing on one ticket).

In this particular topic I don't see how this would be guidelinizable. The minimum screen size is defined as WXGA having old notebooks/displays in mind.

Back to topic: you want to solve the issue of unintentionally moved images by locking it, this might be your way to go. I don't get the point of global lock/unlock in this regards.
Comment 4 Telesto 2020-09-22 18:24:38 UTC
(In reply to Heiko Tietze from comment #3)
> (In reply to Telesto from comment #2)
> > You do sound like a FAQ bot :-) 
> 
> Always in hope you search the bugtracker first :-). We have several about
> frames either being selected unintentionally when users want to get the
> object or not the other way around. A quick search revealed bug 78583 and
> bug 86598 (you might find better suited, I remember Regina arguing on one
> ticket).

I think you know the answer to that(◔_◔). Will try to find the ticket with Regina her argument

> In this particular topic I don't see how this would be guidelinizable. The
> minimum screen size is defined as WXGA having old notebooks/displays in mind.

Screen size drifting off topic. Core question. Must tablet/phone taken into account. Selecting a frame with touch screen is even harder (compared to mouse cursor), so locking mechanism would really welcome in that case.. But not knowing enough about if this needs to be taken into account here. 

> Back to topic: you want to solve the issue of unintentionally moved images
> by locking it, this might be your way to go. I don't get the point of global
> lock/unlock in this regards.

Didn't read my initial report, directly jumped into your suggestion. The initial proposal was the 'grouping' concept. So making frame & content a group (similar to shapes). Which can be ungrouped. Not enough experience with grouping shapes and stuff to now if the caption would be accessible in this model (I assume so)

So 'lock/unlock' is same as 'group/ungroup'. Advantage of grouping is of course that no fixed position being set.
Comment 5 QA Administrators 2020-09-23 04:00:01 UTC Comment hidden (obsolete)
Comment 6 Heiko Tietze 2020-10-09 08:47:09 UTC
We discussed the topic in the design meeting. The use case of accidentally moving objects is clear, however sometimes also wanted. Typically workflow is to add an image, position it correctly, and then make it sticky. This can be achieved by a dedicated frame style where the position/size protection is enabled.

It should also be possible to have this setting by default after changing the default frame/graphic styles. However, after adding an image the style is a applied (and highlighted in the inspector) but the protection is not effective. One has to change the style manually back and forth. This is a (different) bug; resolving the enhancement request here as WF.