KTextEditorPreviewPlugin 0.2.0

frinring KDE, KDevelop

KTextEditorPreviewPlugin 0.2.0 has been released.

Example: KTextEditor Document Preview plugin used with KMarkdownWebView KParts plugin in Kate

The KTextEditorPreviewPlugin software provides the KTextEditor Document Preview Plugin, a plugin for the editor Kate, the IDE KDevelop, or other software using the KTextEditor framework.

The plugin enables a live preview of the currently edited text document in the final format, in the sidebar (Kate) or as tool view (KDevelop). So when editing e.g. a Markdown text or an SVG image, the result is instantly visible next to the source text. For the display the plugin uses that KParts plugin which is currently selected as the preferred one for the MIME type of the document. If there is no KParts plugin for that type, no preview is possible.

Download from:
https://download.kde.org/stable/ktexteditorpreviewplugin/0.2.0/src

sha256:
ab54382dfd8e88247b53b72fdd9b259feb7c0266300b604db899edf0828677ae ktexteditorpreviewplugin-0.2.0.tar.xz

Signed with my new PGP key
E191 FD5B E6F4 6870 F09E 82B2 024E 7FB4 3D01 5474
Friedrich W. H. Kossebau
ktexteditorpreviewplugin-0.2.0.tar.xz.sig

Change since 0.1.0

  • Add dropdown menu to toolbar with the main menu of the KParts plugin
  • Add About dialog for the currently used KParts plugin (invokable from the new dropdown menu)

Notes

Long term the plan is to merge this plugin into the Kate repository, or some new separate KTextEditor-Plugins repo, ideally already for KDE Applications 17.12.

For now though this plugin is in its own repository to allow an initial independent quick release cycle phase, following the release-often-and-early mantra. With the help of your feedback (file your issue) that should make the features of the plugin the ones you like to have rather soon.

Developers: Improve your favourite KParts plugin

While a usual KParts plugin works out of the box, for a perfect experience with the Automatic Updating option some further improvements might be needed:

A few KParts plugins have already seen such adaptions, like the SVGPart and the KUIViewerPart (see also blog post), adaptions to be released with KDE Applications 17.12.
Another KParts plugin has been written with that in mind from the start, the KMarkdownWebViewPart (see also blog post), which already has been released.

You might want to take some guidance by the respective commit “Support loading by stream and restoring state on reload” to the SVGPart repository.

23 thoughts on “KTextEditorPreviewPlugin 0.2.0”

  1. Unfortunately I have problems with the preview of SVG files, I guess because of KParts: the background of SVG files appears in black (I guess because no color is specified), hidding most of its content. Did you experienced sth similar?

    Reply

      • Oh, actually I recalled it wrongly. SVG files work even better w/o svgpart when using konq-plugins, so kparts uses QtWebengine front-end.

        The problem I was referring to (black background) was actually with preview of DOT files.

        Another issue, of at least version 0.1.0, is that some previews are bigger than available space. It would be nice to 1) zoom in/out the preview to the available space, and 2) be able to adjust the available space.

        Reply

      • DOT graph files are handled by the KGraphViewer KParts plugin from kgraphviewer. Any issues with it need to be fixed with that. So please help and file your black background issue on https://bugs.kde.org/enter_bug.cgi?product=kgraphviewer

        Adapting the preview to available space (i.e. current width and height of preview tool view) is something which would need support by all the KParts plugins, as the preview plugin just loads the KParts plugin and passes it the data to show. Anything else is left to the KParts plugin. Which usually defaults to 100 % zoom view. There is no abstract interface currently which could be used to instruct KParts plugins to a fit-to-size zoom. Something like that might be interesting for other KParts plugin users, like the Ark preview.

        Again please help and file your wish on bugs.kde.org, here with the KParts framework.

        Reply

      • Thanks for the great work and for the info wrt kpart plugins. I will submit the issue and wish asap.

        (Cannot reply to your most recent reply, so doing it here)

        Reply

      • However, somehow dolphin is able to autoscale previews and adjust available space by moving the border of the preview panel left vs. right

        Reply

      • Dolphin uses a different technology to create the preview: KIO thumbnail generators, which deliver a pixmap for a given file. Those previews are indeed tailored to fit the complete object into the available size by design.

        Reply

      • I just realized that point #2 is already implemented. One needs to be extremely close to the boundary to be able to shift it, but it works. Would it be possible to increase the hover region for this?

        Reply

      • > Would it be possible to increase the hover region for this?
        The hover region is possibly defined by the Qt widget style plugin currently used. So if the region is perceived too small, that is a problem everywhere with those tool docker elements. Check if the settings of the Qt widget style (e.g. in Plasma Systen Settings > Application Style > Widget Style > Configure or similar, that changed recently) allow you to perhaps have bigger frames around dockable panels.
        But chance is that this is actually hardcoded somewhere in QMainWindow code.
        In any case, not easily to get under our control and an issue shared with everyone, so should be fixed at the root.

        Reply

      • I think that more than extending the hover region (didn’t find a way, but it’s ok), the actual problem (for me at least) is that where to hover is barely visible. Please see screenshot:

        As you can see, one easily tries to hover on the wrong vertical gray line, the one of the scrollbar instead of in the barely visible line of the preview plugin.

        Could you somehow make this line more salient, so users know where to go? I think this would solve the issue. It would definitely do so for me, at least 🙂

        Reply

      • I can see your need. Just, the challenge is that the separator line between the plugin and the document and thus the resizing UX is controlled by KateMDI code, which by a quick look seems to use a QSplitter for the separator line. So this is outside of what the plugin can (or by design should) feel responsible for.
        (cmp. https://cgit.kde.org/kate.git/tree/kate/katemdi.cpp)

        And you would have this issue with any plugin shown in a tool view, unless their content fills the tool view space with non-default-background color, no? I can only recommend to file a bug about this with Kate (https://bugs.kde.org/enter_bug.cgi?product=kate&component=application), so their maintainers could consider some solution to this.

        Or you might want to approach the developers of the widgets style you are using, to tune the drawing of QSplitters. There is at least some control to the style plugin for QSplitters: QStyle::PM_SplitterWidth (cmp. http://doc.qt.io/qt-5/qstyle.html). Though your choice of UI color palette with the same whitish for backgrounds is surely a challenge. Some styles used lines of dots for marking the splitter, perhaps your style could have that as well, at least optionally?

        Reply

      • Thanks for the info. I think I will submit an upstream bug to Kate to see whether there is sth they can do about it, and also to Kvantum (at least in the style I’m using), as this is not a problem at all when using Breeze instead.

        Thanks for pointing these out

        Reply

      • I finally found the time to fill the issues:

        https://bugs.kde.org/show_bug.cgi?id=386953
        https://github.com/PapirusDevelopmentTeam/adapta-kde/issues/25

        Two last questions:

        – I use Kwin tiling (https://github.com/Jazqa/kwin-quarter-tiling). Not sure this is sth your plugin can do or whether this is another Kate issue, but it would be very nice to have the plugin width as a percentage instead of an absolute measure, so when the size of the window varies, the width of the plugin would automatically get scaled. I guess this is more simple to say than to implement. An example of this is how Kile preview works.

        – I found that embedded images do not appear in Kate previews (e.g., in html or markdown files), I guess it’s a problem of kpart, isn’t it?

        Reply

      • > auto-resize-plugin-on-window-size

        Might be implementable by listening to the window size and adapting tool view size as needed.
        Not sure though if plugins should do that themselves.
        IMHO size of pluins is something that the shell should control (like window manager controls size of windows). In my perfect world the window manager would also control the internal window components layout 🙂

        Again, best file a wish bug with Kate, so their authors can consider this.

        > external resource like embedded images do not appear in preview

        See https://bugs.kde.org/show_bug.cgi?id=386251#c1 and the first challenge mentioned there. Currently not supported/possible due to architecture.
        Might need some clever url rewriting. Perhaps some custom kio-slave which cares for that. In any case a bigger undertaking to solve this.

        Reply

  5. Plugin doesn’t work for me.

    I open some README.md by “Open with” (in Dolphin) and see “No preview available”.

    I have installed plugin mentioned in article: https://frinring.wordpress.com/2017/10/09/ktexteditorpreviewplugin-0-2-0/

    $ ls -l /usr/lib/qt/plugins/ktexteditor/ktexteditorpreviewplugin.so
    -rwxr-xr-x 1 root root 69072 10-12 00:20 /usr/lib/qt/plugins/ktexteditor/ktexteditorpreviewplugin.so

    Seems that properly plugin is not loaded despite I have checked “Document preview” plugin in Kate, but if I open any “ui” file (“Open with” from Dolphin) then after switch (in Kate) to tested README.md preview starts work! It happens like that even KUIViewer is not installed in system. After installation nothing changed, only ui file is properly shown.

    I reported this as bug as “Bug 385755” – https://bugs.kde.org/show_bug.cgi?id=385755

    Reply

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.