General discussion about the stack

[kriptolix]

Analyzing the general stack, I noticed some points to consider and some potential problems that may occur in the future that may deserve attention. Remember that these are just suggestions for discussion in the future and it is probably not the time to think about changing any of this.

1. The use of git as a dependency: git is a huge tool and does much more than the software really needs. The application build takes a long time the first time. There are options that could be better:

• gitlib2+pygit2: gitlib2 is much smaller and brings all the main features of git.

• Dulwich - an implementation of git in pure python without any external dependencies.

2. LanguageTool: LanguageTool and its dependency on Java are also huge. I don't know enough about LanguageTool to know what advantages it has over a simpler framework like using enchant+dictionaries, but it would be a point to note. Perhaps suggesting that the user install Eloquent and use the API if they choose to install it would be better than packaging everything.

3. Gtk.TextView: I have extensive experience with textview and I know, without any doubt, that it will cause problems for formatted text.

• the textview's undo-redo does not cover the insertion/removal of tags, which would mean the need to write a new undo-redo to be able to work with even the most basic formatting.

• it will be necessary to write a more complex serializer and deserializer when the text is formatted, not to mention working with images.

• Any type of more advanced visualization, such as collapsible content, is incredibly complex to implement.

As a suggestion to consider, perhaps it would be better to use a js text editor running via webkit.webview. There are several excellent open source editors and it is also very simple to write one. Working with content in HTML has many advantages for serialization, deserialization and conversion to all types of formats, in addition to an absurd amount of control over content display.

[cgueret]

1. Noted. I went for full git at first for ease but I agree it's overkill
2. I tried to ask the flatpak team if depending on another application is a good practice in general but could not get any reply. It seems the overall mentality is to pack everything so I'll stick to that for now. But I agree, LanguageTool is large
3. I thought of maybe switching to gtksourceview to have the ability to render white space characters for instance but I'd refrain from moving to Javascript. In fact I'm pondering removing WebKit for the book preview even. It felt obvious to render an epub and previous styling changes but I think I'd rather go for something simpler in the end.

As far as the text editing goes I aim to decouple that from the styling. Focusing on typing text and use the common tabs of epub. It may not cover the whole range of visual expressivity some may like to have but I hope that could be enough for a large user base already

[cgueret]

Dulwitch seems very interesting! I'll probably switch to that 👍🏻

[TheShadowOfHassen]

A solution for point two could be you don't ship language tool but give the user an in app button to download it , kinda like a plugin

[cgueret]

That's a good idea idea. I'm not that concerned with shipping a large flatpak TBH. It's not like having a large container or anything, it's just that the thing will take a bit of time to download. Not ideal but not a deal breaker

[kriptolix]

I was reading here about the differences between LanguageTools and Hunspell. Basically, LanguageTools is capable of suggesting corrections beyond grammatical ones, which is a welcome thing in general.

I ended up changing my mind about point 2. For my new app, which I named Tessela, I will focus on a less editorial use and so I will use Hunspell, but in the case of this application that aims to deliver a product closer to a finished book, I think it is the best choice.