In M113#3794, @ngraham wrote:

The UI for the latest implementation is very good. I have only one suggestion. When no valid USB disks are mounted, instead of displaying a blank combobox with no entries, instead hide the combobox and show a centered label that says, "Please plug in a USB disk"

The flash drive selector is on another screen to avoid using dialog windows extensively. The user will be allowed to proceed to the flash drive selection screen only after selecting a valid ISO image.

I am working on the KDE ISO Image Writer as part of GSoC and based on this discussion I created the following mockups:

In D21037#464076, @elvisangelaccio wrote:

Can you show a screenshot of a detail view affected by such problem?

In D21037#463984, @elvisangelaccio wrote:

1. You can already deselect everything by pressing an empty space in the view, if you are a mouse user.

This is not always possible. For example, if you're using the details view mode and there is not empty space to click (when the scrollbar is active).

The highlight effect provided by PlasmaCore.IconItem is only visible when used with dark or colourful icons:

• Revert "[Task Manager] Make mute/unmute behaviour configurable"

In D19822#439195, @rooty wrote:

I like this change I'd just prefer it if you could post screenshots in the test plan section?

I added a screen recording to the test plan.

• [Task Manager] Enable ability to mute tasks by default
• [Task Manager] Change wording in config ui

• [Task Manager] Make mute/unmute behaviour configurable

In D19822#437680, @ngraham wrote:

Also, it would be nice if you also work on making the volume indicators smaller and always in the corner.

• [Task Manager] Remove unnecessary braces

Yes, you could accidentally mute an application when using Icons-Only Task Manager.
As you can see below, the audio indicator is pretty close to the centre of the task button, which is where you would usually click to activate that task:

In D13344#308039, @muhlenpfordt wrote:

In D13344#308027, @faridb wrote:

I've got it to work by using Document::waitUntilLoaded() but it waits until the full image has been loaded which renders the sorting by image size quite slow. Any suggestions?

Document::size() should be available in state MetaInfoLoaded, it's not necessary to load the whole image.
If the meta info is not retrieved automatically for all images in the current directory maybe we need a way to trigger this.
Sorting by Date actually works with EXIF info (if available), so I think the meta info should be loaded already.

In D13344#306903, @rkflx wrote:

@faridb Are you still around?

While proofreading the release notes I had the idea to add "Sort by image size" (Bug 263059 actually, which will probably mean comparing the image's area), but wanted to give you the opportunity first if you are interested in becoming a regular contributor. Let me know ;)

I removed the code which explicitly triggers sorting when the file's data is changed because it seems like using the rating role solved that problem. I did some tests and the sorting refreshes automatically when the rating of an image is changed without manually calling invalidate().

• Revert "Invalidate current sorting when item rating is changed"

@rkflx Thanks for your work! I rebased on D13669.

• Remove D13669 from this revision

• Revert "Fallback to sorting according to file item text (temporary fix)"
• Use rating role instead of column

In D13344#280376, @rkflx wrote:

In D13344#280067, @faridb wrote:

• Import header file only when needed
• Use if instead of else if when using return
• Avoid multiple conversions from QVarient to int

@faridb LGTM, but we should still solve the issue Peter discovered, i.e. try to always sort by name for the secondary criterion (not only accidentally ;)

• Fallback to sorting according to file item text (temporary fix)

• Import header file only when needed
• Use if instead of else if when using return
• Avoid multiple conversions from QVarient to int

I would suggest to always use the filename as the only secondary criterion

When the ratings are the same, the files are sorted using the default sort method of QSortFilterProxyModel which seems to use the filename by default. (Dolphin uses custom code for the sorting which falls back to the filename as a default sorting column). Commit: eb8adc49ab0b.

• Fallback to default sort method in case ratings are the same
• Disable sort by rating when no semantic info backend is available
• Invalidate current sorting when item rating is changed

• Add TODO note to flag this as a temporary fix

• Remove unnecessary QVariant validity check
• Fix coding style issue

Write a small test case app, similar to what's in the forum post.

I actually tried to reproduce the bug by clearing a QMenu multiple times in a row but no luck, until I followed your suggestion and I used a QTimer to clear the menu which caused the exact same bug. It seems like it only happens when the menu is cleared through a slot triggered outside of the main event loop.

Include a TODO note to flag this fix as temporary

I kept digging and I found that it might be related to this code (in KIPIInterface::loadOnePlugin() which is in app/kipiinterface.cpp):

QMetaObject::invokeMethod(this, "loadOnePlugin", Qt::QueuedConnection);

If loadOnePlugin() is called synchronously the Share menu works fine (without D13289 or D13312). Could it be some sort of thread issue? But then why does the problem disappear when compositing is disabled?

BTW, I'm mostly testing in a VM. Are you testing on real hardware?

Yes, I am doing the tests on real hardware (with Arch Linux | KDE Plasma 5.12.5 | KDE Frameworks 5.46.0 | Qt 5.11.0 | Linux 4.16.13)

Calling d->updateMenu() twice seems to fix both D13289 and D13312. If not the menu is updated correctly but it's invisible while still working (i.e. you can click invisible menu actions and they would work even if it doesn't show on screen).