Re: Columns width should be based on data as well as column names

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Victor Engmark <victor(dot)engmark(at)gmail(dot)com>
Cc: pgadmin-support <pgadmin-support(at)postgresql(dot)org>
Subject: Re: Columns width should be based on data as well as column names
Date: 2012-12-24 09:07:54
Message-ID: 1356340074.2000.15.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgadmin-support by date

  From Date Subject
Next Message Guillaume Lelarge 2012-12-24 09:27:30 Re: Deselecting superuser privilage
Previous Message Guillaume Lelarge 2012-12-24 08:59:35 Re: pgadmin3 - Crash on renaming