KDE Welcomes Ghostwriter To Its Collection Of Apps

[Awesomeness]

A new markdown editor

Ghostwriter is not a new markdown editor, it's just a newly adopted into the KDE family. It's available and stable since years.

[skeevy420]

Ghostwriter is not a new markdown editor, it's just a newly adopted into the KDE family. It's available and stable since years.

That's what I meant. It made me wonder if there was a specific use-case, to get a specific feature added under the KDE umbrella, or just because they wanted to.

[evil_core]

Typo.

It's not AJR, but ARJ. It's clear if you read Nate's blog.

It would be clear even for always-offline folks that are old enough (MS-DOS, Win3x and Win9x times ;-)

[FeRD_NYC]

Just tried it and, ugh, let me guess. It's written using Qt Quick? ...because, aside from the general "kinda Electron-y" look to it, which could just be a custom QWidget style sheet, the menus (including context menus) go from GNOME-esque drop-shadow blur borders I never asked for with compositing enabled to no borders at all with compositing disabled.

The latency on updating the split preview is lower than in ReText, but I think the uncanny valley-ness of the Qt Quick-based UI means I'll stick to ReText for my non-fiction writing in addition to sticking to FocusWriter's "this feels like it's gone through more dogfooding by an actual author"-ness for my fiction stuff.

GhostWriter contains zero QML, zero Qt Quick, and is implemented entirely in C++ using QtWidgets. Heck, it doesn't even use any QtDesigner .ui files to build the interface. Consider that you may be imagining things you find distasteful, to justify your knee-jerk aversion to the application.

The HTML preview — only — is built as a React webpage that gets loaded into a QWebEngineView (and which has access to file:/// URLs enabled, since web content is frequently made up of more than one file), which would explain both the slight update delay you've termed the "uncanny valley-ness of the [...] UI" and the need for filesystem access. An XDG portal can load a file, but it can't connect the previewer to an entire directory tree's worth of HTML content.

Just because GhostWriter has a distraction-free option, doesn't mean it's trying to be a direct competitor to FocusWriter. Clearly, some of its feature set and UI took inspiration from FocusWriter, but they each have features the other doesn't. (GhostWriter, for instance, supports not only syntax-highlighted markup editing and side-by-side HTML preview of its content, but even embedded images and LaTeX formulas (which are rendered by MathJax). FocusWriter, OTOH, edits plain text, RTF, and ODT, making Windows Wordpad a closer analogue than GhostWriter.

(Also, why the heck does the Flatpak release want network permissions?

ISTR that coming up over @ the old GitHub repo for GhostWriter, and there was a reason for it. It might be that one of QtAwesome (the font manager), MathJax, or React will auto-download... something, when necessary, for the preview... but don't quote me on that. (Ahh, heck, who am I kidding? If I'm wrong about that, feel free to mockingly quote me as desired, I'll have brought it on myself.)

[ssokolow]

GhostWriter contains zero QML, zero Qt Quick, and is implemented entirely in C++ using QtWidgets. Heck, it doesn't even use any QtDesigner .ui files to build the interface. Consider that you may be imagining things you find distasteful, to justify your knee-jerk aversion to the application.

Actually, I was reacting to how alien the widgetry looks and feels compared to the rest of my KDE desktop or the many other Flatpak-installed Qt applications I'm also running.

I'll admit I made an assumption (and we all know what that does to you and me), but the underlying complaint (that its look and feel reminds me more of the Discord tab in my Firefox than of the other QWidget applications on my KDE desktop) remains valid.

If anything, "must be Qt Quick" stems from my "find the most favourable interpretation" training from the constructive debate course I took in university because, if it's QWidget-based, that makes it worse because that means someone (either the author or the Flatpak maintainer) went out of their way to break from the by-default platform consistency that QWidget offers on a KDE desktop.

(I'd consider the possibility that it's written in Qt 6 and it's a Qt 5 vs. Qt 6 thing, but I installed Qt 6-based QDbusViewer and Qt Designer off Flathub before I realized they were the Qt 6 versions and they didn't look that alien.)

The HTML preview — only — is built as a React webpage that gets loaded into a QWebEngineView (and which has access to file:/// URLs enabled, since web content is frequently made up of more than one file), which would explain both the slight update delay you've termed the "uncanny valley-ness of the [...] UI" and the need for filesystem access. An XDG portal can load a file, but it can't connect the previewer to an entire directory tree's worth of HTML content.

By "uncanny valley-ness", I'm talking about things like the styliing of the widgets outside the preview pane and how I had to turn off dark mode and switch away from the default theme to get an editing pane that matched the default QTextEdit styling specified in my KDE System Settings. Styling that deviates from the system theme should be fully optional and fully opt-in.

Thus my semi-tongue-in-cheek "Didn't we fight a war to get prefers-color-scheme: light in CSS? Why are ostensibly native applications now starting to feel less native than random websites? Grumble Grumble. You damn kids get off my lawn."

(If you're not familiar with it, it's a CSS media query that allows the dark/light mode preference to plumbed all the way through from your OS control panel through the browser to the website's CSS styling. Much more involved than "QWidget widgets default to picking up the color scheme set in KDE System Settings".)

Heck, it wouldn't surprise me if it also makes you work hard to get accessibility as good as a defaultly-themed application. My friend whose vision is so bad that he's considered legally blind doesn't choose the widget theme on his Windows machine for the aesthetics of it.

I only mentioned the slight update delay to say that it's not as slow as ReText, which I currently use for non-fiction writing.

Just because GhostWriter has a distraction-free option, doesn't mean it's trying to be a direct competitor to FocusWriter. Clearly, some of its feature set and UI took inspiration from FocusWriter, but they each have features the other doesn't. (GhostWriter, for instance, supports not only syntax-highlighted markup editing and side-by-side HTML preview of its content, but even embedded images and LaTeX formulas (which are rendered by MathJax). FocusWriter, OTOH, edits plain text, RTF, and ODT, making Windows Wordpad a closer analogue than GhostWriter.

Fair. ReText is closer to what you describe and Ghostwriter's intentional "make the QWidget GUI feel non-native"-ness means I'll continue to use that over Ghostwriter too.

ISTR that coming up over @ the old GitHub repo for GhostWriter, and there was a reason for it. It might be that one of QtAwesome (the font manager), MathJax, or React will auto-download... something, when necessary, for the preview... but don't quote me on that. (Ahh, heck, who am I kidding? If I'm wrong about that, feel free to mockingly quote me as desired, I'll have brought it on myself.)

Ahh. My opinion is "that explains but does not excuse it". A local application should not be prone to surprise breakages when you find yourself without network connectivity.

I also don't like the idea of my documents breaking similarly. At best, things where the URL may be injected by the application (MathJax?) should be bundled into the Flatpak and there should be a "Download and embed resources on detecting URLs" checkbox in the settings dialog that's concerned with things it can't bundle, like markup for embedding images.

[FeRD_NYC]

If anything, "must be Qt Quick" stems from my "find the most favourable interpretation" training from the constructive debate course I took in university because, if it's QWidget-based, that makes it worse because that means someone (either the author or the Flatpak maintainer) went out of their way to break from the by-default platform consistency that QWidget offers on a KDE desktop.

(I'd consider the possibility that it's written in Qt 6 and it's a Qt 5 vs. Qt 6 thing, but I installed Qt 6-based QDbusViewer and Qt Designer off Flathub before I realized they were the Qt 6 versions and they didn't look that alien.)

Yeah, I definitely don't think it has anything to do with Qt5 vs Qt6. At least under GNOME, applications built with either look basically identical. (At least, until Qt6-on-Wayland starts bugging out and detaching dropdown menus from their position on the menubar, for some reason. Or makes the draggable region of the window borders approx. ¼-pixel wide, so it's nearly impossible to grab onto them... There are tells, is what I'm saying. But they're based more in the interaction than basic look-and-feel.)

i'm not involved enough in the KDE project to have a sense of whether it's a "big tent" enough that GhostWriter will continue to enjoy the latitude to go its own way, in terms of UX design, of if it'll be slowly edged more into conformity with the other standard applications. If it was GNOME, I'm pretty sure they'd browbeat the application's developer until either the application design conformed, or the author decided to pull the ripcord and strike back out on their own. The GNOME team have a history of being very opinionated, even about the design of outside projects.