Details

Reviewers

dfaure
ngraham
rkflx

Group Reviewers

Frameworks
VDG

Commits

R241:e3af26bbb1e7: Improve usability of "Open With" dialog by adding option to filter the…

Summary

FEATURE: 359233

The current "open with" dialog implementation does not follow the KDE principle "Simple by default, powerful when needed" for the following reasons:

The current primary goal of the lineedit is to type in a command. Indeed when start typing a drop-down list with command auto-completion appears.

Usability problems:

The mentioned drop-down list covers the application tree
It's not possible to search in the application tree, so to find a software it is necessary to guess the category every time

My patch changes the behavior as follow:

Simple by default:

The primary goal of the lineedit is to be a search box that allows to filter the applications in the tree
The command auto-completion is disabled by default

Powerful when needed

The command autocompletion can be turned on by advanced users by selecting the preferred autocompletion mode in the right click context menu of the lineedit (this behavior is quite hidden, and I guess most of the normal users don't even know it's possible (I didn't know it until I dig into the code))

Implementation details:

The application tree filtering is achieved using a subclass of QSortFilterProxyModel
When 3 characters are typed in the search box all the tree is expanded (there should be few matching entries at this point)
When the 3rd character is deleted all the tree is collapsed
In order to be able to filter, it's necessary to fetch all the tree nodes when the model is created, and not on demand as it was before. This is achieved by adding a fetchAll method. Maybe there is a more elegant way.

I've tested the implementation, but I'm pretty sure I haven't covered all the possible cases, so a careful testing is necessary.

Relevant discussions:
https://forum.kde.org/viewtopic.php?f=285&t=131014

Test Plan

Tests done:

With and without some text in the line edit:

Double click on category opens it
Double click on entry launches the software
Remember program association for mime works
Run in terminal works
Keep open terminal works

Diff Detail

Repository

R241 KIO

Lint

Automatic diff as part of commit; lint not applicable.

Unit

Automatic diff as part of commit; unit tests not applicable.

There are a very large number of changes, so older changes are hidden. Show Older Changes

dfaure added inline comments.Oct 29 2017, 7:40 AM

src/widgets/kopenwithdialog.cpp
398	Ah. Filipe and I implemented recursive filtering in QSortFilterProxyModel but that's only in Qt 5.10. Too bad ;) We'll have to keep this for now then (easier here since the data doesn't change, anyway)
443	Urgh. Why don't we change this method to be setModels(QSortFilterProxyModel , KApplicationModel ) to avoid all these casts?
459	... and keep a QSFPM * member variable to avoid these casts here.
492	space after if
826	I think this would be more readable as const bool selectionEmpty = !d->view->currentIndex().isValid();
833	Please use QRegularExpression; QRegExp is deprecated. Although, if this is about FixedString, why not just use setFilterFixedString? Regexps are slow, better avoid them when not necessary.
837	s/not/no/ ?

@simgunz have you had a chance to work on @dfaure's comments? It would be great to get this in.

ngraham edited the summary of this revision. (Show Details)Nov 4 2017, 4:35 PM

I fixed most of them. I think I'll have time tomorrow.

src/widgets/kopenwithdialog.cpp
398	I saw the new feature in Qt 5.10 indeed.

Can I suggest to maybe simplify even a little more and remove the category separators? AKA, system, internet?

In D8056#164283, @abetts wrote:

Can I suggest to maybe simplify even a little more and remove the category separators? AKA, system, internet?

+1 totally agree.

Can you be more specific?

Currently, the categories are expanded automatically after 3 characters have been typed.

Do you want to make the categories disappear at this point? Or not having them from the beginning?

I would say make the categories disappear as soon as that view displays search results.

In D8056#164287, @ngraham wrote:

I would say make the categories disappear as soon as that view displays search results.

Yeah, because in the end, when you want to narrow down the results, the categories will get in your way to select the item you want.

Fix code styling
Set appModel and proxyModel together, store proxyModel in data member
Avoid casts using pointer to proxyModel

I have fixed what dfaure suggested. I couldn't remove the cast at line 463 because a Segmentation fault happens. It is not clear to me why exactly.

Regarding removing the categories I need to work on that, because it is not trivial apparently. I thought it was enough to remove line 399-404, but in that case the treeview is almost empty once opened (only the "Help" item is shown).

I run out of time for today, I'll work on that soon.

Gave this a spin, it's a really nice improvement. As for the categories, I do not feel they "get in the way", because:

In most cases, even after only typing three letters there is only one result left, which is already preselected so Enter will accept seemlessly.
It is actually helpful to also see which category an app is in, as this provides confirmation you are on the right track (e.g. if you do "graphics" things, you do not want "devel" stuff) as well as disambiguation of similar entries.
In a way those visual anchors help finding results faster in case the resulting list is long, as you can easily move to the next category instead of having to scan the complete list of results.

Here is an idea for a compromise which both preserves important context and reduces visual noise: Include subtle grouping like in the new type-ahead search in System Settings, i.e. instead of a tree, flatten the list and include the categories as disabled items / intermediate headers. (Not sure how difficult this would be to implement, though.)

At least any duplicates should be removed if you should decide to remove categories altogether (e.g. KMail is both in Internet and Office, which would be confusing without context). Note the duplication is actually helpful when just using categories, and searching in Kickoff already de-duplicates results.

That said, there are some improvements I could imagine would polish this even further:

Expand the categories once the first character is typed. This gives a hint on what to type next (e.g. km would hint at KMail and KMag instead of just showing the categories).
Search in the descriptions too (e.g. browser would show Firefox and Chromium instead of returning nothing).
First line of text: Make it clear what is description and what is the item being opened, i.e. like on Phab I would not write "install the arc helper" but add markup like "install the arc helper". Not sure about the best way to do this, but using bold text would be a first step (also see screenshot below).
It is not discoverable you are allowed to type in a full path to a binary, which is important for a lot of third party / proprietary / binary.tar.gz-style software not installing proper desktop files and one of the primary use cases of this dialog IMHO. Ideas: Add something to the tooltip? Add a gray text (e.g. "Type to search or enter full path" – exact formulation could be better) to the line edit which is currently just empty?

That said, I would suggest to just commit this patch as is and work on any further improvements in a followup patch (just wanted to put this out there to give a complete picture).

In addition to the screenshot in D8056#159491, the dialog is used when opening kcmshell5 filetypes and then navigating "text" → "css" → Application Preference Order → Add…. Note the bold text (although I wish the colon in front of it could go):

I'm showing this because there is actually a mention of "If the program is not listed…". In the end both dialogs should be consistent in intro text, line edit background text and tooltip help text. I'd be happy to help implementing any adaptations in wording once we've reached a conclusion here.

src/widgets/kopenwithdialog.cpp
833	@simgunz This is marked as done, but still uses `QRegExp` and not `QRegularExpression`?
1099	Is this a "fixme-before-commit" or a "fixme-sometimes-in-the-future" FIXME?

In D8056#165014, @rkflx wrote:

That said, I would suggest to just commit this patch as is and work on any further improvements in a followup patch

+1, no need to get bogged down making it perfect in the first patch. Incremental improvement, baby!

@abetts @simgunz If you agree with my ideas in general and also with doing those in followup patches, please add a short comment. I'll then open a task on some of Phab's workboards which is better suited for tracking the discussion than some random comment ;)

Use fixed string case insensitive filter

@rkflx I agree on all your points.

In general I also prefer to have the categories. Implementing what you propose will require a bit of time. Basically if we want any behavior different from the current one, we need to replace the QTreeView with a QListView every time some text is typed in the QLineEdit.

I agree in opening a new task to talk about the proposed points.

For this patch everything should be ok, now. I also fixed the QRegExp point.

Just for my mental sanity, what is the remarkup syntax to make the ESC key? key Esc or Escape shows a hammer and sickle :-)

src/widgets/kopenwithdialog.cpp
833	I was using the regular expression only to provide cases insensitive filter, but I saw now I can achieve it with fixed string filter as well. The interface of the method `setFilterRegExp` only accepts `QRegExp`. Thanks for pointing this out.
1099	It is a fixme-sometimes-in-the-future. Actually I am not even sure how much of a problem that is, so any other opinion is welcomed. To be more clear on this point. Currently `↓` moves the focus to the tree view, while `↑` moves it back in the line edit history of commands. When the search provides no results, `↓` moves forward in the history. This is true for any completion type. Before my changes, `↓` was just moving forward in the history of commands. When we use CompletionPopup or CompletionPopupAuto we want `↓` to let use navigate the entries in the popup, so it shouldn't be used to focus on the treeview. At this point there are two possibilities: We hit `Enter` and select an entry. The popup closes, and in the tree there will be likely a single result if the command chosen has also a desktop entry, or no results if the command is a shell command We hit `Esc` and in the line edit there is a piece of text that may match something in the tree view At this point, once the popup is closed, one could use `↓` to focus the tree view, but currently `↓` is disabled. So in this sense the behavior is not consistent with the cases where other completion modes are used. (Note that when the popup is closed `↓` does not open it again, only typing more text opens it)

@dfaure Could we get your green (for real, on Phab :) light from a Frameworks point of view for this Diff?

@simgunz If you have no further changes planned for this Diff and D8670, I could land both on your behalf. Contact information of non-developers are private by default on identity.kde.org, but I found some in https://github.com/simgunz/redshift-plasmoid. Are those okay to use for the authorship (name + email)?

Just for my mental sanity, what is the remarkup syntax to make the ESC key? key Esc or Escape shows a hammer and sickle :-)

Stumbled upon this too some time ago, amazingly you used the very same workaround I applied back then. Looking at https://en.wikipedia.org/wiki/Esc_key the similar looking glyph seems intentional, so I don't see a chance to convince Phab upstream to change this. Just embrace and use it, maybe we all get accustomed after a while :) At least we get tooltips for all those symbols: ⎋+⌘+⌥

I agree in opening a new task to talk about the proposed points.

Great, I'll try to get this done on the weekend (need to digest your forum post and bugzillas first).

As for the ↓ and completion popup issues, the root cause seems to be that we have one input line but two overlapping "lists", which is really weird conceptually and gets complex quite fast as you noticed. A (quick to talk about, slow to implement) idea would be to get rid of the completion popup even for advanced users and merge those results (recent inputs, but also some other search results like kmimetypefinder which are not even in a category!?) into the list view as a new section.

This definitely needs more thinking, no need to rush…

ngraham accepted this revision.Nov 7 2017, 6:22 PM

@simgunz If you have no further changes planned for this Diff and D8670, I could land both on your behalf. Contact information of non-developers are private by default on identity.kde.org, but I found some in https://github.com/simgunz/redshift-plasmoid. Are those okay to use for the authorship (name + email)?

I don't need to add anything so you can land both. The contact information you have found are fine. Is it there a way to make my contact info in kde identity public? I couldn't find an option for it.

Stumbled upon this too some time ago, amazingly you used the very same workaround I applied back then. Looking at https://en.wikipedia.org/wiki/Esc_key the similar looking glyph seems intentional, so I don't see a chance to convince Phab upstream to change this. Just embrace and use it, maybe we all get accustomed after a while :) At least we get tooltips for all those symbols: ⎋+⌘+⌥

Wow. Never saw that glyph before. One never finish learning.

As for the ↓ and completion popup issues, the root cause seems to be that we have one input line but two overlapping "lists", which is really weird conceptually and gets complex quite fast as you noticed. A (quick to talk about, slow to implement) idea would be to get rid of the completion popup even for advanced users and merge those results (recent inputs, but also some other search results like kmimetypefinder which are not even in a category!?) into the list view as a new section.

This definitely needs more thinking, no need to rush…

Yes, doesn't seems trivial. We can talk about it.

One last note on this modification. Given that the previous default was to use PopupCompletion, it means that most of the users out there have this setting configured. And if they are like me, most of them don't even know they can change this behavior. If there will be any type of announcement or changelog regarding this change, it may be useful to explicitly suggest to change to completion None in order to fully enjoy the new feature without the popup covering the tree.

IMO popup completion is rendered obsolete by the new filter behavior, which is much nicer. We might consider just removing it.

Yes, feel free to kill the hidden setting for completion, especially if the default value isn't the one that gives the best user experience.

dfaure requested changes to this revision.Nov 8 2017, 6:36 AM

dfaure added inline comments.

src/widgets/kopenwithdialog.cpp
468–469	Use the member var instead of casting.
833	Could the view have a method that returns the proxymodel (possibly as a QSortFilterProxyModel* if we don't actually need a subclass-typed pointer), to avoid this cast? Such casts make refactoring more difficult, moving problems from compile-time to runtime.
1108	All this "return false" cascade isn't really needed, a single return false at the end would do the job, or even better, calling the eventFilter method of the base class, just in case that's implemented for other reasons.

This revision now requires changes to proceed.Nov 8 2017, 6:36 AM

simgunz added inline comments.Nov 8 2017, 8:57 AM

src/widgets/kopenwithdialog.cpp
468–469	Segmentation fault happens if I use the member var. Accessing the member var is the cause of the fault, because even `qDebug() << d->m_proxyModel` generates the same error. It is not clear to me why.
833	Ok I'll add a method.
1108	Yes, the cascade of return false doesn't make sense. You mean calling eventFilter of QDialog instead of returning false at the end? eventFilter of QDialog is virtual.

dfaure added inline comments.Nov 8 2017, 12:41 PM

src/widgets/kopenwithdialog.cpp
468–469	Please try moving that code inside `if (d->appModel) { ... }`.
1108	Yes.

In D8056#165453, @simgunz wrote:

Is it there a way to make my contact info in kde identity public? I couldn't find an option for it.

There is no such option yet, as far as I know. Turns out as you used arc to upload your patch (good job!) instead of the web upload, it was already included and I would not have needed to ask…

One last note on this modification. Given that the previous default was to use PopupCompletion, it means that most of the users out there have this setting configured. If there will be any type of announcement or changelog regarding this change, it may be useful to explicitly suggest to change to completion None in order to fully enjoy the new feature without the popup covering the tree.

I see were you are coming from, but not sure this would work, would also be a bit weird to read. I remember some distro release notes advising on manual changes of high importance, but listing every little change would probably be too much. The closest would be someone with a blog aggregated on Planet KDE featuring this improvement (@ngraham you should totally start a blog, as I believe you have a quite good overview on what's happening each week in Phabricator land).

Normally such changes can be automated with kconf_update. Recently, I did something similar (with a perl detour). Instead of copying you would have to set a new value explicitly and touch more than one file (e.g. dolphinrc and everywhere else the dialog is used). You can try this direction, but we could also just wait and see what further changes are possible for the dialog.

In D8056#165455, @ngraham wrote:

IMO popup completion is rendered obsolete by the new filter behavior, which is much nicer. We might consider just removing it.

In D8056#165599, @dfaure wrote:

Yes, feel free to kill the hidden setting for completion, especially if the default value isn't the one that gives the best user experience.

As I wrote above, this would mean two things (I believe both should still be supported, in one form or another at least):

An important use case is to enter a custom path. Having a recent history of those paths to avoid typing/selecting them over and over again is useful. The history can still be accessed via the arrow on the right, but the completion would be gone.
There would be no way anymore to autocomplete or discover anything contained in your $PATH (e.g. your own/custom scripts), safe for typing it out in full.

If the ability to add a custom path is important, maybe we should put that under "Terminal options". I don't think we're ever going to figure out a functional UI for that single text field to work equally well for searching and entering a path with history.

IMHO the problem is not so much in the single text field, but how/where the results are presented.

(Sorry I haven't got around to open the task yet. I did not forget, but Okular was more important last weekend…)

@simgunz, how are we doing on addressing the latest review comments? I just love this new UI; it's a huge improvement over the status quo IMHO, and it would be nice to get it in sometime soon.

The deadline of my PhD thesis is very close, so my free time is basically zero in this period. Unfortunately, I didn't manage to complete these reviews before entering this critical period. In January I should have free time and I'll complete this. I also can't wait to complete this.

No problem at all :) Good luck with your thesis!

Avoid cast by using member var to proxyModel
Initialize m_proxyModel to null pointer
Add access method to m_proxyModel, use it to avoid cast
Remove unuseful returns, call parent eventFilter if conditions unmatched

I found some time to implement the suggestions given by @dfaure and I removed all the static_cast. I haven't implemented any UI change for now. I think that if there are not problems we can land it as it is now, and then improve the UI in a second moment (in few months when I'll be free I can work on this more).

Thanks, looks ok to me now.

Well, all that code about incremental fetching (canFetchMore/fetchMore) only to then fetch everything upfront, could be simplified to just create the full tree without going through the fetchMore API... but I'll stop nitpicking ;)

Please wait until the end of this weekend (5.43 tagging) before pushing though (new i18n calls).

This revision is now accepted and ready to land.Feb 3 2018, 11:28 AM

Good!

I cannot push so someone needs to do it for me.

Soon, I'll have more free time, and I'll try to polish the code (remove fetch more, use Qt 5.10 recursive filtering).

In D8056#200013, @simgunz wrote:

I cannot push so someone needs to do it for me.

No problem, I can do it for you.

Needs a rebase on top of master, FWIW. Can't wait to have this!

I rebased and was just about to land this, but found a serious problem: Accepting via OK, double clicking or Enter will only work if you have typed at least a single character. Otherwise nothing will happen and the dialog just stays open.

Can anybody confirm?

Perhaps related: The OK button does get enabled correctly after selecting an item. However, it does not get disabled again when selecting a category. Sounds like something is still off wrt. tracking what is actually selected.)

This revision now requires changes to proceed.Feb 5 2018, 4:56 PM

Fix OK button not disabled when category is selected
Fix cannot accept selection if filter line edit is empty

Fixed the problems reported by @rkflx hopefully without introducing new ones. I did some testing and now everything seems ok, but please check again.

The tooltip of the line edit now says: Type some text to filter the application tree.\nPress down arrow to navigate the results tree.
I suggest to change it to: Type to filter the application tree or type the name of a command.\nPress down arrow to navigate the results tree. just to avoid having a hidden feature, which is the possibility to type commands. Also because the completion mode default is now set to None, so there will not even be the completion that suggests the existence of this feature.

interspersing the CLI command and application filtering would be a mistake. Say I type kate. Am I intending to use the kate command, or select the "Kate" app? It's ambiguous if we use one text field for both.

In D8056#205614, @ngraham wrote:

interspersing the CLI command and application filtering would be a mistake. Say I type kate. Am I intending to use the kate command, or select the "Kate" app? It's ambiguous if we use one text field for both.

That is a good point, actually I need to check which of the two has the priority now. Given that we were planning to land the revision as it is now (so with this ambiguity), don't we need to describe correctly the current behavior? Then this can be changed when we figure out a better design for dealing with how to input the commands.

It's been a while since I tested (could you re-base it on current master?), but I was under the impression that the text box gave priority to the app filtering unless you checked the semi-hidden option to enable command-line completion instead.

Automatically select first match of the filter
ArrowDown on lineEdit pass focus to QTreeView
Add tooltip to explain how to use the search filter
Fix code styling
Set appModel and proxyModel together, store proxyModel in data member
Avoid casts using pointer to proxyModel
Use fixed string case insensitive filter
Avoid cast by using member var to proxyModel
Initialize m_proxyModel to null pointer
Add access method to m_proxyModel, use it to avoid cast
Remove unuseful returns, call parent eventFilter if conditions unmatched
Fix OK button not disabled when category is selected
Fix cannot accept selection if filter line edit is empty

I rebased to master and updated the review. I hope I didn't messed up anything.

In D8056#205621, @ngraham wrote:

I was under the impression that the text box gave priority to the app filtering unless you checked the semi-hidden option to enable command-line completion instead.

That is true, but in the moment you type a text, which is also a valid command, let's say kate you have two things:

The Kate entry is selected (and so its associated service kate -b %U or similar)
The text box contains a valid binary command kate that can be executed

When you click OK the function checkAccepted is called. To me it seems that it actually uses the service associated to the selected "Kate" entry (kate -b %U) and does not execute the command kate.
(That function is quite complicated and I haven't really analyzed it completely)

In D8056#205595, @simgunz wrote:

Fixed the problems reported by @rkflx hopefully without introducing new ones. I did some testing and now everything seems ok, but please check again.

Thanks Simone, works great now.

Successfully tested opening a file with the following methods:

mouse selection only
type a few characters, select with the mouse
type a few characers, hit Enter
double click on entry
history dropdown
enable completion dropdown, open with custom bin in path
open button
paste custom bin not in path
autocomplete custom path
↓ to move focus (this breaks with the completion enabled, though)

That's basically all the dialog should be able to do that I know of, therefore we can land it (once the tooltip is changed).

For improving the usability, I still want to open a task with some ideas to discuss them further (really soon™, the first step is done by listing the current functionality ↑↑↑). [My promise for Nate's https://phabricator.kde.org/D10245 is still open too…]

In D8056#205608, @simgunz wrote:

The tooltip of the line edit now says: Type some text to filter the application tree.\nPress down arrow to navigate the results tree.
I suggest to change it to: Type to filter the application tree or type the name of a command.\nPress down arrow to navigate the results tree. just to avoid having a hidden feature, which is the possibility to type commands. Also because the completion mode default is now set to None, so there will not even be the completion that suggests the existence of this feature.

You are right, the least we can do for now is to improve the tooltip. I don't think users know what a "tree" is, so how about this:

Type to filter the applications below, or specify the name of a command.
Press down arrow to navigate the results.

Use/adapt it if you like it, I'll wait with landing.

When you click OK the function checkAccepted is called. To me it seems that it actually uses the service associated to the selected "Kate" entry (kate -b %U) and does not execute the command kate.
(That function is quite complicated and I haven't really analyzed it completely)

Yeah, that's not ideal (but not too bad since the completion is off by default). In my testing the service was also preferred over the executable, which is fine because you can explicitly specify the latter by typing the full path.

src/widgets/kopenwithdialog.cpp
834–836 ↗	(On Diff #27171)	I checked this, but AFAIK it's fine to remove. @dfaure introduced this 10 years ago in R446:d6903613f07b, but I guess we are covered both by the disabled button for empty line edits as well as the checks below.

This revision is now accepted and ready to land.Feb 13 2018, 9:05 PM

I'm super excited to see this happening. Fantastic work, @simgunz, and thanks as always for your incredibly thorough review prowess, @rkflx. I'm planning to feature this in the coming Sunday's Usability & Productivity post as it it not only a serious improvement to both, but it should also look really, really good in animated gif form. :)

Improve tooltip to let user know he can type a command

↓ to move focus (this breaks with the completion enabled, though)

Only for completion: popup. Still works for completion: auto

I have changed the tooltip as suggested. I think we are ready to land it.

Can't wait to see the gif!

@simgunz Thanks again for your patience (first commit in July!). Hope to see more patches from you in the future (both large* like this one, but also smaller things**), as you both have a good eye for usability as well as the means to implement changes. You should think about applying for commit access in tandem with you next patch or the one after that ;)

*) I know Nate would love to get collapsible headers in Dolphin's sidebar…
**) Just ask if you need ideas.

In D8056#206303, @rkflx wrote:

*) I know Nate would love to get collapsible headers in Dolphin's sidebar…

*completely coincidental mention* https://bugs.kde.org/show_bug.cgi?id=389803 :)

Allow me to echo everything @rkflx said. This is excellent work, and I can't wait to see what else you come up with in the future!

Closed by commit R241:e3af26bbb1e7: Improve usability of "Open With" dialog by adding option to filter the… (authored by simgunz, committed by rkflx). · Explain WhyFeb 14 2018, 5:19 PM

This revision was automatically updated to reflect the committed changes.

In D8056#206303, @rkflx wrote:

@simgunz Thanks again for your patience (first commit in July!). Hope to see more patches from you in the future (both large* like this one, but also smaller things**), as you both have a good eye for usability as well as the means to implement changes. You should think about applying for commit access in tandem with you next patch or the one after that ;)

I finished writing my Ph.D. thesis right now. Finally I am a free man again! (this is also the reason why it took so long to complete this revision, because my commits came spaced by months :-) )

I'll definitely have more free time from this moment on, and I'll be glad to contribute.

*) I know Nate would love to get collapsible headers in Dolphin's sidebar…

I was thinking to discuss the possibility to make a new KDE UI component for collapsible headers so that it can be used in multiple places. Maybe I can open a task for discussing this and collect opinions and possible use cases to see if it makes sense.

**) Just ask if you need ideas.

I usually have too many, and not enough time. Reason why my big projects are swamped, and why I open a lot of bugs without fixing them myself.

I must say I loved the phabricator experience. I always programmed by myself my own projects, but discussing how to implement things, having someone to review the modifications is why more fun and the quality of the outcome is way better.

My next big goal is try to improve the usability of Okular, especially improving the annotations. (I think there are at least 10 bug reports opened by me on this). I'll get you involved soon.

Great to hear. Hopefully you'll find the right balance between chasing the big goals and doing small changes here and there to learn the trade for achieving the former ;)

In D8056#206326, @simgunz wrote:

I was thinking to discuss the possibility to make a new KDE UI component for collapsible headers so that it can be used in multiple places. Maybe I can open a task for discussing this and collect opinions and possible use cases to see if it makes sense.

That sounds great. This is a pretty common and user-friendly UI paradigm, so it would make perfect sense to make it more widely available.

In D8056#206326, @simgunz wrote:

My next big goal is try to improve the usability of Okular, especially improving the annotations. (I think there are at least 10 bug reports opened by me on this). I'll get you involved soon.

You're my hero! This is a big tentpole of the Usability & Productivity initiative. Take a look at some of the Okular bugs mentioned on https://phabricator.kde.org/T6831

A major problem is that Okular (or poppler) often saves annotations in ways that don't make them renderable in other viewers, or when printing. See the following bugs:

			Path	Packages
M			src/widgets/kopenwithdialog.h (2 lines)
M			src/widgets/kopenwithdialog.cpp (162 lines)
M			src/widgets/kopenwithdialog_p.h (17 lines)

Diff	ID	Base	Description	Created	Lint	Unit
Base			Base
Diff 1	20087	43f677a		Sep 29 2017, 11:37 AM	★	★
Diff 2	21261	43f677a	- Automatically select first match of the filter	Oct 24 2017, 8:22 PM	★	★
Diff 3	21925	43f677a	- Fix code styling	Nov 5 2017, 7:58 PM	★	★
Diff 4	21990	43f677a	- Use fixed string case insensitive filter	Nov 6 2017, 7:13 PM	★	★
Diff 5	24488	43f677a	- Avoid cast by using member var to proxyModel	Dec 30 2017, 3:45 PM	★	★
Diff 6	27079	43f677a	- Fix OK button not disabled when category is selected	Feb 13 2018, 5:03 PM	★	★
Diff 7	27084	8b809b7	- Automatically select first match of the filter	Feb 13 2018, 5:55 PM	★	★
Diff 8	27136	8b809b7	- Improve tooltip to let user know he can type a command	Feb 14 2018, 6:55 AM	★	★
Diff 9	27171	8b809b7	R241:e3af26bbb1e7dd32a7bb48c615d352416066e238	Feb 14 2018, 5:19 PM	★	★

Improve usability of "Open With" dialog by adding option to filter the application tree
ClosedPublic
Actions

Details

Diff Detail

Revision Contents
Changeset List

Diff 27171

src/widgets/kopenwithdialog.h

src/widgets/kopenwithdialog.cpp

src/widgets/kopenwithdialog_p.h

Improve usability of "Open With" dialog by adding option to filter the application treeClosedPublicActions

Details

Diff Detail

Revision ContentsChangeset List

Diff 27171

src/widgets/kopenwithdialog.h

src/widgets/kopenwithdialog.cpp

src/widgets/kopenwithdialog_p.h

Improve usability of "Open With" dialog by adding option to filter the application tree
ClosedPublic
Actions

Revision Contents
Changeset List