0003411: IDHiddenGroup and IDHiddenServerPointer are seen as visible columns

(0019164)
WubTheCaptain (developer)
2018-04-11 15:03

As far as I remember, Qt 5.9 is fine.

(0019332)
Pol M (developer)
2018-08-14 13:15

I can't reproduce this :(
Maybe a Qt update fixed it? the current version I'm running is: 5.11.1

(0019333)
Zalewa (developer)
2018-08-14 19:33

Quote
I can't reproduce this :(
Maybe a Qt update fixed it? the current version I'm running is: 5.11.1

I hope so. These columns were explicitly marked as hidden by us, so if Qt suddenly decided to show them then I'm sure it wasn't an intended behavior.

(0019335)
Zalewa (developer)
2018-08-15 08:38

I'll mark this as "needs further testing" with Qt 5.11.1 for the time being.

(0019341)
WubTheCaptain (developer)
2018-08-20 18:17

I'm still experiencing this issue as of commit aafacb71daee (1.2~beta-180816-2126M) in both Doomseeker 1.1 and 1.2~beta.

My Qt5 package version on Debian is now 5.11.1-5, so I don't know.

(0019342)
WubTheCaptain (developer)
2018-08-20 18:26

Attached dpkg-qt5-qt-libc.log has some relevant output from dpkg -l from the host system experiencing the issue.

(0019343)
WubTheCaptain (developer)
2018-08-20 18:36
edited on: 2018-08-20 18:36

After the following commands, I'm no longer able to reproduce:

mv $HOME/.doomseeker/ $HOME/.doomseeker.bak/ # Doomseeker 1.1 directory
mv $HOME/.config/doomseeker/ $HOME/.config/doomseeker.bak/
mv $HOME/.local/share/doomseeker/ $HOME/.local/share/doomseeker.bak/
mv $HOME/.cache/doomseeker/ $HOME/.cache/doomseeker.bak/

Some kind of a data corruption bug in Doomseeker?

(0019344)
Zalewa (developer)
2018-08-20 18:55

This is an useful hint. The state of the table's header is saved in config and then restored, which most likely pinpoints the error to the 'else' block in

void ServerListView::setupTableColumnWidths()

The hidden state for those columns needs to be enforced there too.

(0019354)
WubTheCaptain (developer)
2018-08-20 20:55

@Zalewa: Yes, another issue (surprisingly not mentioned yet) related to this bug is that the table column widths reset on every start of Doomseeker when the bug is present.

(0019355)
WubTheCaptain (developer)
2018-08-20 21:14
edited on: 2018-08-20 21:19

Attached doomseeker.ini reproduces the issue. Place it in Doomseeker configuration directory, which on GNU/Linux should be:

$HOME/.doomseeker/ directory on Doomseeker 1.1; or
$HOME/.config/doomseeker/ on Doomseeker 1.2~beta and later (after hg changeset 2146:908ed1778e0a or somewhere around there)

The cause of this is still unknown or random.

(0019368)
WubTheCaptain (developer)
2018-08-20 22:58

Unrelated note: Doomseeker 1.2~beta (aafacb71daee) just segfaulted on me on quit while testing this with broken state. I couldn't get a dump.

(0019378)
Zalewa (developer)
2018-08-21 16:21
edited on: 2018-08-21 16:22

I was able to reproduce this with Wub's config also in Qt 5.7.

Should be fixed with these 2 commits:

1.https://bitbucket.org/Doomseeker/doomseeker/commits/a2ed1f062be45feec33c7a52c5ba4e8863ae4eb2 [^]
2.https://bitbucket.org/Doomseeker/doomseeker/commits/3e1cbeb2dba8c72c3646923bab1c263b0bc4935d [^]

Please test.

(0019390)
WubTheCaptain (developer)
2018-08-24 00:29
edited on: 2018-08-24 00:36

If we have a corrupted state .ini, going from patched Doomseeker 1.2 to unpatched 1.1 the bug may still be reproduced. It's only seen as a non-issue in Doomseeker 1.2 visually, but we don't actually fix/reset the broken state (in the .ini), as Doomseeker:

inits with hidden status (hidden)
loads the config from saved state (possibly unhidden)
hides it in the layout again (hidden)

What could cause the corrupted state where a column suddenly becomes unhidden, I've not found yet. Switching between clean 1.2 and 1.1 configs and migrating them between the two (multiple times) shouldn't cause this issue – and doesn't in my experience with some testing.

Is there something more we could still do on the issue to prevent this? Practically this issue is kind of resolved now, although it may be seen as some sort of a small hack.

All the better if the hidden status was not part of the saved state (because we don't allow hiding any other columns, anyway), but I almost doubt Qt does not allow.

(0019391)
WubTheCaptain (developer)
2018-08-24 00:46

Quote from WubTheCaptain
Is there something more we could still do on the issue to prevent this? Practically this issue is kind of resolved now, although it may be seen as some sort of a small hack.

And I'm kind of okay with this.

(0019405)
Zalewa (developer)
2018-08-26 10:10

Quote from "WubTheCaptain"
Is there something more we could still do on the issue to [fix the config in new version of the program so that the old version can load it properly]? Practically this issue is kind of resolved now, although it may be seen as some sort of a small hack.

No.

The config should be saved with proper values when there's a reason to save the config. Try opening the config dialog and pressing the "Apply" button.

The user must expect that config saved by a new version of the program may not be fully backwards compatible with the old version of the program.

The user may open the config in a text editor and remove the broken setting manually, letting Doomseeker to recreate it. That's the reason why config is a text file - so that people can modify it with a text editor when they feel it's necessary.

Unless there's still some problem with this issue in the current HEAD, I don't plan to spend any more time on it.

This issue is already marked as resolved. If you feel that is not the case, please reopen it and explain why.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2018-04-11 14:53	WubTheCaptain	New Issue
2018-04-11 14:53	WubTheCaptain	File Added: 2018-04-11-143553_1032x247_scrot.png
2018-04-11 15:03	WubTheCaptain	Note Added: 0019164
2018-08-14 13:15	Pol M	Note Added: 0019332
2018-08-14 19:33	Zalewa	Note Added: 0019333
2018-08-15 08:38	Zalewa	Note Added: 0019335
2018-08-15 08:38	Zalewa	Assigned To	=> Zalewa
2018-08-15 08:38	Zalewa	Status	new => needs testing
2018-08-20 18:17	WubTheCaptain	Note Added: 0019341
2018-08-20 18:17	WubTheCaptain	Status	needs testing => acknowledged
2018-08-20 18:20	WubTheCaptain	File Added: dpkg-qt5-qt-libc.log
2018-08-20 18:22	WubTheCaptain	Status	acknowledged => new
2018-08-20 18:26	WubTheCaptain	Note Added: 0019342
2018-08-20 18:36	WubTheCaptain	Note Added: 0019343
2018-08-20 18:36	WubTheCaptain	Status	new => feedback
2018-08-20 18:36	WubTheCaptain	Note Edited: 0019343	View Revisions
2018-08-20 18:39	WubTheCaptain	Assigned To	Zalewa => WubTheCaptain
2018-08-20 18:39	WubTheCaptain	Status	feedback => assigned
2018-08-20 18:55	Zalewa	Note Added: 0019344
2018-08-20 18:55	Zalewa	Assigned To	WubTheCaptain => Zalewa
2018-08-20 20:55	WubTheCaptain	Note Added: 0019354
2018-08-20 21:01	WubTheCaptain	Reproducibility	have not tried => random
2018-08-20 21:11	WubTheCaptain	File Added: doomseeker.ini
2018-08-20 21:14	WubTheCaptain	Note Added: 0019355
2018-08-20 21:19	WubTheCaptain	Note Edited: 0019355	View Revisions
2018-08-20 21:32	WubTheCaptain	Additional Information Updated	View Revisions
2018-08-20 22:58	WubTheCaptain	Note Added: 0019368
2018-08-21 16:21	Zalewa	Note Added: 0019378
2018-08-21 16:21	Zalewa	Status	assigned => needs testing
2018-08-21 16:22	Zalewa	Note Edited: 0019378	View Revisions
2018-08-24 00:29	WubTheCaptain	Note Added: 0019390
2018-08-24 00:29	WubTheCaptain	Status	needs testing => needs review
2018-08-24 00:36	WubTheCaptain	Note Edited: 0019390	View Revisions
2018-08-24 00:46	WubTheCaptain	Note Added: 0019391
2018-08-24 03:30	WubTheCaptain	Relationship added	related to 0003463
2018-08-26 10:10	Zalewa	Note Added: 0019405
2018-08-26 10:10	Zalewa	Status	needs review => resolved
2018-08-26 10:10	Zalewa	Fixed in Version	=> 1.2
2018-08-26 10:10	Zalewa	Resolution	open => fixed

Notes
(0019164) WubTheCaptain (developer) 2018-04-11 15:03	As far as I remember, Qt 5.9 is fine.

(0019332) Pol M (developer) 2018-08-14 13:15	I can't reproduce this :( Maybe a Qt update fixed it? the current version I'm running is: 5.11.1

(0019333) Zalewa (developer) 2018-08-14 19:33	Quote I can't reproduce this :( Maybe a Qt update fixed it? the current version I'm running is: 5.11.1 I hope so. These columns were explicitly marked as hidden by us, so if Qt suddenly decided to show them then I'm sure it wasn't an intended behavior.

(0019335) Zalewa (developer) 2018-08-15 08:38	I'll mark this as "needs further testing" with Qt 5.11.1 for the time being.

(0019341) WubTheCaptain (developer) 2018-08-20 18:17	I'm still experiencing this issue as of commit aafacb71daee (1.2~beta-180816-2126M) in both Doomseeker 1.1 and 1.2~beta. My Qt5 package version on Debian is now 5.11.1-5, so I don't know.

(0019342) WubTheCaptain (developer) 2018-08-20 18:26	Attached dpkg-qt5-qt-libc.log has some relevant output from dpkg -l from the host system experiencing the issue.

(0019343) WubTheCaptain (developer) 2018-08-20 18:36 edited on: 2018-08-20 18:36	After the following commands, I'm no longer able to reproduce: mv $HOME/.doomseeker/ $HOME/.doomseeker.bak/ # Doomseeker 1.1 directory mv $HOME/.config/doomseeker/ $HOME/.config/doomseeker.bak/ mv $HOME/.local/share/doomseeker/ $HOME/.local/share/doomseeker.bak/ mv $HOME/.cache/doomseeker/ $HOME/.cache/doomseeker.bak/ Some kind of a data corruption bug in Doomseeker?

(0019344) Zalewa (developer) 2018-08-20 18:55	This is an useful hint. The state of the table's header is saved in config and then restored, which most likely pinpoints the error to the 'else' block in void ServerListView::setupTableColumnWidths() The hidden state for those columns needs to be enforced there too.

(0019354) WubTheCaptain (developer) 2018-08-20 20:55	@Zalewa: Yes, another issue (surprisingly not mentioned yet) related to this bug is that the table column widths reset on every start of Doomseeker when the bug is present.

(0019355) WubTheCaptain (developer) 2018-08-20 21:14 edited on: 2018-08-20 21:19	Attached doomseeker.ini reproduces the issue. Place it in Doomseeker configuration directory, which on GNU/Linux should be: $HOME/.doomseeker/ directory on Doomseeker 1.1; or $HOME/.config/doomseeker/ on Doomseeker 1.2~beta and later (after hg changeset 2146:908ed1778e0a or somewhere around there) The cause of this is still unknown or random.

(0019368) WubTheCaptain (developer) 2018-08-20 22:58	Unrelated note: Doomseeker 1.2~beta (aafacb71daee) just segfaulted on me on quit while testing this with broken state. I couldn't get a dump.

(0019378) Zalewa (developer) 2018-08-21 16:21 edited on: 2018-08-21 16:22	I was able to reproduce this with Wub's config also in Qt 5.7. Should be fixed with these 2 commits: 1.https://bitbucket.org/Doomseeker/doomseeker/commits/a2ed1f062be45feec33c7a52c5ba4e8863ae4eb2 [^] 2.https://bitbucket.org/Doomseeker/doomseeker/commits/3e1cbeb2dba8c72c3646923bab1c263b0bc4935d [^] Please test.

(0019390) WubTheCaptain (developer) 2018-08-24 00:29 edited on: 2018-08-24 00:36	If we have a corrupted state .ini, going from patched Doomseeker 1.2 to unpatched 1.1 the bug may still be reproduced. It's only seen as a non-issue in Doomseeker 1.2 visually, but we don't actually fix/reset the broken state (in the .ini), as Doomseeker: inits with hidden status (hidden) loads the config from saved state (possibly unhidden) hides it in the layout again (hidden) What could cause the corrupted state where a column suddenly becomes unhidden, I've not found yet. Switching between clean 1.2 and 1.1 configs and migrating them between the two (multiple times) shouldn't cause this issue – and doesn't in my experience with some testing. Is there something more we could still do on the issue to prevent this? Practically this issue is kind of resolved now, although it may be seen as some sort of a small hack. All the better if the hidden status was not part of the saved state (because we don't allow hiding any other columns, anyway), but I almost doubt Qt does not allow.

(0019391) WubTheCaptain (developer) 2018-08-24 00:46	Quote from WubTheCaptain Is there something more we could still do on the issue to prevent this? Practically this issue is kind of resolved now, although it may be seen as some sort of a small hack. And I'm kind of okay with this.

(0019405) Zalewa (developer) 2018-08-26 10:10	Quote from "WubTheCaptain" Is there something more we could still do on the issue to [fix the config in new version of the program so that the old version can load it properly]? Practically this issue is kind of resolved now, although it may be seen as some sort of a small hack. No. The config should be saved with proper values when there's a reason to save the config. Try opening the config dialog and pressing the "Apply" button. The user must expect that config saved by a new version of the program may not be fully backwards compatible with the old version of the program. The user may open the config in a text editor and remove the broken setting manually, letting Doomseeker to recreate it. That's the reason why config is a text file - so that people can modify it with a text editor when they feel it's necessary. Unless there's still some problem with this issue in the current HEAD, I don't plan to spend any more time on it.