Re: PATCH: Choose best width for Data Output columns of Query tool

Hi ,

On Tue, Dec 3, 2013 at 8:57 PM, J.F. Oster <jinfroster(at)mail(dot)ru> wrote:

> Hello Dinesh,
>
> Tuesday, December 3, 2013, 12:23:16 PM, you wrote:
>
>
> DK> Could you change this like "event.CmdDown()
> DK> || event.CtrlDown()" for supporting both Mac, as well non-mac
> DK> keyboards.
>
> Done.
>
>
Thank you very much.

DK> I believe, the column size should not exceed to the half of
> DK> the available screen. But in this patch, the column size grows to
> DK> end of the screen.
>
> That is by design, as we have no reason to refuse to benefit of
> user's wide screen if all other columns fit well. Also Dave's
> observations were the same:
> Tuesday, November 19, 2013, 1:08:17 PM, Dave Page wrote:
> DP> ...
> DP> (I would suggest that a column should
> DP> never take up more than 50% of the visible space, unless that space
> DP> would otherwise be unused (e.g. you have 1 very narrow column, and one
> DP> large).
>
>
It's my mistake. Sorry. :)

> DK> And also suggesting to change the AutoColumns() function like below.
>
> Sure, done.
>
>
Thank you.

I have reviewed your patch and managed to traverse each line of your code,
except "AutoColumn" function body. Could you give me some information, when
the pgAdmin goes to this function call.

I have verified it in Mac/Linux/Windows, seems working fine. :)

Regards,
Dinesh

Please see the fixed patch attached.
>
>
>
>
> DK>> Thursday, November 21, 2013, 12:03:04 PM, you wrote:
>
> DK>>> Hi,
>
>
> DK>>> On Wed, Nov 20, 2013 at 11:02 PM, J.F. Oster <jinfroster(at)mail(dot)ru>
> wrote:
> DK>>> Hello Dinesh,
>
> DK>>>> Do
> SELECT '1', 'f'; ==>>>>> And then re-size the 1st
>
> SELECT '1', 'f'; ==>>>>> column to the end of the screen.
> DK>>>> Then do,
> DK>>>> SELECT 'f', '111111......Wide column' ==> This should re-size
> DK>>>> the grid as per the query result, which is not happening currently
> DK>>>> in my windows machine.
>
> DK>>> The first column gets same label in both queries
> DK>>> ("?column?\nunknown"). The original code behaves identically.
>
> DK>>>> Note: Yours 1st patch is working fine with the above case.
>
> DK>>> Due to my inadvertence it didn't honour previously saved sizes at
> all.
>
> DK>>> Here is another idea:
> DK>>> Do save the sizes only for those columns which were explicitly
> DK>>> resized by the user. Every user's resize results in new (or update to
> DK>>> existing) element in some associative array, whose key is composed of
> DK>>> colIndex and colLabel, and value is user-specified size. Elements
> DK>>> never get deleted out of this array for the life of Query window.
> DK>>> When displaying new result set, each column is inspected, if it's
> DK>>> index and label have corresponding element in array, it's size is
> DK>>> restored. Else it falls under automatic sizing.
> DK>>> Good points here:
> DK>>> 0. Automatic sizing works by default for every result set - so is
> DK>>> responsive (unlike last patch!) to changes in query results where
> DK>>> labels don't change - that's a very frequent case.
> DK>>> 1. Can save and restore user-specified sizes for columns in several
> DK>>> _different_ queries (run in the same window in arbitary order).
> DK>>> 2. Undesired sizing artefacts may appear in rare cases where user has
> DK>>> manually resized the column AND later he got column with same label
> DK>>> and in same position but of positively improper size (your last case
> DK>>> is about it). This still can be overcome by introducing restrictions
> DK>>> on applying saved sizes ("if saved and auto sizes differ more than n
> DK>>> times, discard the saved one / resize to something between / etc").
>
> DK>>> I'll try to implement this approach soon.
> DK>>> Opinions are welcome!
>
>
>
>
>
> DK>>> This is a good approach. But i am worrying about the performance.
>
> DK>>> For Ex:-
> DK>>> What if the query is having two many columns in a table,
> DK>>> which will be storing in a Hash/Assoc array, following by a SELECT
> DK>>> query with a single column.
>
>
> DK>>> @Dave,
>
>
> DK>>> Could you share your inputs on this please.
>
>
> --
> Best regards,
> Vadim
>