Manuskript 0.12.0 as snap

Because some random events and a missing maintainer I became the actual maintainer of Manuskript, an open-source tool for writers (with over 1k stars on Github 😅). I didn’t really have any experience in maintaining packages until then with the exceptions of smaller packages in the AUR. However it went reasonable I would say and I published my first release of Manuskript (0.12.0).

Sure, the release had some minor issues:

  • It crashed/didn’t start on Windows. 😓
  • It performed worse though of the spell- and grammar-checking with LanguageTool, I added. 😐
  • I had to publish a fixed version for Windows (it still crashed on Windows 7 and 8, Windows XP wasn’t even supported anymore 😕)
  • I didn’t had any access to snapcraft.io, so the snap package could not be updated (it also contained some errors which made the build impossible as well). 😟

But slowly we got there. I’ve implemented a very useful script to automatically build the Windows version via Wine on my Arch Linux btw and debugged together with different people from the community how to patch it until it works on most Windows systems. The problem was actually the mixture of PyInstaller and Qt5 which generated unnecessary libraries, we needed to delete. For example QtBluetooth ended up in the zipped folder even though Manuskript is for local file editing - it doesn’t even require networking. 😅

During the time thinking about how to fix the issue with the snap package (I actually contacted the previous maintainer of the snap), I also looked into flatpaks. Short version is: We have a flatpak now which is on Flathub! 😁

But it still requires a lot of work to get close to the version you can get from the Arch repositories. It misses the PDF export preview because Qt5 is a pain to work with, creating a flatpak. Especially if you want to use PyQt5 and need its web-components. My recommendation is: Copy your flatpak from a native KDE applications flatpak or avoid it at all cost!

However since a few days I got access to the package on snapcraft.io and I could finally publish the newest release over there. I’m still making some adjustments to its configuration because similar to flatpak it’s not easy to work with. From my experience it would be a lot easier if those configuration were just bash scripts like the PKGBUILDs on Arch. I really hope it becomes easier over time.

It still amazes me a little that I could figure out how to get all those issues (mostly) solved. The next release 0.13.0 will probably come out next month and I don’t plan on needing day-one-patches. 😀

Fingers crossed,
Jacki

Read original article

Popular posts from this blog

GNUnet Messenger API: March

Image
Hi again, Last time I had big hopes to make enough progress for a first release. But I think I’m gonna delay that a bit (maybe still this month but we will see) even though I could actually complete the things, I anticipated. However here is finally the long promised video of it running on the Pinephone Pro because there’s still much to show. The back-end of the messenger-gtk application called libgnunetchat now uses the GNUnet Name Store service to manage your chats instead of using a local directory and some configuration files for each chat as before. This means that it is now possible to start the application from any directory and it will properly sync the chats depending on the account/identity selected. Next big feature is that it is possible to generate so called lobbies. Lobbies are empty chat rooms which will be shared in form of a GNS record under a newly generated zone instead of your own identity zone. This has multiple reasons: Technically your own key could
Read more

GNUnet Messenger API: September

Image
Hey, this is the last post under the topic “GNUnet Messenger API”. As mentioned last time I only had a few remaining things to implement in the messenger-cli application. So that is pretty much what I did with some small caveats. The only thing not working as planned is file sharing. Let me explain this: You can already write a file path to your text input and it will send the file. When a file gets received, you can select the message, hit ENTER and download the file. However depending on your GNUnet setup uploading a file might not work. This seems to depend on user access permissions of your selected files. The best work-around I know is to use a single-user installation for GNUnet. But I hope that this can be solved properly, so users don’t have to mess with configurations. More information about this issue can be found here . The second missing part is that you can technically download the file and progress of that will be visualized. However there’s still no opt
Read more

GNUnet Messenger API: February

Image
Hi there, At the beginning of the month I didn’t think to make that much progress. But now I get the feeling that the GUI client could come to an end next month. Why do I have this feeling? It’s looking really good already, not gonna lie. So as stated in my last update in January, loading older messages needs to be implemented as well as switching accounts during runtime. Now it is. Getting older messages still needs some tweaking to not load all older messages but it’s good enough for now. image of messenger-gtk account selection Switching accounts was more difficult to implement because I had to go back looking into the Messenger service of GNUnet itself, fixing that the service will run as user to make use of the same EGOs as the client side library in multi-user setups. The client side library ( libgnunetchat ) now exposes each of your EGOs as account with name and own directory to store the files and configurations used by the applications. Another benefit of this is tha
Read more