Moving from Qt to GTK?

[TheJackiMonster]

Because there are several issues related to Qt (essentially multiple crashes related to Qt theming) which is the framework we use mostly for the graphical interface, we should discuss about using a different toolkit.

One quite popular choice would be GTK which is also using a fitting license for manuskript. We could choose between the newer version 4 and the latest release of version 3 which have both advantages and disadvantages. Creating a good interface is best when you have a visual editor. Unfortunately Glade, the most advanced visual editor for GTK, only supports GTK 3 currently. So if we wanted to use GTK 4, we had to script the whole GUI or edit XML files.

So using GTK 3 seems the obvious choice but it is for one fully single-threaded and its rendering is not hardware accelerated too. That doesn't mean performance will be terrible automatically but if we don't refactor a lot of the old code base, it probably will be worse than using Qt currently.

I would suggest that even if we don't decide to use something else than Qt right now, we should definitely start abstracting function calls using Qt so that a transition is easier and causes less problems. I also think if someone decides to port over using GTK, this should happen on a fork and a separate branch first. But for now it's probably best to start improving performance and fixing other issues. I just wanted to open a discussion here.

Also choosing any other toolkit may not affect cross-compatibility since we don't want any writer to be forced changing operating system or something. That's one reason for thinking about GTK which is free and open source. Also other applications like Gimp which use GTK run on Windows, Linux and macOS just fine afaik. Please comment if you have other experiences or thoughts regarding that topic.

[Ellipsine]

Hi  ! As an user, I am not favorable of using GTK : I always have difficulties with GTK application on Windows 10. I am french, and I have some hands problem so I use custom keybord mapping : with Zim and Gajim, my keys does not work at all I have to desactivate it. So I don't use Zim at all : I really need this keyboard custom mapping to write ! I am afraid of facing the same difficulties with Manuskript, which I really appreciate the 0.12 release by the way w Thank you :)

[TheJackiMonster]

@Ellipsine Thanks for the feedback. That's exactly why I opened this issue, so we can collect certain issues with other GUI framework to make a decision how to improve Manuskript overall without breaking advantages from the given user experience.

I think we could implement customizable key bindings, so users can arrange their mapping. Would this help for a transition? How do you solve this currently (I didn't notice Qt allows something like this without developers implementing it)?

[Ellipsine]

Hi I am glad to help  ! I stop using Zim and I use other things instead. My keymap customising tool is a global software that change keys for any softwares I use because I write my novel's frist draft in plain text with FocusWriter, import it in my compil software Manuskript, I have my encyclopedia in other soft (Obisdian for interlinking and custom CodeMirror CSS for my lists and articles, right now I did not find an Opensource alternative like I did with Scrivener and Manuskript). I use this keys for writing e-mails too, tchat or blogging.

I would like to transition totaly into Manuskript for my novel as it handles plain files text in true folders. If it is possible to customise keybord mapping it would be possible for me to disable the keyboard soft, working in Manuskript and re-enable later.

For example two of my main character have their name begin with a "É". The "À" is quite frequent just like the "œ" or the "Ç" but they are not native in french keyboards :

• I add them for example, the Ç is "c" with "alt-graph"
• I swift from "%" to "œ" or the "£" to "É"

For my health, I change some of the keys places too to keep them close to my fingers too.
Maybe it would help, I use this soft : Clavier+

[TheJackiMonster]

I understand. So the keymap is mostly for writing characters and easing writing. I didn't know there was this issue with GTK because I use something very similar on Linux which just works with every application so far including GTK and Qt. For example I can switch between different keyboard layouts (for example to write japanese Hiragana) with a shortcut, add custom shortcuts via settings. Some layouts even support replacing written characters afterwards. So multiple Hiragana can be replaced with one Kanji afterwards.

So in theory GTK should already allow custom shortcuts or character maps from system level. I assume this is more a problem with the build process on Windows and how GTK interacts with the desktop environment. So maybe this can be fixed and the solution can be shared with other applications as well.

In worst case we can probably add custom key mappings for writing into Manuskript but I think being able to use global ones is much more convenient rather than configuring them twice. ^^'

[Ellipsine]

I can switch between keyboard configuration when they are saved from Windows me too but creating custom layout for Windows is much more tricky than Linux. I have tried to create my own layout that would be recognised by my system but the tools I found did not work. So I found this soft that allowed me to customise the actual keyboard layout without changing it from the system point of view.

So I think you are right : the problem may comes from the way GTK and Windows interact because Linux does not handle the keyboard layout the same way.

However, if it is really hard to do I would have not problem to customise Manuskript as well. Good tools are rare enough to spend time to make it feel at home.

Maybe GTK would be simplier to customise as well ? Would be it possible to change the composant colors (tree, bars and so one and not only the redaction leaf) ? I kown it is possible with Qt (like NovelWriter, Scrivener or QwonNotes) but I do not know if it is doable with GTK ?

[TheJackiMonster]

@Ellipsine In GTK there are ways to use custom themes mostly written in CSS. So it should be possible to change design. Maybe it will be easier if we use GTK4 rather than GTK3 but this is probably a good point to have in mind since many people using Manuskript found the Qt theming option quite useful (despite it causes many bugs ^^').

One example I know which uses GTK and allows multiple themes inside of the application itself is GIMP. So that shouldn't be a huge issue. I definitely didn't had any stability issues with theming using GTK applications which is mostly the reason to switch GUI framework. Other reasons would be that Qt is much bigger and brings a lot of libraries we don't even use. Also GTK uses the same license as Manuskript and it can't practically restrict us in any future.

There are definitely some downsides because Qt provides quite useful development tools. So we have to refactor the translation models, refactor the data models in the code (pretty much what I'm doing currently ^^) and adjust most of the logic to work with GTK after the GUI was redesigned. I've started some parts of the redesign process to see how difficult it would be and I tried to mimic the current layout of Manuskript as much as possible to ease the transition for everyone.

I'm not sure how long everything will take but I expect we will have at least one release (0.13.0) before any GTK related changes but this will mostly depend on others, I assume. ^^'

[Ellipsine]

You seem really motivated, I appreciate reading this ! :)

I am not a developper myself (sorry I am really passionate about this matter but I don't have time to learn to code myself now ^^') but I have some experiences in design so maybe I can help with GUI question related ? It seems to be a lot of works to accomplish and I hope you'll have some help soon !

I think the most important parts to keep are the way things work and not the whole look of the app. Some choices are logical or intuitive (tree on the left, leaf on the center, metadata on the right) but some menu bars could be moved to other places if the whole soft wins ease and speed. Users like myself we would learn to use it and help with documentation to help transition.

If Qt provides some tools, Python could help with some of this maybe ?

I have a question and you may have thinking about this as well but did you consider working with Electron ? As it is open source and Manuskript works with plain .md files, could it fit to this whole recoding ? Here I have test some of them an Typora and Obsidian can open +70.000word files without slowing down. I repeat : I am not a developper myself so it is only a suggestion

[TheJackiMonster]

@Ellipsine I think Electron as a tool can be useful but it has also major disadvantages. Because the concept of it is pretty much running web applications locally, it requires a whole web browser built-in as backend. We would also need to transition from Python to Javascript which isn't great for readability of the code and it could pull off most contributors.

I think the most problems of Manuskript being slow with big files isn't related to Python or even the tools we use. But the code isn't particular efficient or has a good taste. While refactoring the IO of reading and writing project files, I've found parts which copied the same data over and over again for no other reason than to use neat looking features of the Python language. ^^'

I personally come from writing very boring but efficient code in C. So when I see something like this, I understand the fun the responsible developer had but it's not good for the runtime. That's why I currently want to refactor most parts. Once we have a simple but solid and maybe even efficient code-base, it will be much easier to contribute and the application will be more useful.

Another thing I'm targeting is to use multi-threading in Manuskript without breaking it. In the past I fixed some crashes regarding multi-threading from API side of Qt which wasn't a good use. However we can for example load, save or check multiple files for spelling at once if we use the whole power of a modern processor. All of this can also be possible without slowing down the interaction with the GUI. ^^

I really hope we can get there. Because currently many people ask if there is a limit in size of words Manuskript can handle and all I think is that these are just simple text files. It shouldn't be limited at all. ^^'

[Ellipsine]

Thank you for your answer ! :)

@Ellipsine I think Electron as a tool can be useful but it has also major disadvantages. Because the concept of it is pretty much running web applications locally, it requires a whole web browser built-in as backend. We would also need to transition from Python to Javascript which isn't great for readability of the code and it could pull off most contributors.

OK let's forget about Electron :) So keeping Python, adding GTK, having some multithread and cleaning the code.

I really hope we can get there. Because currently many people ask if there is a limit in size of words Manuskript can handle and all I think is that these are just simple text files. It shouldn't be limited at all. ^^'

I totaly agree. Some basic text editors can handle 10Mo text files (an lot more for some CSV readers) without slowing down. For indication, the biggest text I have is 80.000words and 150Ko. If I refer to my experience with other tools, maybe having metadata attached to it slows the process (added with the redundant code you found)?

I really like the Json ou Yaml frontmatter format to write metadata at the top of a plain text file (markdown). You can even create customs strings to call in the software like "Point of View" "Synospsis" "Date" "Custom string 1" "Color of the mood" and the user just writes it in plain text too. Would it help to make the use lighter ? Is GTK changes the way the soft exploits metadata ?

[TheJackiMonster]

GTK itself won't change anything in handling the data as structures or format. But like I said I will refactor a lot. So the code will probably change how the data is stored and handled in memory. However the file formats all stay the same because we need compatibility for all the older projects.

[zeth]

I use Manuskript on Ubuntu and obviously it would be better in GTK for me as it would seem more native and respect the theme better. Rightly or wrongly, Ubuntu is the vast majority of Linux users.

Manukript says:

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.

If you do use QT_QPA_PLATFORM=wayland, it looks weird and you get a weird massive cursor.

[TheJackiMonster]

@zeth Sure, the benefit of fitting better into any desktop using GTK for most applications is nice. But even though I also use GNOME as desktop on Archlinux, I wouldn't want to change as much if Qt wouldn't provide horrible error handling of custom themes. ^^'

Because people want their application to look nice and fitting into their desktop. So currently the option of picking a custom theme doesn't really work while keeping the application reliable and there are many more bugs to fix in Manuskript we should focus on. So Qt doesn't help at all in that case if everyone gets segfaults because of some themes. ^^'

If you do use QT_QPA_PLATFORM=wayland, it looks weird and you get a weird massive cursor.

That's probably a combination of Ubuntu's and Qt's wayland support. So maybe this will look better using newer versions of Qt but unsure how the state of that is exactly.

[xahodo]

Hello. Just noticed this thread.

Allow me to throw a curve ball: FLTK (Fast Light ToolKit). It's rock solid and extremely simple to use. There are also python bindings floating around (pyfltk). The bindings were last updated August 29th, 2021, which is recent.

[TheJackiMonster]

@xahodo Not a bad idea. But this would have quite some drawbacks:

1. We can not create/edit the GUI as separate files to split logic and design.
2. The way FLTK operates is not really good for clean and readable code (it utilizes side-effects to connect GUI in relationships for example which could cause major issues during development being hard to track down).

In comparison with Qt even GTK is pretty much lightweight. Also we could utilize major advantages which are currently in development being well supported bindings for Python, a graphical GUI editor, separate GUI files, potential responsive UI elements and an upgrade path to GTK4 (which would bring multiple alternatives for hardware acceleration via OpenGL or Vulkan).

There's also the fact that we currently rely pretty much on Qt's implementation of translation files for text in the GUI. GTK offers at least some bindings and concepts to implement something like this. If we would use FLTK, we would need to implement a GUI with translation ourselves and the whole update process of text in all GUI elements using it.

[TheJackiMonster]

Today I could play around with a Pinephone (a phone running mainline Linux instead of Android or iOS) I received and I can report that my current progress with GTK and libhandy so far is working fine on the phone as well. So maybe we can even deal with another request (#942) at the same time to a degree.

Sure, first of all the GUI should act similar to the current design and it should keep all of its features and functionality. But maybe we can adapt the application to make it work on lower screen resolutions as well. I think if we could get there, making a GTK application run on Android as well should be a minor issue (via VM or a way to port natively).

I still need to re-implement and hook up most of the functionality into the refactored GTK version but the current progress can be tracked in my branch here. I have also checked in the past that it should still run on Windows 10 via MSYS2. The installation of this can probably be automated and for Windows 11 we could maybe even try using WSL2 running the Linux version in Windows as well.

[TheJackiMonster]

I'll now add another option besides GTK, Qt and VLK into the discussion because there are quite some issues currently with getting a build for Windows ready (even with our current PyQt setup). How about we use Godot?

It may sound weird because Godot is actually a game engine. So it's really far off at some point to build graphical user interface for writing but it contains some really basic GUI. The most problem would probably be getting webkit integrated to render formatted markdown and get pdf previews working. Otherwise it contains an XML parser and a JSON parser... so it should be pretty straight forward to load and save Manuskript files.

The downside would be that most of the source code would need to be converted from Python into GDScript probably. That shouldn't be a huge issue though because GDScript is quite close to Python in its syntax and I don't mind refactoring the code anyway.

The biggest advantage however would be that Godot allows exporting a project directly into Linux, Windows and MacOS binaries. Even newer architectures will be supported, we don't need annoying scripts, hassle with PyInstaller or any dependency issues. The binaries can be fully compact but compressed because many game developers prefer this to upload their games in their web space. The engine is also not that big either. So the binaries won't be huge as someone might think. Godot is about 80 MB on Linux and binaries could be even smaller (probably take more space than our builds currently but I doubt that's a realistic issue with modern systems).

It's only an idea. I assume this would take way more work on the front-end side to interact nicely with operating systems. For example drag & drop for external files might not be possible. Also it would require more time to make UI responsive or interact properly with user input. But if there's interest I would start looking more into it and maybe start working on a prototype.

[jdanielp]

Can you please provide some examples (issue numbers) of of the types of crashes that are because of using PyQt and custom themeing? Is there a way we can report that to the upstream project? Or is there a way we can avoid crashes in Manuskript by checking the theme first? A switch from one GUI to another takes away effort that can be spent improving performance, etc.

Also, I would caution against using threads in Python. I instead urge you to use Multiprocessing from the Python standard library. I have had great success speeding up behinds the scenes work with that module. Any help you want with that, please let me know.

Finally, you mention performance issues. Can you please add references to those issues or a specific performance tag on isssues? That will help contributors find and fix those issues.

[TheJackiMonster]

I usually tag all reported crashes with the segfaults caused by either Qt or themes with Qt. There's a link to the filtered list in the initial post here.

I assume we could report this to PyQt but I'm not sure if they could fix that. From my understanding PyQt isn't the problem but Qt itself. Overall PyQt is not even the official API to deal with Qt in Python but the most used. The segfault does not come from PyQt though but from Qt not catching issues in their loaded themes.

I would agree that using multiple processes instead of threads can make the code safer while utilizing the hardware. So that would be better, I think. I was mostly thinking about using a thread-pool to parallelize tasks instead of concurrency when talking about using multi-threading. I just don't have much experience how well inter process communication is performing on Windows and Mac. On Linux this is definitely no issue.

The performance issues we currently have are mostly related to spell and grammar checking, I'd think. At least I speed up the word counting recently quite a lot. So that should be fine. The problem with many functions in Manuskript is that they process whole files on every change even though it would only be necessary to check the changed sentence or less.

So best changes for performance would probably be about caching and decreasing the selection of data to reprocess.

[TheShadowOfHassen]

A quick note: I know this discussion is old but seeing that it isn't closed I decided to put my own two cents in. Also sorry if my message isn't properly formatted. This is only my third time every using github.

In this discussion a lot of people have talked in detail about the good points of both Qt and Gtk and some have even mentioned some other ideas. There has been less talk of the process of moving from Qt to Gtk. I have been using Gtk for around a year now and have made with it a few projects. While I am probably not as good a programmer as the rest of you, I have made a project in the same vein as Manuskript.

I don’t know PyQt, but I decided I would look at the code and see what I would do if I was porting it or just rewriting it. I looked at getting the UI itself to work, but I don’t know much about threading for spell check or anything else, although what has been said makes a lot of sense.

It has been mentioned that there are two different versions of Gtk, Gtk3 and Gtk4, currently supported. They seem to be similar, but I haven’t used Gtk4 mostly because its UI designer Cambalache lags and is (at least for me) a lot harder to use. While Glade is easy to use, anyone with a Linux system with flatpak installed can get both of them and see for themselves.

When I first wrote with Gtk3, I wasn’t certain it would be the best choice, so I made certain to separate the UI code from the rest of the program, at least by marking the place with comments. I know that isn’t always possible. You have to use Gtk.TreeStore if you’re going to use a TreeView for file directories, but most of the time a comment here and there is easy. I usually tried to put my UI in a different file than my back end. When I decided I liked Gtk3, I kept doing it because it will be so much easier when I do change to Gtk4. I would just need to replace the UI file and make the few minor changes to the GUI part of the code, and it would work. I think this was what JackiMonster was mentioning Manuskript didn’t have.

So upon looking at the latest Manuskript code, to convert to Gtk, Manuskript would need a lot of work. The UI and the back code is not separate, and while some parts like the saving and exporting would be easy, the data models require Qt a lot. Once that is done, most of the UI really wouldn’t be that hard. I can make with glade a UI layout quickly and for the welcome screen, main window, and the tabs of general, characters, world, and plots, wouldn’t be hard. You could reuse the ui files that were from the now-abandoned Manuskript Gtk fork, and if you added signals the programming would be even easier. For the Outline tab it would be a bit more complicated. I’ve been wanting to make something with the file/folder treeview thing myself, but you need to make a custom drag and drop function, so you don’t drag folders into files. I haven’t been able to figure it out, but I’m sure for one of you it’d be easy.

Finally, for the editor. The metadata and searching parts would be easy, and I think some sort of Gtk.FlowBox could work for the notecard view. Full screen view might not work with the same themes, but you could create another window and make it fullscreen with Gtk.Window.fullscreen(). The actual editor would be the tricky part. You could use either Gtk.TextView or WebView for the editor. Gtk.TextView has tags which can show bold and italic text, and at least for the beginning you could use GtkSource for the Undo/Redo function until the revision update is done. You would have to do some sort of markdown handler for either version. If you use TextView some custom theming would be useful if just for that one editor. It is sort of hard to see it opposed to the rest of the window, and I suppose it’d be the same with the other TextView. Finally, you’d need to write a spell check. Gtkspellcheck [https://pygtkspellcheck.readthedocs.io/en/latest/] is a cool spellchecker for Gtk.TextViews, and you could use it at first until you can get Language Tool and all your other options.

It would be a difficult choice. Both Gtk and Qt have their good parts, and while a Gtk version wouldn’t be hard to make, it would still take work. My guess is at least half of the code would need changed/rewritten, although it sounds like you would have to rewrite quite a bit of the code anyway and there are some good points to rewriting. I think in the case of a rewrite, a discussion could be had of what features people would find useful which would otherwise require a lot of changes in the existing code. Whatever way this program goes, I am certain that I will continue using it. Manuskript is the best thing I can find for writing on a Linux computer, and the fact that it is free makes it even better.

Also now that I’m at the end, my vote’s for Gtk.

[TheJackiMonster]

@TheShadowOfHassen Thanks for the feedback. You can actually find a WIP state of a potential transition from Qt to Gtk3, I am working on, in my fork: https://github.com/TheJackiMonster/manuskript/tree/gtk

The problem is that like you said, it takes a lot of work to rewrite it. Especially when it aims to create as little difference as possible in the general UI workflow to not confuse current users. Then I also tried to integrate libhandy already to make a transition to libadwaita and GTK4 smoother when Cambalache is out of beta state.

I'm still not sure whether it makes sense to aim for a version which is usable on a small screen device like the Pinephone but it's fun trying. ^^'

If you were interested to contribute to such a version, I could push my commits into a separate branch upstream. So you could easily create merge-requests on it. It already contains a code to redesign IO handling and very simple data structure. So most of the work required is linking up the logic for the UI. But I haven't started with the editor yet (I assume it has to be an editable WebView considering that people already requested support for images and a little bit more formatting options).

[TheShadowOfHassen]

I am not on top of all things gtk, and as I said I am a beginner to Github, but I would like to try.

If you think it would be easier to do a different branch I'll take your word for it. But I wouldn't know exactly where I would start working and It might get confusing for the qt developers with the back in forths in issues as I figure it out.(if that is where you talk about what needs done.)

:EDIT:

On more researching on git, I think I understand the fork/ repository thing. Making another branch I think is the only way to do it. However It might want to set up a special tag for the Gtk version for issues/ pull requests. I have a thoughts on the code already written for the character UI.

[TheJackiMonster]

GNOME developers seem to consider dropping the macOS CI for GTK which means that GTK might get incompatible with macOS in the future (or even more than it might be now).

We should definitely discuss that since we recently made efforts to bring binaries for macOS back and these changes might kill the option with a GTK port. On Windows we definitely have multiple options, I can think of (via WSL in worst case) but on macOS that's not really a valid option.

[TheShadowOfHassen]

GNOME developers seem to consider dropping the macOS CI for GTK which means that GTK might get incompatible with macOS in the future (or even more than it might be now).

We should definitely discuss that since we recently made efforts to bring binaries for macOS back and these changes might kill the option with a GTK port. On Windows we definitely have multiple options, I can think of (via WSL in worst case) but on macOS that's not really a valid option.

That is an issue.

[TheShadowOfHassen]

Ok after more thinking about this I have a few thoughts and questions. I'm assuming that Mac OS has to be a release platform of Manuksript (As it should) So first is GNOME doing it because Mac OS is snobby or are they doing it because GNOME'S snobby?

The first and possibly simplest solution would be: Anybody with an Apple computer want to step up and help?

Second thought is, sure GNOME who is currently developing GTK might refuse, but there are quite a few apps that use GTK on mac. First of all is GIMP, which made GTK. If Mac OS support is dropped will they step up? That might not be pygobject or anything but its a thought.

The second solution could be that we drop the gtk. But what do we switch to, QT6? That could work but it really isn't as good as GTK with the UI design. Also I'm loth to suggest QT because every other open source writing program either uses web-view or QT. I also don't like QT's default look, but that could be fixed with theming

Another idea is as we're separating the UI from the back code we could have a separate port for mac os running cocos. (We could do the same with Windows but I don't like their native GUI toolkit.) Of course, cocos might not have the .glade design stuff either...

There seemed to be a lot more webUI based python tools since last time I checked like:

https://anvil.works/articles/python-gui-builder-web

However if we don't want web (and for some reason I don't) the only options are GTK or QT most of the other graphic toolkits for python is miles behind... Of course we could always make our own.... MTK anyone?

[TheJackiMonster]

So first is GNOME doing it because Mac OS is snobby or are they doing it because GNOME'S snobby?

There are just very little developers on macOS which contribute to GTK, I would think. So it does not make sense for them to run a CI which nobody can properly debug, I assume. I don't think it has opinionated reasoning.

First of all is GIMP, which made GTK. If Mac OS support is dropped will they step up? That might not be pygobject or anything but its a thought.

GIMP is currently transitioning from GTK2 to GTK3 because they are lacking UI/UX developers maintaining it. So I would not rely on developers from GIMP to solve this.

But what do we switch to, QT6?

Qt is definitely causing issues at the moment. We would still need to do a whole refactoring to be sure no multi-threaded code exists which causes a random crash or similar. Then still theming can cause a segfault. So I don't really like the idea to invest a lot of time into using a GUI toolkit which likely still causes issues in the end.

I would also think sticking to Qt5 would make more sense than going to Qt6. There are currently a lot of issues around the KDE desktop in their transition to Qt6. So I wouldn't expect it to be a silver bullet to our current instability.

The biggest advantage the current efforts with GTK has is that it separates data from UI. So technically we could have multiple GUIs on top. I'm just not sure what would make sense for macOS. Likely a semi commercial variant as Qt... I definitely don't see a macOS specific GUI as a valid option as long as we don't have any developer who's going to implement/test/maintain that.

[TheShadowOfHassen]

I would also think sticking to Qt5 would make more sense than going to Qt6. There are currently a lot of issues around the KDE desktop in their transition to Qt6. So I wouldn't expect it to be a silver bullet to our current instability.

I don't know anything about QT, so I take your word for it. That said, if someone can point me to a really good tutorial...

Likely a semi commercial variant as Qt...

What? Like a payed version on Flatpak?! Please clarify because this is a kind of big deal. If so I have a few thoughts on that. (Not all of them are bad but-- it's not something that should be taken lightly, and it probably should have its own issue)

The biggest advantage the current efforts with GTK has is that it separates data from UI. So technically we could have multiple GUIs on top. I'm just not sure what would make sense for macOS

Firstly this would require us to have multiple repositories, which is impossible with the current set up. Well, you could do it with branches but it would be far more effort than just setting up a GitHub project. However, if we did do this we could run android and ios apps with Kivy (I know just enough kivy that I could do it.)

However, if we had more than one repository the people who can approve of PRs needs to be expanded. I understand @TheJackiMonster that you are doing this basically by yourself and that you're busy, but I've had a PR created in April that is tiny, and you(or anyone else) haven't commented on it. If we're going commercial/bigger open source we need to approve PRs faster. But this is also something that would need to be discussed in another issue (Probably with the commercial stuff.)

So by what I'm seeing our best bet is having a Linux/Windows GTK port and another QT port that could run on everything (Including Mac OS) and while we're at it I can probably start a Kivvy for android/ Mac OS.

I was only partly joking with MTK if we could write a cross platform GUI toolkit it would be cross platform. But of course it would mean a lot more work.

[TheJackiMonster]

What? Like a payed version on Flatpak?! Please clarify because this is a kind of big deal. If so I have a few thoughts on that. (Not all of them are bad but-- it's not something that should be taken lightly, and it probably should have its own issue)

What I meant is that Qt uses a license model which allows commercial use. So people are more likely to use it for macOS applications which typically cost money (compared to Linux there are only very few people who write FOSS for macOS). That means the developers behind Qt also have an incentive to keep macOS supported as well as Apple has a reason not to break it (not that this would matter as much though - they break a lot of compatibility lately).

I think separating the back-end into a different repository might make sense. I am not fully convinced we need more people approving. I think you mean we need more people reviewing. All I can say is that it might make sense to work on your fork if I'm too slow in reviewing and merging. I mean git is a completely decentralized tool. We can still merge anything later. I definitely don't want to start merging things without proper review into the GTK port. Because that's how the Qt code got so complicated... probably.

Most PRs in the past I actually merged right before a release, I think. I also don't want to add too many new features into the GTK yet. Because I actually want to make a release with Qt and GTK in parallel. So people can actually test whether it improves the application or not. If we change too much right away, it's far more likely people stay with the old Qt application even though it has this instability. So GTK should not change the experience at this point.

@TheShadowOfHassen What I could offer now (to have things merged faster) is opening a gtk-next branch which I would already merge your changes when you think they are ready. Because you are working on quite a lot new features and other people might have it easier to test them then. I don't have any issue with you working on new features (that's good). It's just not bringing the GTK port release any sooner because much of the expected functionality is still missing unfortunately. So I would keep adding all the changes from the gtk branch in sync with the gtk-next branch and when the first GTK version could be released, I would merge everything from gtk-next afterwards for the next release. What do you think?

Obviously none of this would matter if we don't use GTK but the only other GUI I might consider as option is Godot. However as mentioned in some comment here before, it's likely that this would require much more work to get UI components act as expected and we either need to use a Godot build supporting Python (which exists) or switch from Python to GDScript (which is quite similar to Python). I'm not sure how well that would work for most contributors. But at least Godot supports exporting to Windows, Linux, macOS and even mobile platforms. That means for compatibility it might actually make the most sense.

[TheShadowOfHassen]

What I meant is that Qt uses a license model which allows commercial use. So people are more likely to use it for macOS applications which typically cost money (compared to Linux there are only very few people who write FOSS for macOS). That means the developers behind Qt also have an incentive to keep macOS supported as well as Apple has a reason not to break it (not that this would matter as much though - they break a lot of compatibility lately).

Yeah, I think porting anything to Apple's going to be a struggle. QT is a better bet for that.

I think separating the back-end into a different repository might make sense

I honestly think it does. If we have a repo for the back end, and only work on that, Qt and Gtk would be done pretty soon. We could have separate repos for each version we want to make or other things. I saw that someone made a docker image. We could put that on a centralized repo as well. We could focus on Manuskript core first (and for some reason I want to write a command line GUI for it) and then people can do qt/ gtk/ kivy/ web/ whatever we want.

Of course that would require this repository to be transferred into a manuksript organization because if we have the core on your repos qt on this and so on, no one would find anything.

I am not fully convinced we need more people approving. I think you mean we need more people reviewing.

I do think that eventually it would be nice to have more people both reviewing and approving. I was working on something for battle of wesnoth and a lot of people reviewed my PRs. Most of the people who reviewed could approved but mostly they waited and let their writing expert to do it. They had it set up that everyone had to get a review before merging their changes. That might be smart here so no changes get done without proper reviews/approves.

Actually, I do think with multiple repositories having more than one person with the ability to approve would work. I know this repo did have that but now everyone else left. The reason I think more people approve is because if we do have multiple reops, that's a lot for one person to handle, even if we aren't overflowing with PRs.(At the moment but I hope that changes)

Most PRs in the past I actually merged right before a release, I think. I also don't want to add too many new features into the GTK yet. Because I actually want to make a release with Qt and GTK in parallel. So people can actually test whether it improves the application or not. If we change too much right away, it's far more likely people stay with the old Qt application even though it has this instability. So GTK should not change the experience at this point.

Smart. However, after we have a QT and GTK will their features be done in lockstep(and be exactly the same besides UI) or will each project be allowed a bit of wiggle room to make their own changes.

What I could offer now (to have things merged faster) is opening a gtk-next branch which I would already merge your changes when you think they are ready. Because you are working on quite a lot new features and other people might have it easier to test them then. I don't have any issue with you working on new features (that's good). It's just not bringing the GTK port release any sooner because much of the expected functionality is still missing unfortunately. So I would keep adding all the changes from the gtk branch in sync with the gtk-next branch and when the first GTK version could be released, I would merge everything from gtk-next afterwards for the next release. What do you think?

A gtk next would be nice. I want to help on some of the core work but I can't figure out Manuskript Core. I figured out how it could handle the huge file (by just not reading anything other than the first directory of files) however I still can't figure out how, if you keep all the data stored in RAM how you're going to work git. Also you said that the unzipped version of manuskript was stored in a temporary folder, but I found it in the directory with the msk file.

It would be great if you wrote something how you A. wanted core to function. B. How Git will attach with tracking. Then I'd be able to work on that!

Obviously none of this would matter if we don't use GTK but the only other GUI I might consider as option is Godot. However as mentioned in some comment here before, it's likely that this would require much more work to get UI components act as expected and we either need to use a Godot build supporting Python (which exists) or switch from Python to GDScript (which is quite similar to Python). I'm not sure how well that would work for most contributors. But at least Godot supports exporting to Windows, Linux, macOS and even mobile platforms. That means for compatibility it might actually make the most sense.

I think a web UI makes the same amount of sense as Godot in regard to compatibility. And I'd be leaning towards a web UI because with Godot I think it'd be extremely hard to even with python bindings get things like Language tool and attach them to a text UI. Besides Godot's UI doesn't look really good, (but that might be able to be fixed)

Another curve ball is someone wrote a glade like designer for Tkinter, so we could try Tkinter. It also has a very ugly old looking UI system but theming might fix that, and with Tkinter we have python's support.

[xahodo]

Curve ball number million.

Why not move the whole project to rust and FLTK?

Yesyes, C++ is the native language of FLTK, but there's a well maintained wrapper library for rust which functions on Linux, Mac, and Windows.

Rust runs on Windows, Mac, and Linux too. Compiled binaries should be way nicer to provide to people. Rust statically links by default, and forces the developer to work in a clean way.

Why not C++? Well, C++ has issues... Somewhere in the distance you hear maniacal laughter.

GTK looks like an alien on anything other than GTK based desktop environments. For consistency's sake, you should at least have the application look like an alien on every platform! At least the remark "OMG this application looks horrible!" will come from everybody, so everybody will be in agreement for once. :D

[TheJackiMonster]

@xahodo I neither want to go to C++ or Rust with this project, I think. Manuskript is definitely an application which does not need such a complex language. Because we want to rely on external tools to do the heavy lifting anyway (like Pandoc or different spell checker libraries).

GTK's biggest advantage is also that it's heavily single-threaded. So we can't easily mess up race conditions. It's also open-source under GPL license and got official Python bindings. I don't think we want to switch the language. So Python bindings are important.

The only reason I put Godot out as option is that GDScript is very similar to Python and there are Python bindings for Godot (because it's an open-source engine). It also comes with the ability to port the whole application very easily to all popular desktop platforms. Then the UI is also single-threaded. So we can't really mess up race conditions.

@TheShadowOfHassen I agree that Godot UI does not look very fitting in its defaults. But it can completely be adjusted via theming and the themes should not be able to crash it as with Qt. ^^'

For now I'll probably check whether GTK3 is a valid option for macOS. If it's good enough for our purpose, we can probably continue with our port. Because as long as we don't plan a switch to GTK4 soon with that, it shouldn't matter as much that GNOME developers don't run a CI anymore. It'll just take some research.

[TheShadowOfHassen]

@xahodo I'd love to learn Rust. I think it's a good looking programing language. However, There are two big points to Manuskript A. it's a program using only free and open source software and B. it's written in python.

@TheJackiMonster If this project got bigger, we could use donations to allow some of our smarter developers(not me) to have time to work on getting GTK4 working on Mac OS. We don't have to complain how unfair it is because we can actually do something about it. Of course, I don't know how the donation works but I think they currently all go to olivierkes.

But of course we don't have to worry about it because GTK3 is out of active development and in order to move to GTK 4 we need cambalache and that thing is taking its time.

[ghost]

I concur with @xahodo, the UI experience with GTK is very variable depending on the application, GTK version, and the user's desktop environment. For a long time Inkscape and GIMP didn't look good on KDE using dark mode. Only recently (maybe since GTK4?) have things looked way better.

Concerning Rust, I'm not sure how many contributors it will cost to switch to Rust. It has a strong ecosystem, but the language is nowhere near as popular as Python. However, it would allow splitting the application in to a library/core and UI. That would allow writing clients in any language on top of the core.

Rust has two great libraries that allow generating desktop and web applications: slint and makepad, although admittedly makepad is quite beta. They do allow creating modern looking GUIs and work is being done to support mobile as well.

[xahodo]

Rust has two great libraries that allow generating desktop and web applications: slint and makepad, although admittedly makepad is quite beta. They do allow creating modern looking GUIs and work is being done to support mobile as well. Slint is a commercial product. I guess they would require you guys to pay. Makepad isn't finished, so you might run into problems there.

There is a wrapper for fltk (1.4 development branch) which is quite complete. On top of that, the developers of fltk and it's rust wrapper are very active. Fltk supports Windows, Mac, and Linux. It's also quite simple to learn and extremely flexible.

By default it looks like an alien everywhere, but there's a bunch of built-in theme's available, and the rust developer has created a theme crate.

[obw]

I think a language change is actual not the bast way for Manuskript! Also, a compiled language would have some performance enhancements!

Besides RUST would be my first selection for a compiler based version. Which language would be best, I don't know, myself learning D, there is also classic C++, GO, or why not use a Java VM based languagelike Java or Scala...

I think as I said before the step to GTK and using Python is at the moment the best way! Later we could switch completely, or partly to compiler based solutions!

For my Part think, a partial solution is the best way, because then we can reuse most of the existing code base!