Bug report #19386

QGIS 3 does not save main window size and position (after being set as default app?)

Added by Loren Amelang over 6 years ago. Updated over 6 years ago.

Status:Open
Priority:Normal
Assignee:-
Category:GUI
Affected QGIS version:3.2 Regression?:No
Operating System:Windows 10 Creators with 3000x2000 screen and 175% scaling Easy fix?:No
Pull Request or Patch supplied:No Resolution:
Crashes QGIS or corrupts data:No Copied to github as #:27214

Description

I reported #19172 about "QGIS 3.0.3 main window does not remember chosen size (Win 10 with scaling...)".

As I commented there, "So far 3.2 has always remembered my choices!" For two weeks after the update, it started exactly where I had left it, every time.

Today I was looking at a shapefile in a Win 10 folder, and wanted to know what was in it. Windows showed no app claiming shapefiles, so I scrolled through the list of possibilities and chose QGIS. And left the "Always use this app" box checked. QGIS opened - in its extremely tiny centered location and size! I'd never seen 3.2 do that! And now it reverts to the tiny size on every start, from the Start menu or by any other mechanism.

I wanted to edit 19172, but it seems there is no way to remove the "3.0.3" from the subject, which means it would probably get little attention. Whatever is happening to me definitely affects 3.2 as well! Perhaps it was triggered by being set as default app... Or something else... I do remember once setting 3.0.3 as Win 10 default app for some file type. Can't remember if that was related to the appearance of the size issue there.

Where should the window size and position be stored? How can I debug this further?

History

#1 Updated by Jürgen Fischer over 6 years ago

  • Description updated (diff)

#2 Updated by Richard Duivenvoorde over 6 years ago

Hi,

I think http://doc.qt.io/qt-5/qsettings.html#platform-specific-notes could be helpful.

If I'm correct, QGIS now on all platforms uses the ini format in the profile folder (and that folder you can via the QGIS menu for profiles).

I think(!) Qt information about the size and position ('geometry' in Qt lingua) is part of the QGIS3.ini file which you find in your profilefolder/<profilename>/QGIS/QGIS3.ini
As you can see that file(s) contain 'geometry' and 'state' keys with ByteArray values.

Normally all those are updated upon change of position and size.

Is it maybe possible that this kind of info is cleaned up every time with you? Are you maybe on some 'thin client' or 'citrix' setup? In some environments people startup with a very clean Windows profile upon every restart (as in roaming folder is deleted when logged out).

Anyway, hope this helps a little to do some testing yourself.

#3 Updated by Loren Amelang over 6 years ago

Thank you to Richard Duivenvoorde! (And no, my profile remains in place.)

I find:

C:\Program Files\QGIS 3.2\apps\qgis\resources\qgis_global_settings.ini
(no relevant content?)

C:\Users\loren\AppData\Roaming\QGIS\QGIS3\profiles\profiles.ini (180710-19:00, time of last close)
---
[core]
defaultProfile=default
---

The only other *QGIS*.* item anywhere is:

C:\Users\loren\AppData\Roaming\QGIS\QGIS3\profiles\default\QGIS\QGIS3.ini (180710-19:00)
---
[UI]
defaultAddDbLayerAction=0
state=@ByteArray(\0\0\0\xff\0\0\0\0\xfd\0\0\0\x3\0\0\0\0\0\0\x1\xb4\0\0\x3\xb9\xfc\x2\0\0\0\f\xfc
...
geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x3Y\0\0\x1>\0\0\n\x86\0\0\x5\xce\0\0\x3\x65\0\0\x1r\0\0\nz\0\0\x5\xc2\0\0\0\0\0\0\0\0\v\xb8)
...
[rivergis]
...
mainWindow\geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x5\xcc\0\0\x2o\0\0\vH\0\0\x5\xe6\0\0\x5\xd8\0\0\x2\xa3\0\0\v<\0\0\x5\xda\0\0\0\0\0\0\0\0\v\xb8)
...
[DB_Manager]
...
mainWindow\geometry="@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\a1\0\0\x2)\0\0\v\x1f\0\0\x5\xd6\0\0\a=\0\0\x2]\0\0\v\x13\0\0\x5\xca\0\0\0\0\0\0\0\0\v\xb8)
---

From the Windows Start menu, I asked to open my last project - opened default view, not project, at:
x 1047 y 695, x 2091, y 1294, 1045 x 600 (in 3000 x 2000 space; after scaling that is unbearably tiny!)

RiverGIS opened at:
1494 623, 2876 1499, 1383 x 877

DB_Manager opened at:
1852 553, 2836 1483, 985 x 931

I left QGIS unchanged, made RiverGIS and DBman taller... It is writing new ini files on every change of a sub window:

geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x3Y\0\0\x1>\0\0\n\x86\0\0\x5\xce\0\0\x3\x65\0\0\x1r\0\0\nz\0\0\x5\xc2\0\0\0\0\0\0\0\0\v\xb8)
(unchanged)

mainWindow\geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x6\x5\0\0\0\xf5\0\0\v\x81\0\0\x6\x6\0\0\x6\x11\0\0\x1)\0\0\vu\0\0\x5\xfa\0\0\0\0\0\0\0\0\v\xb8)

mainWindow\geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\a%\0\0\x1\x45\0\0\v\x13\0\0\x5\xb1\0\0\a1\0\0\x1y\0\0\v\a\0\0\x5\xa5\0\0\0\0\0\0\0\0\v\xb8)

Changing size of main window did not write ini file.
Opening a project did:

geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x3Y\0\0\x1>\0\0\n\x86\0\0\x5\xce\0\0\x3\x65\0\0\x1r\0\0\nz\0\0\x5\xc2\0\0\0\0\0\0\0\0\v\xb8)
(unchanged)

Saving project didn't change ini.
Exit QGIS did:

geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x1Q\0\0\0\xe5\0\0\t\xb4\0\0\x5N\0\0\x1]\0\0\x1\x19\0\0\t\xa8\0\0\x5\x42\0\0\0\0\0\0\0\0\v\xb8)
was:
geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x3Y\0\0\x1>\0\0\n\x86\0\0\x5\xce\0\0\x3\x65\0\0\x1r\0\0\nz\0\0\x5\xc2\0\0\0\0\0\0\0\0\v\xb8)

QGIS re-opened tiny, rewrote the ini before window appeared:

geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x1Q\0\0\0\xe5\0\0\t\xb4\0\0\x5N\0\0\x1]\0\0\x1\x19\0\0\t\xa8\0\0\x5\x42\0\0\0\0\0\0\0\0\v\xb8)
(unchanged from exit values)

QGIS now:
1047 695, 2091 1294, 1045 x 600
(same loc and size)

Resized, quit:

geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x4\f\0\0\x2\xb7\0\0\nT\0\0\x6\xce\0\0\x4\x18\0\0\x2\xeb\0\0\nH\0\0\x6\xc2\0\0\0\0\0\0\0\0\v\xb8)
(new values)

Wait!

Those are not escape chars, they are exactly the ASCII chars in the binary file.

I can read the first, non-geometry array:
@ByteArray(\0\0\0\xff\0\0\0\0\xfd\0\0\0\x3\0\0\0\0\0\0\x1\xb4\0\0\x3\xb9\xfc\x2\0\0\0\f\xfc
Except for that last "\f" they all look like "\x.." hex numbers.

But the window geometries I don't understand. The first line that doesn't change is numbers, but after that both the characters and their positioning seem random (I've converted the ones that look like numbers in the second column):

@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0
\x3Y\0\0
\x1>\0\0\n
\x86\0\0     134
\x5\xce\0\0    1486
\x3\x65\0\0    869
\x1r\0\0
\nz\0\0
\x5\xc2     1474
\0\0\0\0\0\0\0\0\v\xb8)

@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0
\x1Q\0\0\0
\xe5\0\0\t    229
\xb4\0\0     180
\x5N\0\0
\x1]\0\0
\x1\x19\0\0\t    281
\xa8\0\0    168
\x5\x42     1346
\0\0\0\0\0\0\0\0\v\xb8)

@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0
\x4\f\0\0    79
\x2\xb7\0\0    695
\nT\0\0
\x6\xce\0\0    1742
\x4\x18\0\0    1048
\x2\xeb\0\0    747
\nH\0\0
\x6\xc2     1730
\0\0\0\0\0\0\0\0\v\xb8)

@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0
\x6\x5\0\0\0    101
\xf5\0\0\v    245
\x81\0\0     129
\x6\x6\0\0    102
\x6\x11\0\0    1553
\x1)\0\0
\vu\0\0
\x5\xfa     1530
\0\0\0\0\0\0\0\0\v\xb8)

@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0
\x5\xcc\0\0    1484
\x2o\0\0
\vH\0\0
\x5\xe6\0\0    1510
\x5\xd8\0\0    1496
\x2\xa3\0\0    675
\v<\0\0
\x5\xda     1498
\0\0\0\0\0\0\0\0\v\xb8)

@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0
\a%\0\0\x1
\x45\0\0     69
\v\x13\0\0
\x5\xb1\0\0    1457
\a1\0\0
\x1y\0\0
\v\a\0\0
\x5\xa5     1445
\0\0\0\0\0\0\0\0\v\xb8)

@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0
\a1\0\0
\x2)\0\0\v
\x1f\0\0     31
\x5\xd6\0\0    1494
\a=\0\0
\x2]\0\0
\v\x13\0\0
\x5\xca     1482
\0\0\0\0\0\0\0\0\v\xb8)

So either I'm imagining a totally wrong scenario for how this works, or the geometry values are written as garbage. There is no set of positions that reliably decode to numeric values. Different positions look like numbers each time!

But this worked for two weeks! Wish I had a backup of AppData, but I don't. I also can't imagine how setting QGIS as default app for shapefiles could have changed this, but something about that session did...

#4 Updated by Loren Amelang over 6 years ago

It is working again! For no known reason, it has begun saving window size and position, like it did at first.

Current Geometry:
geometry="@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x1Q\0\0\0\x8e\0\0\n,\0\0\x6\xa4\0\0\x1]\0\0\0\xc2\0\0\n \0\0\x6\x98\0\0\0\0\0\0\0\0\v\xb8)"

Failing Geometry:
geometry=@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x4\f\0\0\x2\xb7\0\0\nT\0\0\x6\xce\0\0\x4\x18\0\0\x2\xeb\0\0\nH\0\0\x6\xc2\0\0\0\0\0\0\0\0\v\xb8)

Spaced to match:

(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x1Q\0\0\0...\x8e\0\0\n,\0\0\x6\xa4\0\0\x1]\0  \0\0...\xc2\0\0\n \0\0\x6\x98\0\0\0\0\0\0\0\0\v\xb8)
(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x4 \f\0\0\x2\xb7\0\0\nT\0\0\x6\xce\0\0\x4 \x18\0\0\x2\xeb\0\0\nH\0\0\x6\xc2\0\0\0\0\0\0\0\0\v\xb8)

Could the added "\x2" bytes under the "..." sections be the problem? There are still things that don't look to me like hex bytes, even when it is working...

Did posting it here remove the double quotes from my "Failing" example? Let's see:

Working Regular text:
geometry="@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x1Q\0\0\0\x8e\0\0\n,\0\0\x6\xa4\0\0\x1]\0\0\0\xc2\0\0\n \0\0\x6\x98\0\0\0\0\0\0\0\0\v\xb8)"

With Pre tag:

geometry="@ByteArray(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x1Q\0\0\0\x8e\0\0\n,\0\0\x6\xa4\0\0\x1]\0\0\0\xc2\0\0\n \0\0\x6\x98\0\0\0\0\0\0\0\0\v\xb8)"

Preview says no... Maybe missing double quotes on the "Failing" byte array was the problem?

#5 Updated by Loren Amelang over 6 years ago

I've been watching this... It seems to save the position for awhile, and then stop saving for awhile. No clue what triggers the changes. But I've been logging the byte arrays. I've added spaces here to try to align parts that seem to match (but the changes in pattern still make no sense to me):

good?(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x1Q   \0\0\0\x8e \0\0\n,   \0\0\x6\xa4\0\0\x1]\0  \0\0...\xc2\0\0\n    \0\0\x6\x98\0\0\0\0\0\0\0\0\v\xb8)
bad  (\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x3Y     \0\0\x1> \0\0\n\x86\0\0\x5\xce\0\0\x3\x65 \0\0   \x1r\0\0\nz   \0\0\x5\xc2\0\0\0\0\0\0\0\0\v\xb8)
bad  (\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x1Q   \0\0\0\xe5 \0\0\t\xb4\0\0\x5N   \0\0\x1]    \0\0\x1\x19\0\0\t\xa8\0\0\x5\x42\0\0\0\0\0\0\0\0\v\xb8)
bad  (\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x4 \f\0\0\x2\xb7 \0\0\nT   \0\0\x6\xce\0\0\x4\x18 \0\0\x2\xeb\0\0\nH   \0\0\x6\xc2\0\0\0\0\0\0\0\0\v\xb8)
bad  (\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x1N   \0\0\0\x9a \0\0\nl   \0\0\a \x88\0\0\x1Z\0  \0\0   \xce\0\0\n`   \0\0\a|    \0\0\0\0\0\0\0\0\v\xb8)
bad  (\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x1v  \0\0\x1\xaf \0\0\t\x81\0\0\x6H   \0\0\x1\x82 \0\0\x1\xe3\0\0\tu   \0\0\x6<   \0\0\0\0\0\0\0\0\v\xb8)
bad  (\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x1J   \0\0\0\xe0 \0\0\tu   \0\0\x6~   \0\0\x1V    \0\0\x1\x14\0\0\ti   \0\0\x6r   \0\0\0\0\0\0\0\0\v\xb8)
good"(\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x2\x31\0\0\0\xc9 \0\0\nD   \0\0\x5\xb8\0\0\x2=    \0\0\0\xfd \0\0\n8   \0\0\x5\xac\0\0\0\0\0\0\0\0\v\xb8)" 
good (\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x1\x88\0\0\0\xe0 \0\0\n%   \0\0\x6\x15\0\0\x1\x94 \0\0\x1\x14\0\0\n\x19\0\0\x6\t  \0\0\0\0\0\0\0\0\v\xb8)
good (\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x3%     \0\0\x2G \0\0\v\xc2\0\0\a|    \0\0\x3\x31 \0\0\x2{   \0\0\v\xb6\0\0\ap    \0\0\0\0\0\0\0\0\v\xb8) (same window size as above, different position?)
bad  (\x1\xd9\xd0\xcb\0\x2\0\0\0\0\x1\xeb\0\0\0\xf0 \0\0\v\xc3\0\0\x6\xe4\0\0\x1\xf8 \0\0\x1*   \0\0\v\xb6\0\0\x6\xd7\0\0\0\0\0\0\0\0\v\xb8)

Note - the "good" / "bad" report and copy of byte array is taken just after opening QGIS...
Double-quote status for first "good?" sample was not recorded (quotes were rare),
later samples show the " symbol if present, or nothing.
Obviously can work without quotes...

Is there anything else I should be watching to try to understand this?

Also available in: Atom PDF