[Qt-creator] QtCreator Markdown Plugin

André Pönitz apoenitz at t-online.de
Wed Apr 14 11:20:48 CEST 2021

On Mon, Apr 12, 2021 at 06:51:44PM +0300, ahmet erdinc yilmaz wrote:
>    I'm very glad to hear that you liked the plugin, thank you!
>    As discussed in
>    [1]https://forum.qt.io/topic/124822/qtcreator-markdown-plugin, I really
>    want that it is included QtCreator by default, but I don't know whether it
>    is possible or not for the following reasons:

Note that the following is my personal opinion, not necessarily a final decision.
>    - Plugin depends on qtwebengine and qtwebchannel modules which do not ship
>    with the QtCreator by default.

I am afraid, this is actually a show stopper /for me/, for one and a half reason:

One reason is that any application depending on QtWebEngine needs to be able to
ship security updates on short notice and practically needs to run in an "always
update" mode. For Creator that's neither possible nor desirable. First, there is
simply not the manpower to create ad-hoc releases. Second, people use Creator for
long-term projects, effectively with a version fixed for the duration of a
project. As a data point: I've seen 2.4.1 in active use last year.

The half reason is that webengine is, sorry for the bluntness, *FAT*. This impacts
the whole development cycle, starting with developers needing to have/build
(Qt)WebEngine, witnessing impact during development like debugger start up, over
packaging/ shipping, to actual use. This would constantly eat into the already
mentioned scarce resources.

>    - Plugin uses javascript for parsing markdown.

This is not exactly a hard show stopper by itself as long as the performance
impact is not noticable to the user but seems undesirable as it does not really
seem to be necessary conceptually. Even though there is already a dependency
on JavaScript of some core plugins (QML Profiler, Perf Profiler, ...) and the
core itself (possible use of JS expression in the macro expander and template
parsing) this is something that I'd rather have only optionally in the long
term, and not add more "hard" dependencies on.

>    Also I really did not want to add these dependencies. As Cristian
>    mentioned the c++ alternatives, I tried c++ markdown parsers at first. I
>    played with "[2]https://github.com/progsource/maddy" but at the very first
>    examples they failed. I did not find any c++ parser that maintained
>    properly. Then I find "[3]https://github.com/markedjs/marked" (js markdown
>    parser) which is  highly maintained and used. It has many tests which are
>    actively developed. Then I realized that it is not an easy task. Markedjs
>    is being maintained by 126 developers and used by 603k clients. Also has
>    24.8k stars. This library is really mature (By the way, I hate
>    javascript). Then, I quit my C++ markdown parser dream. Therefore, I
>    forked markedjs ([4]https://github.com/erdinc09/marked) and added line
>    number data to the rendered html nodes as html attribute in order to use
>    it in synchronization of the editor and preview. If I followed other
>    options than the plugin would be useless. I also used "highlightjs" for
>    code syntax highlighting in preview. It is also as mature as markedjs. As
>    a bonus, If I have any parsing or highlighting bug I can get it fixed very
>    easily.
>    And another advantage that comes with webengie, since the parsing is in
>    the engine process you don't need to code for extra parsing thread and
>    synchronization of data. Less code, less headache I think.
>    As litehtml html rendering option there are following problems (IMHO):
>     - It is not a javascript engine, therefore we cannot use markedjs,
>    highlightjs and  we can not use javascipt DOM API to synch the preview and
>    editor.
>     - It is not fully compatible with HTML/CSS standards.
>     - If I understand correctly, for drawing texts, images, fonts we need
>    other libraries.

https://code.qt.io/cgit/playground/qlitehtml.git/ seems to solve the latter
using Qt for those "outsourced" tasks. This is, btw, also the default way
to render Help in Qt Creator, i.e. would not be a new dependency.

>    In my professional coding time (to earn money :-( ), I use IDEs Intellij
>    and vscode mainly since I am a JVM (java, kotlin, xtext...) developer (by
>    the way, my favorite is C++, Qt and QtCreator. Really!). All these IDEs
>    have these features, developers like them. I felt uncomfortable when I
>    used my plugin without any feature that I mentioned. For example, without
>    scroll synchronization after your md file gets bigger, you start to get
>    angry.
>    I like Qt and Qt Community, I will be so happy if I can help them. I
>    really want to upstream plugin but I know that it is not an easy decision
>    when it comes to dependencies. As I explained, I really tried  not to add
>    them but I can not find any other useful and maintainable option. It is
>    your decision and which decision is made, I want to help QtCreator become
>    more beautiful! Yes, she is very beautiful :-).
>     If your decision is not to upstream, then I want your ideas about
>    automatic downloading dependencies. Then it will be more useful.

There is https://code.qt.io/cgit/qt-creator/qtc-super.git/, containing Qt Creator
"core" distributions and a few plugins (Haskell support, Fossil VCS, python
extensions). Plugins there are not shipped by default, but installable into an
existing Qt Creator installations. They get a sanity check ("compiles!") on
releases and therefore more or less automatic updates when Creator core
infrastructure changes. Things there also do not have to follow 100% Qt Creator
coding conventions (even though that's of course nevertheless desirable).

Maybe that's a possible way forward for your plugin.

Nicer, from my point of view, would of course be a plain C++ solution.


More information about the Qt-creator mailing list