Re: [pgadmin-hackers] [pgAdmin4][PATCH] Improvements to Query ResultsGrid User Experience - Mailing list pgadmin-hackers

From Sarah McAlear
Subject Re: [pgadmin-hackers] [pgAdmin4][PATCH] Improvements to Query ResultsGrid User Experience
Date
Msg-id CAGRPzo8N59YE3qyZDLzBfVu=UiaiYfcK-QoLFF7PvPh2uL5jTg@mail.gmail.com
Whole thread Raw
In response to Re: [pgadmin-hackers] [pgAdmin4][PATCH] Improvements to Query ResultsGrid User Experience  (Dave Page <dpage@pgadmin.org>)
Responses Re: [pgadmin-hackers] [pgAdmin4][PATCH] Improvements to Query ResultsGrid User Experience  (Dave Page <dpage@pgadmin.org>)
List pgadmin-hackers
Thanks. When I run the tests my browser opens in some default size
that's always consistent, but doesn't match my normal Chrome sessions,
or the 1024x1024 default set in app_starter.py.

This looks like an issue with string edit box placement in the implementation. We created an issue for this (RM2477).

Anyway - I found another issue. If I select one or more columns or
rows, or an arbitrary selection of cells, copy/paste seems to work
fine. However, if I click the Select All arrow, for a small resultset
(e.g. SELECT * FROM pg_database with 18 rows) it works fine, but if I
do the same with the contents of pg_class, which has 1342 rows on this
DB, it seems to fail to populate the clipboard and ends up pasting
whatever was copied previously instead. If I use the Copy button, even
on a fast machine it seems to pause for a second or so before failing
to put the data on the clipboard.
 
We were able to reproduce this with "SELECT generate_series(1, 50000)"
The issue was still present for us when we ran the app at each of 2fddf750 and 495a3cedb
Could we move this discussion to a new thread as it doesn't seem related to these changes?

Thanks,
George & Sarah




On Thu, Jun 8, 2017 at 10:19 AM, Dave Page <dpage@pgadmin.org> wrote:
Hi

On Thu, Jun 8, 2017 at 2:18 PM, Sarah McAlear <smcalear@pivotal.io> wrote:
> On Thu, Jun 8, 2017 at 8:34 AM, Dave Page <dpage@pgadmin.org> wrote:
>> - There are changes to SlickGrid, the addition of a function to scroll
>> a column into view. Is this submitted upstream and accepted?
>
> We have submitted the changes we made to the patch to Slick grid and they
> were accepted yesterday. We can get this in today or first thing tomorrow.

Great.

>>
>> - One of the regression tests now fails because it's trying to access
>> an element that's out of the clickable area. If I widen then browser
>> for testing it passes so I believe it's just the test that needs
>> fixing. Can you take a look at that ASAP please?
>
> We haven't seen this test fail but we can absolutely look into it. Our
> Chrome browser is always the same size. We can try fiddling with that to see
> if we can get it to fail.

Thanks. When I run the tests my browser opens in some default size
that's always consistent, but doesn't match my normal Chrome sessions,
or the 1024x1024 default set in app_starter.py.

Anyway - I found another issue. If I select one or more columns or
rows, or an arbitrary selection of cells, copy/paste seems to work
fine. However, if I click the Select All arrow, for a small resultset
(e.g. SELECT * FROM pg_database with 18 rows) it works fine, but if I
do the same with the contents of pg_class, which has 1342 rows on this
DB, it seems to fail to populate the clipboard and ends up pasting
whatever was copied previously instead. If I use the Copy button, even
on a fast machine it seems to pause for a second or so before failing
to put the data on the clipboard.

Can you take a look at that too please?

Thanks.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

pgadmin-hackers by date:

Previous
From: Dave Page
Date:
Subject: Re: [pgadmin-hackers] [pgAdmin4][Patch]: UI improvements indata-grid/query tool
Next
From: Sarah McAlear
Date:
Subject: [pgadmin-hackers][patch] Changing the ACI tree font to Helvetica