Remove document preview plugin: current technology harms workflow
AbandonedPublic

Authored by kossebau on Nov 4 2018, 6:48 PM.

Details

Reviewers
None
Group Reviewers
Kate
Summary

While the idea seemed smart to reuse kparts plugins as handler inside
the preview plugin, sadly this results in many clashes for keyboard
shortcuts especially for central ones like "Copy".
Which spoils the idea of a live preview while editing the text document,
as one often runs in unusable shortcuts.

Which is a problem in general with toolviews, which might have actions
with shortcuts conflicting with those as registered by the currently used
document view whose actions are integrated in the global app menu.
KParts plugins in a toolview just escalate this more, given they have
the usual view-centric actions with the respective common shortcuts.

A solution might be to extend KXmlGui to somehow support such situations,
and decide who owns the shortcut by looking at the focus.

Diff Detail

Repository
R40 Kate
Branch
removepreviewplugin
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 4561
Build 4579: arc lint + arc unit
kossebau created this revision.Nov 4 2018, 6:48 PM
Restricted Application added a project: Kate. · View Herald TranscriptNov 4 2018, 6:48 PM
Restricted Application added a subscriber: kwrite-devel. · View Herald Transcript
kossebau requested review of this revision.Nov 4 2018, 6:48 PM

It's painful to propose this, as I had invested quite some time into it, also by tuning some kparts plugins for optimized usage or even writing a new one, kmarkdownwebview, just for the preview purpose, and then doing some blog posts.
But after the initial proud-developer-and-testing phase I found myself in normal user life too often avoid using the plugin, due to the annoying shortcut issue. And then there are some minor papercuts as well which still are unsolved (mimetype changes, new document unknown mimetype, etc).

I never got lots of feedback, so have no idea how large any userbase of the plugin is and how much they rely on it now. There surely are some who at least tried it, and found it worthwhile to file some bug reports, cmp. https://bugs.kde.org/buglist.cgi?component=plugin-preview&product=kate&resolution=---

The feature itself surely is something very wanted still.

sars added a subscriber: sars.Nov 4 2018, 8:03 PM

I would like to give a -1 for removing the plugin I think that the feature is really something that has potential to be great!

That said I have also disabled the plugin because of the shortcut problems, but I do think that it would be great if we could get changes in KParts that would allow us to embed a read-only-no-shortcuts part.

Would the needed changes in KPart be big?

Maybe we could just put a disclaimer that the plugin is a technology preview at the moment?

brauch added a subscriber: brauch.Nov 4 2018, 10:53 PM

A solution might be to extend KXmlGui to somehow support such situations,
and decide who owns the shortcut by looking at the focus.

FWIW I have heard this idea several times over the last years from different directions, and I think a lot of applications would profit from having something like that.

In D16668#354093, @sars wrote:

I would like to give a -1 for removing the plugin I think that the feature is really something that has potential to be great!

We surely all agree about the feature in theory. It's the current implementation which sucks (too much) and which thus I propose to withdraw.

Would the needed changes in KPart be big?

From the short looks I had, this might need some more work (at least for me who is not that much into KXmlGui, where I suspect the real work is needed to reach flexibility with the app-global shortcuts registered for actions & Co). So far do not even have a rough idea how this could be approached
In short: No idea ;)

A solution might be to extend KXmlGui to somehow support such situations,
and decide who owns the shortcut by looking at the focus.

FWIW I have heard this idea several times over the last years from different directions, and I think a lot of applications would profit from having something like that.

Chance is you also heard it often from me this year in multiple channels, every time when I was frustrated about having no instant idea how to fix it :P
(e.g. also for the wanted-to-have shortcuts in the documentation toolview of KDevelop)

-1. I would prefer if this plugin could stay until an alternative is implemented.
I use it like this: the tool view is collapsed most of the time. When I would like to check how my markdown would look like if it is rendered, I open the tool view and then close it (because of the hijacked shortcuts).

(One thing I noticed: in the beginning there was the Webview preview widget to render markdown; and now most of the time an Okular widget is shown for the markdown preview. Probably it depends which render plugin is loaded first)

kossebau added a comment.EditedNov 11 2018, 6:08 PM

@gregormi @sars Is there a chance I could transfer the in-official maintainership of this plugin to you then?
Truth is I have lost my love for this plugin and do not care as much as would be good. D12131 e.g. had me passive besides helping to fix the related crashes in kdevelop. Any time I look at this plugin I rather start to think about fixing kxmlgui, but never with the needed amount of resources, so resultless.

(One thing I noticed: in the beginning there was the Webview preview widget to render markdown; and now most of the time an Okular widget is shown for the markdown preview. Probably it depends which render plugin is loaded first)

The KParts plugin is chosen which is system/user globally selected as preferred one for embedded view. This selection though is only possible to edit with Plasma SystemSettings -> Applications -> File Associations -> text/markdown -> Embedded. The plan would have been to a) give a shortcut to open these settings from the plugin b) add a custom variant to the Kate Settings to allow overwriting those system/user global settings. But motivation to do that sadly also blocked by the key shortcuts issue.
Does changing the order in the settings work for you? If not, please tell, I would be still eager enough to fix that at least.

@gregormi @sars Is there a chance I could transfer the in-official maintainership of this plugin to you then?
Truth is I have lost my love for this plugin and do not care as much as would be good. D12131 e.g. had me passive besides helping to fix the related crashes in kdevelop. Any time I look at this plugin I rather start to think about fixing kxmlgui, but never with the needed amount of resources, so resultless.

You said the plugin as it is now, has no future. But the shortcut issue could be solved by removing all shortcut settings from the plugin, couldn't it?

(One thing I noticed: in the beginning there was the Webview preview widget to render markdown; and now most of the time an Okular widget is shown for the markdown preview. Probably it depends which render plugin is loaded first)

The KParts plugin is chosen which is system/user globally selected as preferred one for embedded view. This selection though is only possible to edit with Plasma SystemSettings -> Applications -> File Associations -> text/markdown -> Embedded. The plan would have been to a) give a shortcut to open these settings from the plugin b) add a custom variant to the Kate Settings to allow overwriting those system/user global settings. But motivation to do that sadly also blocked by the key shortcuts issue.
Does changing the order in the settings work for you? If not, please tell, I would be still eager enough to fix that at least.

a) and b) sound like good ideas. Yes, changing the order in "File Associations -> text/markdown -> Embedded" works - thanks for this hint - I didn't know that this setting exist! But nothing to fix for you, then ;-)

You said the plugin as it is now, has no future. But the shortcut issue could be solved by removing all shortcut settings from the plugin, couldn't it?

The shortcuts are coming from the KParts plugins, not from the preview plugin itself. And removing the shortcuts from the respetive KParts plugins is not something that would be favoured by people, given those plugins are also used in other places where the key shortcuts are very wanted (because there the KParts plugins are used for the main document view). So IMHO not really a solution to explore more.

Yes, changing the order in "File Associations -> text/markdown -> Embedded" works - thanks for this hint - I didn't know that this setting exist! But nothing to fix for you, then ;-)

Good. Preferred outcome :)

I think one should not let perfect be the enemy of good.
You are right that the plugin has issues. But on the other side, it provides value for "many" users.
Given it is not on per default and people seem to use it, I would tend to keep it.
If there is a better replacement, one can phase it out.

kossebau abandoned this revision.Nov 17 2018, 4:37 PM

Okidoki, so moving my iron broom back into the lumber-room. Perhaps can take it just as positive thing that the plugin still is useful to some people then, despite having run myself into a technology wall here for now and pulled back a bit in frustration, waiting for the big idea for the needed breakthrough.

Otherwise, as said before, happy to pass on the maintainership of the plugin to someone who is ready to give the love it needs to what we have now with the plugin. Who in for the job? :)