[dolphin]: bookmarks are completely removed from left panel

[star-buck]

reported here: https://bugs.kde.org/show_bug.cgi?id=342685

[notmart]

as affected packages they are probably one of the two:

• dolphin
• kdelibs (containing kfileplacesmodel)

so if the problem is relatively recent, changes either in dolphin4 or kfileplacesmodel should be bisected. on the kde4 branches such changes should be very sparse nowdays

[notmart]

in kde4 last commit in kfileplacesmodel is in 2013 dolphin has some commits in november/december to may be related

since when the problem happens? just latest iso? one interesting thing would be trying to replace the dolphin package with older builds

[star-buck]

i think I noticed it also one time in previous KCI, but maybe something made it go worse or happen more often? How about kfiledialog, which also displays the bookmarks on left side?

[notmart]

will they remain hidden in the next reboot? and any ways that appear to reproduce the problem?

[star-buck]

they stay hidden and no way to tell when they dissapear but they do very very often here... do they stay stable for you?

[star-buck]

maybe: it has to do something how vishesh hid the baloo predefined search items?

[star-buck]

i have baloo disabled, just wild guessing here

[notmart]

what do the following files contain? ~/.kde/share/apps/kfileplaces/bookmarks.xml ~/.local/share/user-places.xbel

[notmart]

another thing that may be useful to check when it happens is if the problem happens also in the file open dialog of kf5 applications such as kate in the image.

In the last image the weird behavior i can reproduce is when i add a favorite in the kate sidebar, while it appears in kde4 dolphin too correctly (thanks to ~/.local/share/user-places.xbel) the nepomuk related entries get hidden. but the normal entries such as home, root, trash and the ones manually added stay there

[star-buck]

kate could be a good hint, will keep watching it, as i use kate frequently.

[notmart]

apparently happened to somebody else, he reported this upstream that gives some ideas https://bugs.kde.org/show_bug.cgi?id=343735

[davidedmundson]

oooh! I think I have it from reading lots of code.

Initial note: KBookmarks is retarded and I hate it.

The way it looks like it's meant to work: Dolphin reads and writes into $KDECONFIG/kfileplaces/bookmarks.xml

Anything that uses KFilePlacesWidget also uses that

KFilePlacesWidget creates a kfileplacessharedbookmarks.cpp which tries to do a two way sync with this file and freedesktop shared user-places.xbel

When this is one KDE file and one shared Freedesktop file, this worked fine.

However now we have 2 KDE files (from kde4 and kde5 apps) trying to do a two way sync with the same shared file.

I've no idea how to solve this.

[notmart]

so would be kf5 applications that destroy user-places.xbel since the custom places are saved in the kde4 bookmarks.xml, or vice versa

(thing is that usually all seems work just fine and read/write un ser-places.xbel, on the iso i have dolphin and kate bookmarks seamlessy synchronizing immediately, so may be some kind of race condition of what gets read before, what gets read after)

solutions could be either make the kf5 part to read/write in kde4 as well with the migration stuff, or patching kfileplacesmodel of both kdelibs4 and kf5 to use only user-places.xbel ?

[davidedmundson]

Yeah, it's certainly not as simple as I'd hoped, but I think it's narrowed down where to look.

The import/export seems to be done whenever the kbookmarkmanager (cpp wrapper loading the $KDECONFIG/kfileplaces/bookmarks.xml) signals that it has changed. This is emitted in response to a DBus signal that another app with the same file open has changed it.

This is where things get interesting.

The dbus signal emitted is that /KBookmarkManager/kfilePlaces has changed; which means both kde4 and kde5 apps will reload different files and both be trying to re-sync at the same.

[davidedmundson]

FWIW, relevant files to look at are: .local/share/user-places.xbel .local/share/kfileplaces/bookmarks.xml .kde/share/apps/kfileplaces/bookmarks.xml

[notmart]

i'm going to hate myself for proposing something horrible like that, but... but what about (maybe in some kconfupdate) making .kde/share/apps/kfileplaces/bookmarks.xml a symlink to .local/share/kfileplaces/bookmarks.xml ?

[davidedmundson]

If we want an urgent fix for Netrunner, that's not a bad solution.

I think there might be a simple long term fix. Currently it seems all apps export the bookmarks to the shared location whenever /any/ app changes the bookmarks.

If only the app that has actually changed does the export we should lose that race and be fine; and save quite a bit of pointless IO.

Would mean patching both kdelibs and kf5. I can either make the change and see what happens?

[star-buck]

notmart: would the symlink proposal from above fix this in netrunner?

[notmart]

if the reason is actually what we diagnosed here, it should. I can try to write a simple kconf update program that does that

[notmart]

a possible approach to a patch: https://git.reviewboard.kde.org/r/122459/

[notmart]

a quick and dirty kconfigupdate that does the link stuff is at http://quickgit.kde.org/?p=scratch%2Fmart%2Ffileplacesmodel-workaround.git that may be packaged and tried

[hsitter]

https://launchpad.net/~netrunner-os/+archive/ubuntu/netrunner-15-ci-fixes/+sourcepub/4768463/+listing-archive-extra

since this is a new package it will also have to be added to the netrunner ISO

[star-buck]

seems fixed!

[star-buck]

reopen due to happening again as of kci20150327

[star-buck]

happens again in netrunner 16, what needs to be done to fix this?

[notmart]

Emmanuel Pescosta just pushed fixes in both dolphin and kde4, see https://bugs.kde.org/show_bug.cgi?id=345174 http://commits.kde.org/kdelibs/5c0a31a2f2a46aa44b8c34baae67b6951b2abcaf http://commits.kde.org/kde-baseapps/270d2affaafcc9e87ba14f82bfe579e22607e2d2

hopefully having those revisions packaged should solve the problem. (and my old workaround that was packaged separately can be dropped) What they do, is only using one single file for bookmarks, the one that is crossplatform and used by both kde4, kf5 and gnome

[star-buck]

@notmart: how to patch and ship this? @apachelogger : Does it make sense we do a "netrunner-16-ci-patches" ppa again?

[hsitter]

I think this best be landed in kubuntu directly. Losing data is never good.

[notmart]

and, another one in kio framework, http://quickgit.kde.org/?p=kio.git&a=commit&h=e919daeb5b144b146dbf459fadb116729b866d21

doesn't seem to be a commit on kde4 dolphin. If the kf5 version is going to be used soon, may not matter, otherwise should be to port the commit http://quickgit.kde.org/?p=kde-baseapps.git&a=commit&h=270d2affaafcc9e87ba14f82bfe579e22607e2d2 to the old branch

[hsitter]

building in vivid-proposed soon https://bugs.launchpad.net/hundredpapercuts/+bug/1422469

so long as there aren't any regressions we should see this landed in vivid-updates next monday

[star-buck]

Please also copy relevant packages to netrunner-16-ci-fixes ppa, and mark this thread "shipped needs QA" when done, thanks.

[star-buck]

@apachelogger : when you mark any ticket as "packaged", can you add the package names that were needed to rebuild for this patch? so if multiple packages end up in "fixes" or multiple patches target one package, I know what went where :)

[hsitter]

requires a triplet of kde-baseapps, kio and the old kde4libs to work

https://launchpad.net/~netrunner-os/+archive/ubuntu/netrunner-16-ci-fixes/+sourcepub/5033674/+listing-archive-extra https://launchpad.net/~netrunner-os/+archive/ubuntu/netrunner-16-ci-fixes/+sourcepub/5033675/+listing-archive-extra https://launchpad.net/~netrunner-os/+archive/ubuntu/netrunner-16-ci-fixes/+sourcepub/5033673/+listing-archive-extra

[star-buck]

wow, lots of packages, thanks!

[star-buck]

and seems to work!