- User Since
- May 29 2018, 1:12 PM (50 w, 6 d)
Mon, May 13
I am working on the KDE ISO Image Writer as part of GSoC and based on this discussion I created the following mockups:
Sun, May 12
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).
Sun, May 5
Apr 2 2019
The highlight effect provided by PlasmaCore.IconItem is only visible when used with dark or colourful icons:
Mar 28 2019
- Revert "[Task Manager] Make mute/unmute behaviour configurable"
Mar 27 2019
I added a screen recording to the test plan.
Mar 25 2019
- [Task Manager] Enable ability to mute tasks by default
- [Task Manager] Change wording in config ui
Mar 24 2019
- [Task Manager] Make mute/unmute behaviour configurable
- [Task Manager] Remove unnecessary braces
Mar 17 2019
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:
Aug 18 2018
Aug 13 2018
I used DocumentFactory::instance()->load() **but then sorting by image size only works after the document's info have been loaded (i.e you have to explicitly click on each photo to load its info and then the sorting by image size would work). **
Jun 23 2018
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"
Jun 22 2018
- Remove D13669 from this revision
- Revert "Fallback to sorting according to file item text (temporary fix)"
- Use rating role instead of column
Jun 19 2018
- 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
Jun 7 2018
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
Jun 5 2018
- Add TODO note to flag this as a temporary fix
- Remove unnecessary QVariant validity check
- Fix coding style issue
Jun 4 2018
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?
Jun 3 2018
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).
I looked into the problem of Loading... not showing and I found out that it's because of my bugfix. My change caused d->updateMenu() to be called only when the loading is finished, thus not showing Loading....
Jun 2 2018
Yes, you are right. Implementing this feature could probably break other aspects of Gwenview that assume that folders are sorted before files.
Thanks for the suggestions! I will try that.
@rkflx Thanks for reviewing and accepting the patch! This is my second patch and your feedback and your advices are encouraging me to keep contributing :-).
I think there is a way to make the browsing feature work even if Folders First is disabled. For example, skip the next element if it's a folder and go directly to the next document after it. Would that be an acceptable behaviour?
I could not find a way to test if Loading... was showing correctly because the plugins were loading almost instantaneously.
I made the changes you requested in your inline comments.
I updated the summary. Is it a suitable commit message?
I created a separate Diff for the bug fix at D13289.
Rebase on D13252
Thanks for your detailed feedback! I have made the changes you have requested in your inline comments.
I have also added the ability to sort folders first but I will create a separate revision for that.
Jun 1 2018
@rkflx Thanks for the clarification. Now, I see why it's necessary.
Thanks! This will make D13197 much cleaner.
May 30 2018
Fixed the coding style issue
Made the changes to use mInstallPluginAction instead of the action's text.
It also solved the bug I was having with the Plugins menu.
Fixed coding style issues
May 29 2018
Use an internationalised string instead of a hard-coded one