Re: Columns width should be based on data as well as column names - Mailing list pgadmin-support

From Guillaume Lelarge
Subject Re: Columns width should be based on data as well as column names
Date
Msg-id 1356340074.2000.15.camel@localhost.localdomain
Whole thread Raw
In response to Columns width should be based on data as well as column names  (Victor Engmark <victor.engmark@gmail.com>)
List pgadmin-support
On Thu, 2012-12-20 at 12:19 +0100, Victor Engmark wrote:
> Three related bugs/feature requests:
> 
> How to reproduce:
> 
> 1. Open the Query Tool window.
> 2. Enter "SELECT 'longer text than the title' AS shorter_title" in the
> query window.
> 3. Run the query.
> 
> Result: The width of the column in the Data Output tab fits the string
> "shorter_title", but the result cell is cut off after "longer t"
> (depends on the font).
> 
> Expected: The width should fit the widest of either the column name
> ("shorter_title"), data type ("unknown"), or any rows ("longer text
> than the title").
> 

That would be cool, but it would be so slow. We would have to check the
content's width of every cell. Not sure it's worth it.

> 4. Drag the right of the column frame to change the column width.
> 5. Double-click the column frame to auto-fit the width.
> 
> This also resizes the width to fit the column name or data type,
> rather than the longest string in the column. In addition, unless the
> column border bisects a visible character, it's not really visible
> whether there is any more data in the column. This could be indicated
> by for example fading out the text at the right edge of the column.
> Only if there really is hidden data, though. I've seen implementations
> of this which would shade the right side even though the width exactly
> fit the data.
> 

Yes. Or adding ellipsis at the end.

> Of course, there might be a slight performance issue here

Slight? first tests I did showed some huge performance drops. Enough to
make me stop my work on this.

> , and some
> column data might be very wide, so here are some quick suggestions for
> a more usable compromise:
> * Only check the first N rows for the max width (plus the column name
> and data type, as before).

That could be done, but everyone will have his opinion on the X value.

> * Implement some restrictions if it turns out that the width of all
> the output will be wider than the window. For example, set a maximum
> width, or reduce the widest column widths until they all fit.

Sure.

> * Resize to the widest data in *all* the fetched rows if the user
> double-clicks the right column border; I usually assume that manual
> intervention means the user *really* wants to see the full width.

Yeah, that sounds good.


-- 
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com




pgadmin-support by date:

Previous
From: Guillaume Lelarge
Date:
Subject: Re: pgadmin3 - Crash on renaming
Next
From: Guillaume Lelarge
Date:
Subject: Re: Deselecting superuser privilage