Qt WebAssembly has issues with input method support, such as the touch keyboard not appearing correctly and the inability to input CJK characters. While it is theoretically possible to work around these limitations, there are likely to be many dependency and compatibility issues need to fix.
1 Like
Fair enough, I get it, and no one individually means any harm Iām quite sure. It just adds up without actually adding anything, if that makes sense. Anyway onward.
Web stuff, for some things can be great. Weāre of course using one right now, one that is geared to work as a communication system that keeps said communication preserved and publicly recorded. I like this particular tool, and what it providesābut if someone were to make a solid top-to-bottom native GUI (not an Electron container to be clear) for Discourse, thatās what I would use! I would still appreciate that it had an online record, and an interface for those that didnāt want to install software to use it, but I would probably never come back here save to keep the site updated and verify the updates work well.
But there is something to be said also for where a thing began, and how often difficult it is to fully replicate a thing somewhere else. There is no full-fledged, admin to user level Discourse GUI. Itās a huge web app and it would take an enormous effort to bring it to the desktop.
The same is true of Scrivener, and I donāt even know how it would accomplish some of the things it does in a web context. Compile through Pandoc and LaTeX whilst pulling from a 3gb archive of high-res images, and out to an optimised PDF? I donāt know how that would work. 
1 Like
Wow, I didnāt get that from your posts at all. I must be losing my powers of perception!
Apols for any offence ā I was simply making a personal observation tangential to the general topic that I found interesting, and not trying to in any way imply any kind of relative merit, etc.
Hooray for Android and all the people that want to use it?
This is the internet, dude. None of it adds anything.
3 Likes
I have a prototype (NextJS web app) that can sort of read RTF. The basics are not hard. But actually building out the whole UXā¦ Also, I donāt even want to think about Compile. Also have novels to write and a day job, so, yāknow.
But it has bubbles! 
4 Likes
The RTF problem is one that even those using the wide shoulders of Electron find a struggle. There is RTF parsing, and then there is parsing. Itās one thing to write out your own .rtf, and read it later, but with Scrivener we have to also read the chaotic metric ton of RTF codes that word processors over the decades have saved in different patterns. Libraries can help a lot of course, but thatās one area web development seems distinctly lacking. It makes sense, as RTF kind of faded off of common usage in the same era web development arose. Why code for the past?
But yes, fun fact is that the compile code base is probably larger and more complex than the entire iOS version of Scrivener from top to bottom. Itās something I always think of when there are requests to port the whole of Scrivener to a tablet.
Of course with the Qt version of Scrivener, we could just dump all 500mb of it onto an Android tabletā¦ maybe even iOS, but it wouldnāt look very pretty without an awful lot of work.
1 Like
If it can offer a fairly complete feature set, I think a bigger package size is totally a reasonable trade-off. The native iOS version of Scrivener is missing some thingsālike keywords, custom metadata, and a proper outliner editor, more frequent pop-up dialogs also disrupt the flow state during editing. Thatās fine on an iPhone or iPad Mini, but on an iPad Pro or larger Android tablets (11"+), those limitations really start to show.
To me, the most important thing is what an app can actually do. Whether itās elegant comes second. If it can handle a full writing workflow, then a larger package size really isnāt a big deal. Honestly, 500MB isnāt even that largeāIāve got plenty of apps on my phone that are bigger than that, packed with ads, promotions, and random features that have nothing to do with what the app is supposed to do. Iāve even seen a message app have an Unreal Engine 5 insideā¦ I genuinely donāt know how that even happens.
Touch support is also important for tablets, Windows already has touch capabilities. Iād suggest getting the touch experience better on Windows first, then porting the app to other platforms as a whole. Using the same implementation across different platforms can also help reduce development costs and allow optimizations to benefit all platforms.
Qtās touch interaction isnāt particularly good, but it is sufficient for writing. The main work would be to handle gesture in the binder and editor, prioritize scrolling over dragging documents and text, and may need a theme with larger buttons and more spacing between elements.
I believe large screens and keyboards are what really enable productivity, and professional writers are unlikely to want to finish an entire novel on a phone using touch input. Touch input is better suited for revisions or capturing ideas on the go, or when using a keyboard is inconvenient or you forgot to bring one. Therefore, UI optimization for phones and smaller screens can come later.
1 Like
Itās risky to make assumptions about the āmain workā in a complex application like Scrivener. You might be interested primarily in writing, but I spend more of my tablet time with the Corkboard than the Editor.
1 Like
Same issue, needs to handle gesture, prioritizes scrolling over dragging the Index Card. Binder, editor, and inspector all need to handle this, plus a few other places where scrolling might be needed. Itās only concentrated in a handful of spots, not everywhere.
Do you really think the Corkboard in Scrivener for iOS is well designed? I double-tap an index card to edit it, then a big details dialog jumps right in front of everything. How can I edit this index card while still seeing the text on the others?
Also, I canāt quickly create or delete index cards, everything relies on buttons, there are no keyboard shortcuts (CMD+N not work though it exist), and I have to tap āEditā in the top right, manually select items, then tap delete in the bottom right.
Donāt tell me all I need is to rearrange the index cards.
The compile feature is extremely basic.
No collections, no keywords, no custom metadata and no snapshots.
Porting isnāt perfect, but itās still a relatively low-cost approach to development, and probably the best way to save the different features that different users care about. Iām not against keeping the native version either.
For certain tasks, iPadOS can be a better fit than macOS. For example, syncing in the Adobe Cloud is smoother and less prone to issues, and tasks like image and video editing are more efficiently optimized. This is just because iPadOS is a newer, better optimized operating system than macOS, though it does come with some limitations. Iād say that iPads are excellent for quick media production on the go, possibly even surpassing macOS devices like the MaxBook Air. Just my 5 cents.
I for one would abandon Scrivener/the new app if it ever became a QT or any type of web app on Mac and iPad.
I donāt get the push in some quarters to accept decidedly second rate solutions on those platforms.
4 Likes
Fine.
Itās simply a balance between functionality and elegance. Iām not trying to replace existing versions or make developers give up any efforts theyāve already made.
If developers had unlimited resources and time, it might be more appropriate to rewrite the AppKit version of Scrivener using Swift UI. I remember they said they would rewrite Scapple in this way before, but I havenāt seen any results yet.
Iām going for functionality AND Elegance.
Iāve tried several PWAās and seen the results of ācross platformā development. Almost always disappointed with both.
1 Like
PWA is a webpage. It relies on GPU acceleration, and a large number of text rendering is easy to get too laggy. It seems that only large companies can handle it well, such as Microsoftās VSCode, but other editors, such as Notion or Typora, will get too laggy with only 10000 characters.
I donāt like PWA. And PWA has to be written from scratch, rendering RTF into web page elements and editing them, which is very laborious.
In fact, implementing RTF parsing and saving from scratch has always been one of the most troublesome tasks. Apple provides a Foundation to address this issue, but other platforms do not, so if developers want to develop an Android version, they can only choose between porting Qt to use a exist parser or implementing a new one. (There are still slight differences in RTF parsing between Scrivenerās Mac and Windows versions, such as default font rollback. I can imagine that there will be more differences after introducing the third implementation.)
Simply parsing the project structure of Scrivener and implementing views such as Corkboard and Outliner is not complicated. I once wrote a demo using Flutter to verify its feasibility. Its appearance is very similar to Material Design 3, and the operation logic is also very native, but it lacks a complete parsing of RTF. Due to its poor keyboard and mouse operation experience, I gave up on it. If someone can achieve complete RTF parsing, they can fork the repository.
If I were building a Scrivener clone (and I stress very much I am not about to do that), Iād not use RTF internally. Markdown + custom codes (Iāve already built multiple CMS that do just this in NextJS). But thatās yet another thing 
2 Likes
It was developed as a helper for Scrivener on the Android platform, rather than as a standalone writing application or a clone of Scrivener, therefore, parsing RTF is very important. It simply allows editing of more metadata compared to the official iOS version.
But creating a full Scrivener clone would not bring much economic benefit and would also involve legal risks. This is also the reason why I gave up. Rather than creating a clone and constantly overcoming various development and compatibility challenges, it would be better to consider how I can contribute to Scrivenerās cross-platform support. I have already completed and submitted a new module for payments and licensing to the developers, and they have confirmed that it can help accelerate cross-platform implementation. If they are willing to share other difficulties they are facing, I would be happy to help as well, since I really like Scrivener.
In the novel-writing software I am currently developing, I use plain text only, because more complex styles and formatting are not accepted by online fiction platforms, and the traditional publishing industry in my country is on the verge of decline. These platforms demand extremely fast update speeds, leaving authors little time for revision and editing, which often results in many errors and inconsistencies in the text.
To address this, I implemented a character database to help authors better manage their characters. The software can automatically recognize characters and suggest their traits, manage different states of the same character, and use AI to detect issues in character behavior, such as out-of-character (under development). The character database can also help authors communicate with illustrators, enabling them to create more accurate illustrations. This is especially useful for light novel writing.
3 Likes
Scrivener would not exist without the Apple TextKit it uses, as that saved Keith ā a novice developer at the time ā from having to create a text editing and formatting system from scratch. (And the lack of such a tool kit for Windows is part of why the Windows version lagged so far behind the Mac version.)
Would that still be the best choice now? Developers love Markdown, but itās not clear to me that itās the best choice for people who just want to write. WYSIWYG displaced markup languages in the first place because it doesnāt force you to litter your manuscript with codes and then visualize what the outcome might be. OTOH, rendering/preview tools are a lot better and faster now. And, as you say, the requirements of electronic publishing are different from the requirements of print.
Still, I detest Markdown for anything longer than an email. I donāt think Iām alone in that.
8 Likes
Apart from short blog posts, I detest Markdown!
2 Likes
The webapps Iāve built the user doesnāt see that itās markdown. Itās just how itās stored. All the regular key shortcuts etc work for formatting. Internally, I store markdown, and some light sprinkling of custom [[code]] [[/code]] - which is super easy to convert into whatever (or strip).
The user need not know how any of that works any more than a Scrivener user needs to know how RTF works (or even what it is). But itās soooo much easier to work with.
All the user has to do is type.
2 Likes
Webapps, the other for me.
1 Like