Column sizing in search window broken

[uwemock]

Starting with version 0.35, the search window opens up with unusable column sizes. The third column, containing something like the note filename, occupies way too much space, leaving only little space for the "Name" and "Last Change" columns. However, I'm rarely interested in a note's filename. The "Name" and "Last Change" columns are much more important. These colums should be assigned most of the available width.

[davidbannon]

Yes, thats not intentional. But 0.35 has a lot of changes wrt that ListView. I am not seeing on my day to day systems, what OS (and widgetset, desktop if applicable) do you use ? It might be a DPI scaling issue...

Davo

[uwemock]

This is Plasma on Kubuntu 20.04 and 22.04.

[davidbannon]

Hmm, I don't have a Kubuntu VM right now, I am not seeing it on either Gnome or Mate desktops, just tried. More I think about it, more I think its DPI issue. Is your screen a hires one ? Do you know the resolution ? Davo

[uwemock]

I have standard displays with 1920x1080 on my desktop PC and 1366x768 on my laptop.

[davidbannon]

uwemock, I have not forgotten this issue, just been very busy ..... Davo

[davidbannon]

OK uwemock, I have tried this in a VM and do not see the issue you mention. The actual code that scales the columns in the Notes ListView is pretty old, has not changed for several versions, so there is something else happening here. So, some more questions (sorry !) -

1. I assume you are using the Qt5 version ?
2. I assume you mean the component in the lower right of the search window, the one with column heading of "name" and "last change" ? From your description above I am pretty sure we are discussing the same thing but to be sure ....
3. If you scale the Search Window, grab bottom right corner and move in or out, does it still show the file names ?
4. Could you send me a screen shot please ?
5. If I sent you a binary with some extra debug info, would you run it (from the command line) and send back the few lines of logging generated every time the window is scaled. Note, you do not need to install this debug version !

Thanks ! Davo

[uwemock]

1. I'm using the GTK2 version.
2. Correct.
3. When I resize the search window, the columns resize and I don't see the filenames any more.
4. I'll attach a screenshot.
5. Sure.

[davidbannon]

Oh, wow, thats hopeless, isn't it ? I have no idea what is happening here !

Attached is a tar.gz containing a new binary, its a GTK2 0.35 with a few extras but importantly, logs to console every time the Search Window is first displayed and then resized. A handful of lines each time. Please untar, and run the binary, you must first stop your existing tomboy-ng and you must run this one from the command line. eg - ./tomboy-ng

Now, please watch the console as it starts up. You should see nothing (or very little) until you open the Search Window, then you will get one block of log lines. If you do not see that block of loglines when displaying the window, thats important.

Then resize the search window and you will see (probably) several more blocks. (you may now close the app).

Please send me, at least, the first and last block.

Thanks for helping with this.

David tomboy-ng.tar.gz

[uwemock]

With the binary you sent me, the search window comes up with proper column sizing...

Here we go with the the log:

TSearchForm.ScaleListView Clientwidth=560 Col-0=421 Col-1=139 Col-2=1 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=562 Col-0=423 Col-1=139 Col-2=2 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=565 Col-0=426 Col-1=139 Col-2=3 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=568 Col-0=429 Col-1=139 Col-2=3 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=571 Col-0=432 Col-1=139 Col-2=3 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=573 Col-0=434 Col-1=139 Col-2=2 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=584 Col-0=445 Col-1=139 Col-2=11 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=593 Col-0=454 Col-1=139 Col-2=9 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=597 Col-0=458 Col-1=139 Col-2=4 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=602 Col-0=463 Col-1=139 Col-2=5 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=617 Col-0=478 Col-1=139 Col-2=15 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=622 Col-0=483 Col-1=139 Col-2=5 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=631 Col-0=492 Col-1=139 Col-2=9 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=640 Col-0=501 Col-1=139 Col-2=9 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=644 Col-0=505 Col-1=139 Col-2=4 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=648 Col-0=509 Col-1=139 Col-2=4 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=652 Col-0=513 Col-1=139 Col-2=4 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=656 Col-0=517 Col-1=139 Col-2=4 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=666 Col-0=527 Col-1=139 Col-2=10 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=670 Col-0=531 Col-1=139 Col-2=4 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=673 Col-0=534 Col-1=139 Col-2=3 Text W=139 Text QT5=155 TSearchForm.ScaleListView Clientwidth=674 Col-0=535 Col-1=139 Col-2=1 Text W=139 Text QT5=155

[davidbannon]

With the binary you sent me, the search window comes up with proper column sizing...

Huh ? Are you saying that this test binary solved the problem ? Those numbers are showing what they should ....

(going to look back across recent commits ....)

Davo

[uwemock]

Are you saying that this test binary solved the problem?

Yes!

[davidbannon]

OK, that is officially crazy ! There has been no change to the relevant code since before 0.35 came out, indeed, noting relevant to this issue for a lot longer ! Here, attached, is another binary, this time a ready to use one, that is, it does not generate logs when you resize the search window. Please test it from the command line and if it also fixes this bug, if you are happy to do so, put it in place of your existing /usr/bin/tomboy-ng and test that !

Strange business .... tomboy-ng.tar.gz

[uwemock]

Works. Thanks.

I noticed that the new executable is significantly smaller than the previous one (~7MB -> ~5MB).

[davidbannon]

hmm, stranger and stranger. Built with different compilers, I use the 'risky' trunk version when developing, but for release, I use a formally released version (of the compiler). But I am surprised and will investigate all of this ! Thanks for reporting and helping but you have left me with a real mystery (or two) ! Davo

[davidbannon]

Hey, I just realised what I have just done, you now have a development version of tomboy-ng, it will probably have BUGS !!!

In particular, I have changed the way the search works, when you open the window focus should be moved to the search field as soon as you start typing, in fact, you loose the first character ;-(

I am pretty certain there is no chance of loosing any data but UI things are under dev, please update to 0.35a as soon as I release it ! (Now, that better be soon....)

Davo

[davidbannon]

URGENT

Hmm, we have a problem uwemock, the binary that went out with tomboy-ng 0.35 in a 64bit deb package was 5,658,536 bytes. If yours was about 7Meg, then it did not come from that package. Now we need to ask from where it did come from ? And, maybe ask what extra little goodies it had in it ?

I guess you downloaded it from github ? It should be called tomboy-ng_0.35-0_amd64.deb ? Do you still have that package there ? Incidentally, it should be 1654812 bytes ....

If you still have it, could you please send it to me, this is quite concerning ....

Davo

[uwemock]

I don't download Tomboy as a deb package any more. My previous version came from your repository, and it was version 0.35-2.

[davidbannon]

I have only released a 0.35-2 as an rpm, not a deb, the current deb is tomboy-ng_0.35-0_amd64.deb. You are using KUbuntu right ? You would have needed a deb to install on any Ubuntu. The Debian Bookworm deb is 0.35-1 so it cannot be from there.

the number after the "0.35-" is a packaging number, should contain the same binary (5.6meg). But as I said, I have not even released a 0.35-2 deb.

I am a bit worried that you may have got it from somewhere masquerading as my github site. And that is a worry.

David

[uwemock]

The version number comes from my package manager, so there must have been a deb package with that version number. The repository is at http://ppa.launchpad.net/d-bannon/ppa-tomboy-ng/ubuntu/.

Version 0.35-2 is even listed in the packages overview.

[davidbannon]

Ah, the PPA. Of course. Thats a relief ! Yep, the PPA has 0.35-2, repackaged because of PPA (expletive deleted) requirements ! And yes, the binary is 7 meg, must be something wrong with my workflow there but nothing you need to worry about ! Sorry, was getting a bit panicky there for a minute. All good. I might run some tests with that PPA binary and see if I can explain what we see. Thanks for your help and patience ! Davo

[davidbannon]

No sign of this problem in the newly released 0.35a but I an yet to release 0.35a as a PPA, will do so as soon as I can but the PPA is hard work ! Davo

[davidbannon]

uwemock, I am guessing you are no longer seeing the problem you reported here ? The PPA will have pushed 0.36c to you ....

Davo

[uwemock]

Correct

[davidbannon]

Good, lets close this ticket. Davo