Re: PATCH: Choose best width for Data Output columns of Query tool - Mailing list pgadmin-hackers

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.

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).


DK> And also suggesting to change the AutoColumns() function like below.

Sure, done.

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@mail.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