Bug 87495 - Feature request: dynamically show more content in dialog boxes when user extends their size
Summary: Feature request: dynamically show more content in dialog boxes when user exte...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: ux-advise (show other bugs)
Version:
(earliest affected)
4.3.4.1 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-19 14:04 UTC by Frank Berke
Modified: 2016-05-24 13:20 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Shows a dialog box which is maxed to the extreme (45.61 KB, image/png)
2014-12-19 14:04 UTC, Frank Berke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Berke 2014-12-19 14:04:52 UTC
Created attachment 111049 [details]
Shows a dialog box which is maxed to the extreme

This request came to my mind working with the 'Columns' tab while editing a table. I had a document with a large table (around 20+ columns), and I wanted to properly set each one's width.

With that many columns the design of the colums tab turns out to be very annoying, as it only shows 6 editable fields at a time.

It would be great, if more editable fields could be added, once the user extends the size of the dialog box. I'll add a screenshot that demonstrates the look of that box on a dual-monitor workplace: much space wasted.

If this proposal is impossible to fulfil, at least add buttons that shift all 6 fields to the left or right side. Currently, I can only shift them one by one.

Thanks a lot!
Comment 1 Robinson Tryon (qubit) 2014-12-20 19:46:49 UTC
One for the UX Team...
Comment 2 Heiko Tietze 2016-05-24 10:02:34 UTC
I close this as WONTFIX.

Basically we do not want to make dialogs resizable, with the exclusion of those with input fields like the file name [1]. Regarding (Writer) table format > columns I'd say the current implementation is bad usability. Better fields are stacked vertically (just as a list), or a different interaction is used where first the column has to be selected and then the properties can be changed. User-centered design may add a button "unify" to address the actual use case. 

The current implementation "scrolls" (click on the button moves forward/backward by one) through the columns where "paging" (click moves by all shown items, or better -1) might be more interesting to you. Feel free to create a new ticket for this workaround.

However, a table with +20 columns in Writer? You should consider to use Calc or Base with the option to insert the OLE object in Writer, if necessary.

[1] http://comments.gmane.org/gmane.comp.documentfoundation.libreoffice.design/7396
Comment 3 V Stuart Foote 2016-05-24 13:20:18 UTC
Concur with closing this issue.

(In reply to Heiko Tietze from comment #2)
 > However, a table with +20 columns in Writer? You should consider to use Calc
> or Base with the option to insert the OLE object in Writer, if necessary.

Reality is that formatting and style of Calc cells do not match those of Writer, and for publishing large format pages (beyond Ltr or A4) it is very common to require dozens of columns ideally an ability to style each.  Using OLE from a Calc sheet is not very functional--handling large tables in Writer (including better ability to copy tabular content from Calc) is needed.