Thank you. I'll update change and resubmit it to gitlab.

In D19829#472621, @ngraham wrote:

@i.Dark_Templar can you land this yourself?

Rebased to master, but it needs testing.

In D19829#456234, @GB_2 wrote:

Can you please update this patch? It doesn't apply anymore. It would also be nice if you used Arcanist/arc in the future: https://community.kde.org/Infrastructure/Phabricator#Using_Arcanist_to_post_patches

Unlike information panel, tooltips don't allow to play videos for me. But it can display pictures and text files.

Same as for informational panel: preview of files depends on amount of screen size is used to display file size. It depends on file icon size. At least with my settings preview on tooltip (and on information panel) is bigger than preview in the central area.

To me dolphin without panel on right side looks unusual and unfamiliar. Due to that I made patch returning it.

Without tooltip:

Without panel:

Favorite icons are much larger, it's hard to confuse them with root level menu icons. If it's deemed as informational noise, it's disabled by default. But in case it's not, it may be enabled if this change is applied. And in my opinion it looks more consistent in style with 'modern menu' since 'modern menu' has those icons enabled.

Attaching screenshot with current look of menu (or with disabled option) and new look with enabled option and also a configuration widget.

Abandoning this change in that case.

Any news on this bug and this change yet?

After fixing bug 399274, the issue this change fixes becomes masked, but it still remains. It's hard to hit the issue now, maybe even impossible at the moment. But it might reappear later.

Are there any obstacles remaining which prevent from merging these changes? It'd be great if you could review them and merge. If something still prevents the merge, I'd be glad to help fixing that.

Oh, I see the source of confusion now. I think https://phabricator.kde.org/D16057 shouldn't link to bug 399275 since description of that bug is describing contents index items not expanding/collapsing if "double click" is selected if I understood it correctly.

This is change for bug 399275.

I've seen it. Linked change fixes different issue:

I'm not sure what part exactly is broken. It's just an incompatibility between linux (posix maybe?) file length limits and windows (ntfs) limits. I'm using default gentoo libc (sys-libs/glibc-, "GNU lib C library"). I've ran filelight under valgrind and didn't notice any warnings that glibc writes anything to wrong memory address. I've looked it up, and it looks like glibc allocates buffer large enough to hold more than NAME_MAX path (on my system it allocates 32768 bytes for whole DIRP, struct dirent and additional internal stuff). And it has a special structure field d_reclen to indicate the actual length of returned record. In my case d_reclen holds value 288 (for a filename 264 bytes long). It's not fully standard compatible, but I guess it helps to work around such system design incompatibilities and usually goes unnoticed by users.

With this patch the "Bookmarks" menu in KWrite does no longer open (as if it were empty) with global menu enabled.

Updated patch for plasma-workspace 5.10, I'm using it with 5.10.4, but it should apply to master too. I've tried adding appmenu panel to desktop, still works fine for me. A bit of clarification. I'm not sure it's important, but I'm currently using 'Oxygen' workspace theme and 'Air' desktop theme.

That's not entirely true. We do show the cached version, but also immediately call aboutToShow which will update the subtree. In theory at least :)

There's condition in function 'void DBusMenuImporter::slotAboutToShowDBusCallFinished(QDBusPendingCallWatcher *watcher)' around line 494:

if (needRefresh || menu->actions().isEmpty()) {

needRefresh is a value from dbus. Since another application already issued 'LayoutUpdate' event, needRefresh is false (it should be already refreshed, while it's actually not). And menu->actions() is not empty since it uses cached submenu (this is no longer true with this patch, this patch ensures that menu->actions() is empty).
I think another flag may be stored, for example ActionForId map may be expanded for that use case. But I don't see much difference in the end result.

Current implementation is buggy. Cached menu items may be invalid: after 'LayoutUpdate' event updated menu all of it submenus are no longer valid (and thus cache contains invalid data) and should be updated. Menu itself is updated, but it's submenus are not. It's just usually happens that new submenu data is same as old submenu data, but in case it's not, you'll never get new submenu data and never see updated submenu. See example in menubugtest.tar.bz2 attached to linked bug (and description there).