#1674 "Save as.." dialog navigation panel bookmarks are not remembered

[musewhirl]

Steps to reproduce in RG v23.12:

1. Select File/Save as...to open the "Save as..." dialog
2. Drag any folder to the left bookmark navigation panel
3. Actually saving the session or not does not appear to matter
4. Re-open the "Save as..." dialog and the bookmark is gone

I'm not sure if this is just a local OS issue, but for other applications on the same computer, when a "Save dialog" is later opened again, the bookmark is still available.

Under Edit/Preferences/General/Presentation there is a check box labeled: "Use native dialogs". I have what I believe is the default i.e. it's checked. But unchecking it does not change the above behavior, and I'm not sure it has anything to do with the bookmark behavior anyway.

[Philip Leishman]

I have the "Use native dialogs" checked and bookmarks seem to work fine for me (bookmarks menu). I can create them and on restating rosegarden they are still there. This may be a system issue - I am using kde - the bookmarks are then stored in a file called $HOME/.local/share/kfile/bookmarks.xml

[musewhirl]

Looks like a local issue then. I know I've seen bookmarks in dialogs but haven't noted exactly when. Some could have been Open dialogs because that is often when a bookmark comes in even more handy.

I will keep this ticket open a while longer to see if I can find a pattern.

Thanks for letting me know that it works for you since that narrows things down a bit.

[musewhirl]

I'm using the latest Debian. On my system, bookmarks are stored under the shortcuts entry in
~/.config/QtProject.conf
RG is using that file for its dialog. I identified another application which does work correctly i.e. qpdfview, which also uses that entry in the same file.

In qpdfview, when the bookmark is added to the left panel, on closing the dialog (either after usage or just Cancel), the shortcuts entry is updated in the file. It remembers the bookmark when opened again, even if the application is closed and restarted...UNLESS RG's file dialog is used in the mean time. If so, the bookmark disappears even if qpdfview is actually open.

In RG, if the file dialog is opened, it does not contain the bookmark which was added by qpdfview. It only contains the following, which have are always been there for me at least, even though I didn't put them there:

my home directory
examples (./local/share/rosegarden/examples)
templates (./local/share/rosegarden/templates)
downloads (my download directory)
rosegarden (for some reason / i.e. the root directory)

During the open, the file is not updated i.e. qpdfview's bookmark is there. However, on canceling the file dialog, RG appears to overwrite the conf file and now the bookmark is not only missing from the file, but immediately missing from qpdfview, even though that application is still open. Attempting to re-add the missing bookmark (or any bookmark) beforehand does not work either.

As another test, I deleted the QtProject.conf file, opened RG and it is indeed the application which first created that file...it looked exactly the same as mentioned above i.e. with rosegarden entries. I deleted it again, and this time opened qpdfview first. Now the file only contains:

Computer
my home directory

Using just qpdfview, everything works as expected i.e. bookmarks are added, the file is updated and they are remembered.

Starting RG has no immediate effect on QtProject.conf. Neither does opening the dialog. But it did not read the untouched shortcuts entry in the file which now do not contain anything to do with rosegarden...it appears with the entries shown for it above, as though hard-coded and ready to slam the file. And on Cancel (or just using the dialog) that is exactly what it does.

I suggest that at least in my case, RG is not first reading the shortcuts entry and appending to it, if necessary. Hence on closing, it always ends up with the same entry that would be there if QtProject.conf never existed.

From the above, it seems to be an RG bug because qpdfview behaves normally in the same environment. If you are using native dialogs specific to KDE, and they do not involve Qt or this conf file, then perhaps a different code path occurs?

[musewhirl]

If this does turn out to be something to fix in RG, I should have mentioned that in my case, both Audacity and Audacious store their bookmarks in:
~/.config/gtk-3.0/bookmarks
I didn't knowing configure them to do that any more than I did for RG to use QtProject.conf. I assume this is all default behavior, along with the GTK+ vs Qt frameworks. So, if there is some way to configure RG to use GTK3's bookmarks, let me know, because in my mind, I align RG more with Audacity and Audacious than I do with QPDFView.

[Philip Leishman]

I have always used kde but I have a virtual machine with gnome.
I get the same results - bookmarks not working.
Then I found https://wiki.archlinux.org/title/Uniform_look_for_Qt_and_GTK_applications
There it says - install qt5-styleplugins and set the environment variable:
export QT_QPA_PLATFORMTHEME=gtk2
That seemed to work for me. I don't think we can do anything in the rosegarden code but if the above works for you then that is the workaround

[musewhirl]

Just for other readers, I'll add the missing typo for the package

qt5-style-plugins

It didn't work for me, probably because although I use Debian on that particular box, I do not use a desktop environment. I just use Openbox as a window manager to conserve resources.

The fact that RG dependencies include Qt libraries, whereas Audacity and Audacious both rely on GTK+ doesn't bother me, since GUI themes do not make music sound any better. However, the overwriting of the QtProject.conf file presents a problem. It's a shared file, which means that folks who even review RG will lose all there bookmarks, history etc with no means of recovery. This could of course still be due to my local environment and this issue existed even back in v18.12...obviously no one has mentioned it.

The only facts are:
* qpdfview depends on the same QT libraries as RG, but it does not overwrite Qtproject.conf
* qpdfview has no obvious configuration regarding overwriting QtProject.conf
* RG also has no such configuration, as I had assumed since the preferences checkbox simply says "Use native widgets", not which ones or how.
* The overwritten QtProject.conf always has default RG settings, even if they were never there previously, implying it originated with RG
* Unwanted overwriting occurs while using RG, not while using qpdfview
* And just from my perspective, I can accept the current file dialog theme since I'm only interested in its function

That's all so far, and in all my searching, the only hint at a clue might be the following link in a QT bug report. It's been around for years, and only resolved in December 2023. It's more than a long shot, and may well be unrelated.

https://bugreports.qt.io/browse/QTBUG-36657?focusedCommentId=251963&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel

Hopefully, it should not be too difficult to check RG code against the bug report to make sure that the hand-off to "Use native widgets" is actually being honored.

If all looks fine, then I am satisfied with closing this problem as being outside the province of RG.

[musewhirl]

One more question. Since the last post, I decided to take a quick look at the code. In FileDialog.cpp, I see where the urls for home, examples and templates are set using setSidebarUrls(). However, I see no place where the current urls in the QtProject.conf file are actually read. I would expect there to be a merge/append with these, unless the function always does that automatically or the instantiation of the FileDialog handles it? Have I missed something?

FileDialog::FileDialog(QWidget *parent,
                       const QString &caption,
                       const QString &dir,
                       const QString &filter,
                       QFileDialog::Options options) :
        QFileDialog(parent,
                    caption,
                    dir,
                    filter)
{
    setOptions(options);

    // set up the sidebar stuff; the entire purpose of this class 
    QList<QUrl> urls;

#if QT_VERSION >= 0x050000
    QString home = QStandardPaths::writableLocation(QStandardPaths::HomeLocation);
#else
    QString home = QDesktopServices::storageLocation(QDesktopServices::HomeLocation);
#endif
    QString examples = home + "/.local/share/rosegarden/examples";
    QString templates = home + "/.local/share/rosegarden/templates";
    QString rosegarden = home + "/rosegarden";

    RG_DEBUG  << "FileDialog::FileDialog(...)"
              << "     using paths:  examples: " << examples << "\n"
              << "                  templates: " << templates << "\n"
              << "                 rosegarden: " << rosegarden;

    urls << QUrl::fromLocalFile(home)
         << QUrl::fromLocalFile(examples)
         << QUrl::fromLocalFile(templates)
#if QT_VERSION >= 0x050000
         << QUrl::fromLocalFile(QStandardPaths::writableLocation(QStandardPaths::DocumentsLocation))
         << QUrl::fromLocalFile(QStandardPaths::writableLocation(QStandardPaths::MusicLocation))
#else
         << QUrl::fromLocalFile(QDesktopServices::storageLocation(QDesktopServices::DocumentsLocation))
         << QUrl::fromLocalFile(QDesktopServices::storageLocation(QDesktopServices::MusicLocation))
#endif
         << QUrl::fromLocalFile(rosegarden)
         ; // closing ; on this line to allow the lines above to be shuffled easily

    setSidebarUrls(urls);
}

[Philip Leishman]

My understanding is that the sidebar for the urls is only used if the native dialog is not used!
If the native dialog is used you must set your own bookmarks.
I don't understand why the style plugin does not work for you. Did you remember to set the environment variable before starting rosegarden ?

[musewhirl]

Success! I'm glad you raised the question again. Originally, I had set the environment variable, and forgot to install the plugins. I immediately realized and looked at the long list of dependencies. I thought that I might end up with more Qt style config files than I bargained for. So, since this was an experiment, I switched to a different box and installed the plugins there...but then I forgot the environment variable over there, because in my mind I had already placed the environment variable in my .profile and even checked env shortly before :-)

So now I have it all...the bookmarks are identical and remembered between both RG and qpdfview and both have the gtk theme.

As an aside, it was curious that this new list of bookmarks is only a subset of those previously mentioned for Audacity and Audacious which were located in ~/.config/gtk-3.0/bookmarks. Now however, Audacious has changed to this new subset, losing its other entries, but Audacity is unaffected. I thought it might be because the environment variable was set to gtk2. But then using gtk3 (and even gtk+) resulted in the old QtProject.conf behavior. Perhaps it's because Audacity specifically mentioned gtk3 dependencies. Also, I cannot locate where this new list of shared bookmarks is being kept...although it's not those in QtProject.conf, and I could not find it in .config or .local. But that doesn't matter...it works.

Conclusion: the workaround does work as you originally suggested when both qt5-style-plugins is installed AND the environment variable QT_QPA_PLATFORMTHEME=gtk2 is set. It's not just a workaround...it's a pretty good solution since it unified the workflow better when Audacity is opened via RG audio segments. Once the bookmarks are manually aligned, it should be fine from then on.

I have no issues with closing the bug, although those who happen to experience it and cannot use gtk2 from some reason, will have the same problem.

Thanks.

[Philip Leishman]

That's good news.
I think we should close this bug.
It would be a good idea to document this somewhere so other gnome users can get the bookmarks working.
But where ? The user documentation ?

[musewhirl]

Since one could consider this an dependency for gnome, you could leverage the "Get Dependencies" page located at:

https://rosegardenmusic.com/wiki/dev:get_dependencies

There the various flavors of Linux are mentioned, including Debian, and it also contains packages to be installed, in this case the optional qt5-style-plugins. You'll just need to add information about the environment variable. Also, one could say it's more related to GTK+ than gnome since for one I use Debian, but not that particular desktop, and other flavors may have that GTK+ vs Qt choice.

[Ted Felix]

I'd like to close this, but first I want to nail down the process for "fixing" this. Here's what I did:

• apt install qt5-style-plugins
• export QT_QPA_PLATFORMTHEME=gtk2
• launch rosegarden
• Edit > Preferences > General > Presentation > Make sure "Use native file dialogs" is checked.
• Restart rosegarden.

Now I have a file save dialog where I can dump new bookmarks in the left column and they stay. Does this sound right?

[Philip Leishman]

Sounds right to me

[Ted Felix]

Ok, then this has me wondering a few things...

• Shouldn't this just always work? Is this a Qt bug that we are stuck with?
• Would it be possible for us to fix this for our non-native file dialogs? Is there code we can write to save/restore the bookmarks?
• Is this problem fixed in qt6?
• Does it seem like it would be worthwhile to leave this open and do some more digging at some point in the future? Or is this not worth our time?

[Philip Leishman]

I think this is just the difference between kde(qt) and gnome(gtk)
Normally under kde the kde bookmarks work fine - I have a bookmarks button in the top right of the native save menu. The problem is if I want to use the gnome(gtk) bookmarks - then I need the above workaround.
I think for non native dialogs we would have to implement bookmarks in Rosegarden !
This will almost certainly be the same in qt6.
I don't see this as a bug - the workaround above is for people who want to use the gnome bookmarks.