[BUG]: All labels deleted when synching folders (despite RSS service doesn't even support labels)

[ghost]

Brief description of the issue.

When synching folders and other items with Nextcloud News, to account for new feed subscriptions, all existing labels get deleted.

How to reproduce the bug?

1. Add a Nextcloud News account (if there is none yet)
2. In RSS Guard, manually create a label under that account
3. Execute "Synchronize folders & other items" for that account
4. The label (and all others that were previously created) are gone

What was the expected result?

Never delete labels that were manually created. Especially when the configured RSS service does not even support labels that would need, or allow for, syncing.

What actually happened?

All labels deleted, tedious work to recreate them upon every new feed subscription in Nextcloud News that I want RSS Guard to pick up, via a sync.

Other information

• OS: Kubuntu 20.04
• RSS Guard version: 3.9.2

[martinrotter]

Wow what a cute bug it is.

[martinrotter]

Will fix for 4.0.0 for sure, serious flaw.

[martinrotter]

the issue is now fixed, there are some follow-up problems which i will fix too, but now you can test

test with development build please

[ghost]

Seems to be fixed. Needed to delete config dir "RSS Guard 4" though, since v4 imported some stuff from v3.9.2, but lost account passwords (and several other things, like filters, message display [msgs still in database, though], ...). Simply adding the password again passed the connection test, but resulted in a crash when I closed the dialog.

So, deleted v4.0.0 config dir, started from scratch and labels were preserved when I added a new feed, synced folders, removed feed and synced again.

I hope the final release of v4.0.0 will seamlessly handle database migration from v3.9.2?

For the time being, I'll export the labels to CSV and re-import them, via SQLite Studio. Currently, I'm assigning the labels via filters, so this can be restore by running them again, but it's a painful workaraound.

[martinrotter]

since v4 imported some stuff from v3.9.2

Very unlikely, RSS Guard 4.0.0 never ever automatically touches anything from 3.x, it uses different folders to keep settings/DB.

Yes, at this point DB file from 3.x is not compatible for 4.x and database migration will probably be impossible, like for 99%.

If you are bit profficient with SQLite, then you can however perform the transition by yourself as some tables are in fact untouched - eg "Messages". Some basic copy-paste in SQlitestudio (which i use too, great app) will make things ok.

Simply adding the password again passed the connection test, but resulted in a crash when I closed the dialog.

Is this somehow reproducible? Could you pin-point list of steps to reproduce?

This is related to the fact that v4 DB file is hugely incompatible with v3.

[ghost]

v4 does not import anything automatically, yes. I used "Restore settings" and picked a v3.9.2 backup, and since v4 did not outright refuse to restore a backup from on older version, I was assuming that restoring was possible, and the resulting issues were simply todos.

I had already copied over the tables MessageFilter and Labels after your assurance that my data would not actually burn in hell... and it worked.

So far, devbuild 4f6ec40 works for me, except for some cosmetic issues.
Not sure whether it's worth to file a bug for these, already (e.g.: not all icon themes installed on my machine work in the toolbar, for instance, WhiteSur does, but Papirus doesn't; feed updating progress bar can't accommodate long feed names and line-breaks; columns of message list don't auto-adjust their width, when necessary)

[martinrotter]

Yes, those tables can be copied, I will probably write some semi-DIY SQL script to perform partial migration, so that advanced users like you could migrate atleast some data.

not all icon themes installed on my machine work in the toolbar

What does it mean that icon theme does not "work" in toolbar. You mean that buttons have no icons? Like all buttons? What Linux distro, how installed RSS Guard?

feed updating progress bar can't accommodate long feed names and line-breaks

Yes, but overally it does not look that bad, it is just informative progress bar anyway.

columns of message list don't auto-adjust their width, when necessary

You cannot set all columns to "fit", that's just not possible. Check the code.

RSS Guard sets some columns to fit the contents, rest of columns are "interactive" - resizable and their order and size is remembered persistently.

[ghost]

The buttons have icons, but while I can clearly recognize, e.g., WhiteSur, gnome, and ubuntu-mono-light icon themes when I set them in RSS Guard, the Papirus icons do not resemble what I know from Papirus. Distro is Kubuntu 20.04 LTS, running rssguard-devbuild-4f6ec403-nowebengine-linux64.AppImage.

My C++ days are over by 20+ years now, so, sadly, I can't fully check the code you asked me to :) What I mean is that I'm used to columns remembering their order and respective relative widths; the behavior right now is a bit unusual: I keep the internal browser window at the right border (not at the bottom), and when no message is shown, the columns of the message list just stay where they are, leaving a huge blank space where the internal browser view was.

I'd expected the columns to fill that space, while preserving their relative widths. Same thing happens when I switch the layout so the browser view is at the bottom: the message list doesn't expand to fill the gap. I just checked v3.9.2, and in both cases, the message list exapnds to fill the gap.

[martinrotter]

Key information right here.

I keep the internal browser window at the right border (not at the bottom), and when no message is shown, the columns of the message list just stay where they are, leaving a huge blank space where the internal browser view was.

Report as separate bug perhaps.

I just checked v3.9.2, and in both cases, the message list exapnds to fill the gap.

So you say it worked fine with 3.9.2 but does not work anymore with 4.0.0?

[sakkamade]

@rfkat

I'd expected the columns to fill that space, while preserving their relative widths.

Try removing this line in config #435 (comment)
Do you have similar content to what I had? No quotes?
If so, try adding the quotes.

the Papirus icons do not resemble what I know from Papirus

I am not too sure of what have happened here, nor how is it possible even.
What is the value in respective line of config, when you set Papirus? In this one icon_theme_name=..., that is.

Perhaps the because of

(..).AppImage.

?

Do you running it in firejail?
Even if not, the .AppImage is most likely cause.

[sakkamade]

Do you have Papirus installed system-wide or only for your user?
I.e. did you install it by package manager or manually extracted it to ~/.icons directory?

[martinrotter]

I had some problems with icons too, and sadly there is not much I can do. Basically everything I do is that I call special function which "sets" active icon theme by name. Everything else is automatic and THE function is known to sometimes have big problems.

https://bugreports.qt.io/browse/QTBUG-48121?jql=text%20~%20%22icon%20theme%22

[martinrotter]

I keep the internal browser window at the right border (not at the bottom), and when no message is shown, the columns of the message list just stay where they are, leaving a huge blank space where the internal browser view was.

Btw I was unable to reproduce the issue.

[martinrotter]

Also, I discovered the actual upstream method which is responsible for saving of state of list of messages and I am not happy.

https://code.qt.io/cgit/qt/qtbase.git/tree/src/widgets/itemviews/qheaderview.cpp?h=dev#n4077

The code saves also some unwanted things like out << stretchLastSection; and in this case, suggestions made by @sakkamade might actually work, especially remove proposed line from config.

[martinrotter]

Followup: I created experimental fix b81ac69. The fix now strictly saves only these properties of each column: visibility, sort order, width. It should work fine. You might cleanup your "config.ini" as @sakkamade states as new format of setting is not backwards compatible.

[sakkamade]

I keep the internal browser window at the right border (not at the bottom), and when no message is shown, the columns of the message list just stay where they are, leaving a huge blank space where the internal browser view was.

Btw I was unable to reproduce the issue.

This is only a consequence of the same string in config, hence the same issue.

[ghost]

@Sakkade: That's it!

Do you have Papirus installed system-wide or only for your user?
I.e. did you install it by package manager or manually extracted it to ~/.icons directory?

Purged per-user installed icon sets, and re-installed them system-wide. Now they work in RSS Guard.

[sakkamade]

re-installed them system-wide. Now they work in RSS Guard.

I guess this is a limitation of AppImage itself. It doesn't use much configuration from user's home directory.
I am compiling a packages and I have no such issues with them.
I wonder that RSS Guard can help it.
@martinrotter Can it?

[sakkamade]

@rfkat, Could you revert this change for a bit

Purged per-user installed icon sets, and re-installed them system-wide.

Start RSS Guard with rssguard --log ~/Desktop/guard-log.txt, and attach it here?

[ghost]

@sakkamade I've tried with both Lyra and Papirus icons locally installed, and I can't reproduce the error anymore, with any of the test binaries; the respective icons are correctly shown now. :-|

Binaries used for testing:

• rssguard-devbuild-88c75da5-nowebengine-linux64.AppImage
• rssguard-devbuild-4f6ec403-nowebengine-linux64.AppImage
• rssguard-3.9.2-407646a8-nowebengine-linux64.AppImage

The log files are quite large (9-19 MB) and include both my personal directory structure, as well as my RSS feed subscriptions in plain text. So I prefer not to make them available to others (in our case, there's no error msgs anyway).

I can't rule out that I broke the earlier icon install (that did not become visible in RSS Guard) when I did it manually. I've only recently switched to using ocs-url.