KTextEditorPreviewPlugin 0.1.0

frinring KDE, KDevelop

KTextEditorPreviewPlugin 0.1.0 has been released.

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

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. For the display it uses the KParts plugin which is currently selected as the preferred one for the MIME type of the document. If there is no matching KParts plugin, no preview is possible.

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

sha256:
21e17a97fe2b942991ce564371ce822564397488847f8d21d7d5b24d4c120796 ktexteditorpreviewplugin-0.1.0.tar.xz

Signed with my new PGP key
E191 FD5B E6F4 6870 F09E 82B2 024E 7FB4 3D01 5474
Friedrich W. H. Kossebau <kossebau@kde.org>
ktexteditorpreviewplugin-0.1.0.tar.xz.sig

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.

16 thoughts on “KTextEditorPreviewPlugin 0.1.0”

  4. If I understand correctly, the plugin renders the text to a KPart widget. Is it possible to use it other way around? To modify the text using the KPart widget? For example to open a GraphML file, display preview of the graph, and then draw a new edge in the preview to add a new element into the original GraphML file?

    Reply

    • Just to make things clear: “the plugin renders the text to a KPart widget.” is more correct as “the plugin pipes a snapshot file of the current text document to the KParts plugin, either by stream or a temp file, and the KParts plugin loads it and displays it”.

      Short answer: Not yet and no own plans for implementing that.

      Long answer:
      Right now the KParts plugins are only queried and instantiated as “ReadOnly”, so it is really just viewing/display only.

      For doing it the “other way around”, as you asked for, one could use the “ReadWrite” mode for those KParts plugins which have it implemented. But when I first considered this, I found no simple way for getting the KParts plugin to return the text data back to the preview plugin so it could update the text document, especially in case the text data was before streamed to the KParts plugin. After all the idea is to avoid going via the filesystem and just exchanging data between working memory models. Seems this first needs some extension of KParts::ReadWritePart API, unless one is fine with only hacking things via the filesystem.

      And syncing data in two directions complicates things a lot, both code-wise but also for designing UX. For that reason I do not plan to invest into it right now, but even more for another reason:
      After all the whole approach of the current preview plugin is rather a pragmatic hack then result of clean design. For editing a document both with a source editor and a WYSIWYG editor at the same time (someone remembers WordPerfect “underwater screen”/”reveal codes” feature?), ideally there would be a much deeper integration and mapping between source data structure and final data structure. E.g. for highlighting selected elements, but also for sync’ing edit changes or syntax highlighing. For the future I would rather see investing into designing things around such an approach. But that is just me.

      Reply

Leave a reply to Lanzado KDE Aplicaciones 17.12, un regalo adelantado - KDE Blog Cancel reply

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