Rewrite using newer technologies

[gregorni]

I really like the concept of this app, and I'd like to see it go further than where it is currently, possibly even joining the GNOME Circle one day :)

However, Spedread would have to be re-written to make use of some newer technologies in order to advance to make use of a more modern platform. Notably, the rewrite would have to make use of GTK4 and libadwaita. Perhaps it could even be extended to changing the underlying programming language, or using UI templates to define the interface.

Is this sort of rewrite a conceivable goal of the project?

[Darazaki]

I'm not planning for a rewrite right now but it'll probably have to be done at some point to properly support languages like Chinese

I'm not sure what you mean by "newer technologies" though? Spedread already support GTK4 and libadwaita although its use of libadwaita can be disabled

I agree that changing the underlying programming language would probably be a good idea considering Vala's popularity and third-party library support... With a lot of NLP library being in Python, it'd probably be the best choice for supporting all kinds of human languages :)

UI templates though is something that I'm against using when it comes to GTK. Spedread was originally written in C & GTK3 with UI templates but, when GTK4 came out, there was no proper transition guides for UI templates. Not only that but GNOME's official IDE didn't even support GTK4 UI templates and couldn't find any examples of how to use them in GTK's documentation. I simply don't trust GNOME to properly support their UI template files anymore. Sorry :/

---

TL;DR: Yes a rewrite is conceivable although not right now. The rewrite would probably be in Python. No UI templates

I've probably misunderstood what you meant by "newer technologies" so please do correct me!

[gregorni]

I basically meant GTK4 and libadwaita, I must've somehow missed that the app already uses libadwaita. However, speaking of, I don't really see the benefit of allowing the user to turn off libadwaita. You might consider just removing that option.

Python as a language choice is nice, I fully support it! 😃

Concerning UI templates: I can only recommend them. GNOME Builder's support for them is really good now, and there's even a new markup language now called Blueprint which is a lot nicer to use than XML. I think it's very future-proof, as it has a small, active community behind it, amd it's documentation is held up-to-date very well. It's also easy to look at XML examples in the libadwaita docs and translate it to Blueprint in your head.

[Darazaki]

Thanks for telling me about Blueprint! That seems like a good option :)

I don't think I'll drop the option to turn off libadwaita anytime soon though. I want Spedread's users to have the freedom to theme it for as long as possible. Maybe libadwaita will become necessary once I want to properly support Linux phones. We'll see!

[Kibranoz]

Please do not rewrite in Python.

Python makes gtk apps really slow to start.

[Darazaki]

Python makes gtk apps really slow to start.

Do you have any specific apps in mind when saying that? Do you have them installed through your native package manager or through something like Snap/Flatpak? I've never noticed that on Linux on my 12 years old laptop so I'm wondering if I just got used to the slowness or if there's something weird happening

Anyway, I'm not rewriting Spedread anytime soon so don't worry too much about it :)

[Kibranoz]

Python makes gtk apps really slow to start.

Do you have any specific apps in mind when saying that? Do you have them installed through your native package manager or through something like Snap/Flatpak? I've never noticed that on Linux on my 12 years old laptop so I'm wondering if I just got used to the slowness or if there's something weird happening

Anyway, I'm not rewriting Spedread anytime soon so don't worry too much about it :)

I made an app in Python with pygtk and yeah I see the delay. It was packaged on flatpak, but I never published it. When you run it it's fine but it definitely takes longer to start

[Darazaki]

I made an app in Python with pygtk and yeah I see the delay. It was packaged on flatpak, but I never published it. When you run it it's fine but it definitely takes longer to start

I guess I must've gotten used to the slowness then! I was wondering about the Snap/Flatpak thing because some sandboxing techs have a bad impact on disk I/O which Python requires a lot of to initialize vs a native binary. But it seems that's not much of a problem with Flatpak

It could also just be PyGTK being slow since the standard nowadays is PyGObject or some funky D-Bus connection issue but I don't know enough to tell. Do you also see the delay on apps using PyGObject like "What IP" or "GNOME Music"? (You don't have to answer if you don't feel like it, I'm just curious!)

[Kibranoz]

Do you also see the delay on apps using PyGObject like "What IP" or "GNOME Music"? (You don't have to answer if you don't feel like it, I'm just curious!)

I see a 3 seconds delay with What IP with others it usually shows up within a second.

[Darazaki]

I see a 3 seconds delay with What IP with others it usually shows up within a second.

I'm assuming others are "apps with native binaries rather than PyGObject apps"? But yeah, it makes a lot more sense why I wouldn't notice if it was 3 seconds! I was used to apps taking over a minute to launch before switching to Linux so everything feels so fast since then lol

I'll try to favor fast compiled languages over scripting languages for the future of Spedread anyway. But, as I've said before, Spedread can't currently support human languages with "hard to detect" word splitting like Chinese since it'd require relying on language specific NLP libraries which are usually made for Python. Currently I think using those will probably cause more problem that it'd solve and I'm already working on other personal projects which is why I don't want to rewrite it but I won't promise anything for the future. I'll watch for alternatives in the meantime :)