Bug 1268455

Summary: [RFE] support auto-shrinking table columns
Product: [oVirt] ovirt-engine Reporter: David Jaša <djasa>
Component: Frontend.WebAdminAssignee: bugs <bugs>
Status: CLOSED DUPLICATE QA Contact: Pavel Stehlik <pstehlik>
Severity: low Docs Contact:
Priority: low    
Version: 3.6.0CC: bugs, gshereme, oourfali, vszocs, ykaul
Target Milestone: ---Keywords: FutureFeature, Improvement
Target Release: ---Flags: ecohen: ovirt-future?
djasa: planning_ack?
djasa: devel_ack?
djasa: testing_ack?
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-11-30 21:13:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: UX RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screenshot with inspector
none
table overflowing on FullHD monitor
none
table fitting in < 1500px window after deletion of fixed width definitions none

Description David Jaša 2015-10-02 20:55:29 UTC
Created attachment 1079510 [details]
screenshot with inspector

Description of problem:
Most of the tables (or more precisely, "tables" because column widths are defined per-row(group), not for whole table) have "feature" of having lots of unused horizontal space (in attached screenshot). In some tables, even Full HD resolution is not wide enough to display the table (screenshot 2). OTOH when all the fixed column width definitions are removed using Inspector, the content fits in less than 1500px, aka about 2/3 of currently needed horizontal area (screenshot 3) although the realistic size would be somewhat wider in order to look nice...

Tables in webadmin should be reimplemented using real tables so that all the info in the table is useful (visible) without compromising aesthetics.


Version-Release number of selected component (if applicable):
3.6

How reproducible:


Steps to Reproduce:
1. diplay wide tables in webadmin using not-so-wide browser window
2.
3.

Actual results:
tables overflow the window but lots of space within cells is absolutely empty

Expected results:
table cells have just enough padding so they don't look cramped

Additional info:

Comment 1 David Jaša 2015-10-02 21:00:15 UTC
Created attachment 1079519 [details]
table overflowing on FullHD monitor

Comment 2 David Jaša 2015-10-02 21:03:56 UTC
Created attachment 1079520 [details]
table fitting in < 1500px window after deletion of fixed width definitions

Comment 3 Einav Cohen 2015-10-14 06:23:30 UTC
tables in the UI should be based on PatternFly tables.

Comment 4 Greg Sheremeta 2017-11-30 17:28:46 UTC
We've switched the table widget to a GWT DataGrid. I don't see us ever switching to the PatternFly datatable while we're still using GWT in webadmin.

We could implement some kind of "shrink columns to minimum" feature. That could be done globally, or by perhaps double-clicking on the column border (similar to a spreadsheet).

Comment 5 Vojtech Szocs 2017-11-30 17:50:17 UTC
(In reply to Greg Sheremeta from comment #4)
> We've switched the table widget to a GWT DataGrid. I don't see us ever
> switching to the PatternFly datatable while we're still using GWT in
> webadmin.

Using native JS (non-GWT) solution would require GWT/JS interop (added code complexity) and make it harder to debug potential issues (due to GWT centered around Java).

Even if we justify the above, we'd still need to keep supporting existing features like column resizing and column control (toggle visibility + swap position) while preserving existing look & feel. It's not impossible [1], just more research & work compared to existing GWT solution.

[1] https://datatables.net/extensions/colreorder/examples/integration/colvis.html

Comment 6 Vojtech Szocs 2017-11-30 17:50:44 UTC
Link to PatternFly table view, for reference: https://www.patternfly.org/pattern-library/content-views/table-view/#/code

Comment 7 Greg Sheremeta 2017-11-30 21:13:37 UTC

*** This bug has been marked as a duplicate of bug 1020167 ***