[Libreoffice-ux-advise] [Bug 113604] Optimal column width of table in Writer is cumbersome and not persistent

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=113604

cson...@halmai.hu changed:

   What|Removed |Added

 CC||cson...@halmai.hu

--- Comment #10 from cson...@halmai.hu ---
Created attachment 137932
  --> https://bugs.documentfoundation.org/attachment.cgi?id=137932=edit
use case showing when automatic readjustment of column withs would destroy the
precisely adjusted layout

I add an attachment now to illustrate what kind of use case I was referring to. 

Let's say a teacher, who creates work sheets for their student and uses many
images for illustrations, they can adjust the images manually, like the
attachment shows. They create the document at 11pm in the evening, print them
for the next morning and probably never use the same document again. 

For them, this manual positioning is the most straightforward way (please
correct me if there is a better one). If a small change like "R" => "r" in this
example, would adjust the columns slightly and would destroy the precise
alignment between the umbrealla and the letter J then quite likely they would
realise it only after printing or maybe the next day. This would cause
frustration for them.

As there is no better way to define relative positions in a nicer way, they
don't have other choice than reviewing the whole document continuously.


I'm not saying LO should never reposition anything. I just showed an example
where this can be different what the user wants.

Cut a long story short, I think the user may need two things:
- adjust the column width to be optimal according to their current content
- permanently keep the column withs optimal

Now LO has the first functionality and doesn't have the second one. I think we
should keep the existing menu item and we should introduce a new checkbox in
the table propertise called "Keep column widths optimal".

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] [Bug 113604] Optimal column width of table in Writer is cumbersome and not persistent

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=113604

--- Comment #9 from cson...@halmai.hu ---
Reply(In reply to Christian Lehmann from comment #8)

> 2) Optimal column width is a permanent property of a table until the user
> resets it. It remains in vigor after editing the cells. Again, I cannot
> imagine a scenario where I would want optimal column width for the present
> content of my table, but not for a changed table content.

I can. :) 

Example: the user fills the cells with some content and then changes the column
widths to be optimal (whatever it means). Later on, they may change the content
slightly, like fixing some typos or making some other minor changes. It can
happen that the user still wants to keep the existing postion of each column,
for example, because they placed some wrap-through images or frames here and
there. 

I admit, in many cases applying such images and frames is not necessary or can
be avoided but there are some other cases when they provide the
quickest/simplest solution. In those cases the user may want to preserve the
overall layout of the page, including the table cell positions.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] [Bug 113831] Find All search result window should show the number of found results

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=113831

Heiko Tietze  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #4 from Heiko Tietze  ---
The dialog has a label anyway, hidden by default, that shows the number of
'skipped' items for very long lists. We could always show this label and just
add the skipped to it.

Selection and CountA are alternative workflows.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] [Bug 113939] double underline - inconsistent shortcut across components

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=113939

Heiko Tietze  changed:

   What|Removed |Added

   Keywords|needsUXEval |
 CC|libreoffice-ux-advise@lists |tietze.he...@gmail.com
   |.freedesktop.org|

--- Comment #4 from Heiko Tietze  ---
We discussed the idea in the design meeting and think consistency is paramount.
Therefore double underline should be available in all modules, however with a
consistent shortcut where shift+ctrl+U is a good option.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] [Bug 86303] STATUSBAR: Easy access to change to read only mode

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=86303

Heiko Tietze  changed:

   What|Removed |Added

   Keywords|needsUXEval |
 CC|libreoffice-ux-advise@lists |tietze.he...@gmail.com
   |.freedesktop.org|
  Component|LibreOffice |Writer

--- Comment #15 from Heiko Tietze  ---
The design team discussed the proposal and supports the idea. The additional
status bar entry should toggle the read/write mode, ideally not per single or
double click but via context menu to avoid unintentional activation, and
clearly show the document status.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] [Bug 87742] When image anchor is set to 'As Character' it should set vertical align to top

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=87742

Yousuf Philips (jay)  changed:

   What|Removed |Added

   Keywords|needsUXEval |
 CC|libreoffice-ux-advise@lists |rb.hensc...@t-online.de,
   |.freedesktop.org|vstuart.fo...@utsa.edu

--- Comment #7 from Yousuf Philips (jay)  ---
Regina, Stuart: any thoughts on this?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] [Bug 113276] UI of LO6: frayed borders of =?UTF-8?Q?=E2=80=9Ab=E2=80=98?=, ‚e‘ & ‚O‘ in the logo of the ‚About‘ window

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=113276

Heiko Tietze  changed:

   What|Removed |Added

   Keywords|needsDevEval, needsUXEval   |
 Status|NEW |RESOLVED
 CC|libreoffice-ux-advise@lists |tietze.he...@gmail.com
   |.freedesktop.org|
 Resolution|--- |FIXED

--- Comment #3 from Heiko Tietze  ---
Issue should be solved in Beta. This image (SVG) will be used
https://redmine.documentfoundation.org/attachments/2137/flat_logo.svg

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] [Bug 113604] Optimal column width of table in Writer is cumbersome and not persistent

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=113604

--- Comment #8 from Christian Lehmann  ---
To Csongor:
It does not seem excluded that something like my suggestion for refurbish the
entire table management will be adopted in a future version of LO. Then that
would include a simple solution for selecting portions of a table and applying
anything to them. And sure enough, these latter actions should be accessible by
right-click menus.

As long as this presupposition is not fulfilled, any interim solution which
requires less key hitting or button clicking is fine.

However, I would insist on two things:

1) If one wants optimal column width, then the default is to want it for an
entire table. I cannot even imagine a sensible scenario where I would require
it for only a subset. Suppose that applying optimal column width to the entire
table produces a result that does not appeal to me. Then it suffices to drag
the disturbing vertical borders to the side, which I would have to do, anyway.
And in particular, applying optimal column width only to one cell should not
even be offered, as this would imply table distortions à la MS Word.

2) Optimal column width is a permanent property of a table until the user
resets it. It remains in vigor after editing the cells. Again, I cannot imagine
a scenario where I would want optimal column width for the present content of
my table, but not for a changed table content.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] [Bug 95880] Add lock mark on protected sheet tab before tab label

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=95880

--- Comment #14 from Timur  ---
Created attachment 137909
  --> https://bugs.documentfoundation.org/attachment.cgi?id=137909=edit
Lock mark - Before and after Eike's patch

I can't say what's better, look before or after Eike's patch, but I guess there
were reasons as written. 
Anyway, thank you both. 

Jean-Francois didn't follow with the explanation why we wouldn't show lock mark
also in a corporate environment, for spreadsheet templates.
For me, it's better to have this mark always because it gives a clue why some
sheet is different and why some fields cannot be changed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise

[Libreoffice-ux-advise] [Bug 95880] Add lock mark on protected sheet tab before tab label

[bugzilla-daemon]

https://bugs.documentfoundation.org/show_bug.cgi?id=95880

Timur  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
Libreoffice-ux-advise mailing list
Libreoffice-ux-advise@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-ux-advise