Fw: [pgadmin-support] No high resolution support in Windows

About a month ago I created this patch for Windows and sent it to the pg-admin support list, but received no reply.

Today another user complains about similar issues on Linux.

Maybe my patch could be adapted to fix both issues.

Thanks,

Sent from Windows Mail

From: Vladimir Nicolici
Sent: ‎Saturday‎, ‎25‎ ‎October‎, ‎2014 ‎19‎:‎37
To: Guillaume Lelarge
Cc: pgadmin-support(at)postgresql(dot)org

BTW, i found another related bug:

If you resize a row manually, then you try to zoom in/out using the mouse wheel, the text size changes, but the row height no longer changes.

I think that is because the default value for the resizeExistingRows parameter of theSetDefaultRowSize method is “false”, and once you make a manual change the defaults no longer apply automatically.

Attached a new version of my patch, that attempts to fix that too.

Sent from Windows Mail

From: Vladimir Nicolici
Sent: ‎Saturday‎, ‎25‎ ‎October‎, ‎2014 ‎16‎:‎54
To: Guillaume Lelarge
Cc: pgadmin-support(at)postgresql(dot)org

Found the reason the “Edit” grid looks better, rows have 2 more pixels.

in frmEditGrid.cpp:

#ifdef __WXMSW__
sqlGrid->SetDefaultRowSize(sqlGrid->GetDefaultRowSize() + 2, true);
#endif

The commit comment is:

commit ec4098968604f0acd3ef34fad56afb63b9add062

Author: Steffen Kuhn <pg(at)kuhnsteffen(dot)de> 2010-09-02 19:15:35

Committer: Guillaume Lelarge <guillaume(at)lelarge(dot)info> 2010-09-02 19:18:03

Fix an issue when editing date value in frmEditGrid

There was a bug which makes the date value invisible. Adding two pixels to the

height of the widget fixes that.

Patch from Steffen Kuhn.

A quick and safe fix would be to move that code to ctlSqlGrid.cpp, after the “ SetDefaultRowSize(fntCells.GetPointSize() * 2);” lines in both the constructor and the OnMouseWheel method, making the frmEditGrid and frmQuery grids look the same.

The only potentially negative side effect is that, depending on the font settings, about 10% less rows will fit on the screen in the query result.

BTW, nice undocumented feature, being able to zoom in/out with [Control] + [Mouse Wheel]. Not that I would read the documentation anyway. Funny that I discovered that reading the source code. This shows the truth of Robert C. Martin’s quote: “Truth can only be found in one place: the code.”

Probably it would be better to have zoom in/out buttons on the toolbar, with a hover tooltip “you can also use control+mouse wheel to zoom” to make it more discoverable. But I digress.

Another issue is that the code for mouse wheel zoom doesn’t to take into account those additional 2 pixels for edit grids, and after scrolling in/out those two pixels are lost, so the edit grid looks just as bad as the SQL results grid, and probably the bug fixed by that patch resurfaces. Moving that code as I recommended will also fix this.

Digging some more and playing with the zoom in/out feature, I noticed that the row labels are not affected by this issue, and look fine for both query grids and edit grids, at all zoom levels.

Looking at the wxwidgets source code, the default cell alignment is:

m_defaultCellAttr->SetAlignment(wxALIGN_LEFT, wxALIGN_TOP);

and the default row label alignment is:

m_rowLabelVertAlign = wxALIGN_CENTRE;

This seems to fix the issue for the row labels.

So, in addition to moving that code, I think this should be added:

SetDefaultCellAlignment(wxALIGN_LEFT, wxALIGN_CENTER);

under

SetColLabelAlignment(wxALIGN_LEFT, wxALIGN_CENTER);

in ctlSqlGrid.cpp . Maybe enclosed in a #ifdef __WXMSW__, if you don’t want this on other operating systems, although it should be fine.

Also, since we’re here, the column headers are affected by the same issue, and need about 4 more pixels for the two rows, something like this:

#ifdef __WXMSW__
SetDefaultRowSize(GetDefaultRowSize() + 2);
SetColLabelSize(GetColLabelSize() + 4);
#endif

Anyway, I attached a patch.

While I tried to be very careful and I’m quite confident it will work and fix the issues, it’s not tested in any way, it may not even compile, since I usually work with Java and I don’t have a C++ development environment.

Sent from Windows Mail

From: Vladimir Nicolici
Sent: ‎Sunday‎, ‎19‎ ‎October‎, ‎2014 ‎15‎:‎40
To: Guillaume Lelarge
Cc: pgadmin-support(at)postgresql(dot)org

Is there any way to increase the default row height in SQL Data Output grids? Because grids having rows that are too narrow to show the text properly is the only annoying thing when I disable high resolution scaling for pgAdmin.

The “Edit Data” grids look much better because the rows are a few pixels taller, for some reason. They still truncate a few pixels from the bottom of the content, but it’s acceptable.

SQL Data Output vs Edit Data grids with high resolution scaling disabled: http://i.imgur.com/yyLcFYE.png

And for that matter, unrelated to the resolution issues, is there a way to increase the default column width? I hate having to resize each column, especially when the grid has many columns, because by default they are not wide enough in most cases:

http://i.imgur.com/ewSW8kP.png

Sent from Windows Mail

From: Guillaume Lelarge
Sent: ‎Wednesday‎, ‎1‎ ‎October‎, ‎2014 ‎14‎:‎44
To: Vladimir Nicolici
Cc: pgadmin-support(at)postgresql(dot)org

Hi,

Le 26 sept. 2014 16:33, <vladnc(at)gmail(dot)com> a écrit :
>
> pgAdmin Version: 1.18.1
>
> OS: Microsoft Windows [Version 6.3.9600] (8.1 Pro 64 bit)
>
> 1. Use Control Panel\Appearance and Personalisation\Display to set a high dpi:
>
> http://i.imgur.com/WQJmlWe.png
>
> 2. Logout/login again to make sure the changes are fully applied.
>
> 3. Open pgAdmin
>
> Result - pgAdmin is very blury, because it doesn’t support high DPIs and is up-scaled by Windows:
>
> http://i.imgur.com/0L8l3Yh.png
>
> http://i.imgur.com/fBV09X5.png
>
> Disabling scaling for the application resulted in even worse behavior, like overlapping UI elements, because some of them were resized and some not.
>

Well, yeah, PgAdmin is not fully compatible with high DPI display. We need to provide icons with better resolution. And we need a fully compatible wxwidgets library. As far as I can tell, it isn't, at least on windows. Mac os x retinas displays seem to work fine though.