Paperwork for MacOS

[fabwu]

I recently switched to MacOS (blame me) and I really miss Paperwork on that platform. A quick Google search told me that I’m not the only one.

I’ve tried to build the source code but it fails with some GTK-Error. Then I saw that you can build GTK-Applications for MacOS (see here) but couldn’t get that to work either.

In the meantime, I created a simple SwiftUI Application which uses the Paperwork directory structure and imports PDF/JPEGs with the Apple Text Recognition. It’s all very basic but it shows my old documents and I can import new documents, preserving the folder structure. Here’s a screenshot of the app:

What do you think about offer a MacOS version of Paperwork, either by using the existing python code or as a Swift application?

[jflesch]

Hello,

Sorry, but I have no plan to port Paperwork to MacOS. Porting to MacOS requires Apple computers. I have no intention of wasting my money (and my time) on proprietary hardware and software.

However if someone else want to port it, please go ahead ! . I’ll do my best to help you (keeping in mind I know very little about MacOS).

If someone is willing, there is a bit of good news. Paperwork 2 has been designed to be portable (the intended target is Android):

• It is modular. It is made of a very small core and a lot of plugins. Plugins can be disabled if required.
• The logic has been separated from the user interfaces has much as possible. The logic is in paperwork-backend/ whereas the user interfaces are in paperwork-gtk/ and paperwork-shell/ (paperwork-shell = paperwork-json + paperwork-cli).

Now the bad news:

• I haven’t ported Libinsane to MacOS. And while Libinsane is modular too, it looks like a huge work. As a first step, I think the simplest thing to do would be to disable scanning on MacOS (see below).
• I’m not going to publish officially a Paperwork version for MacOS unless I have a gitlab-runner running on a MacOS computer to run the tests and make the builds. MacOS VM are remarkably painful to create and maintain (Apple does obviously everything they can to prevent you from making a VM) and as mentioned before, I’m not going to spend money for a MacOS port. So it’s up to the person doing the port to provide the test/build runner.

To disable scanning in Paperwork:

# Linux/Windows
paperwork-gtk plugins remove paperwork_backend.docscan.libinsane
paperwork-json plugins remove paperwork_backend.docscan.libinsane

# Linux only:
paperwork-cli plugins remove paperwork_backend.docscan.libinsane

If you can’t run Paperwork (because you’re porting it to MacOS for instance), the simplest thing to do is to remove paperwork_backend.docscan.libinsane from the plugin list in paperwork-backend/src/paperwork_backend/__init__.py.

Best regards,

[fabwu]

Hi jflesch,

Thanks for your quick reply. I think I start with getting the paperwork-cli to work on Mac and then continue with GTK. I hope it will work with scanning disabled.

I’ve never setup a github-runner for MacOS but I’m sure there is a way.

I’ll keep you posted in this thread about my progress.

[fabwu]

Ok I’ve got a running version of Paperwork on my Mac using Homebrew

Here’s what I did:

1. brew install gobject-introspection gtk+3 libnotify poppler libhandy tesseract tesseract-lang
2. Clone git repo and create a virtual environment
3. Run pip install . in every module
4. pip install python-poppler setuptools to add missing python dependencies
5. Disable scanning paperwork-gtk plugins remove paperwork_backend.docscan.libinsane
6. Apply this patch:

diff --git a/openpaperwork-gtk/src/openpaperwork_gtk/fs/gio.py b/openpaperwork-gtk/src/openpaperwork_gtk/fs/gio.py
--- a/openpaperwork-gtk/src/openpaperwork_gtk/fs/gio.py	(revision 3f51346f3f04dd16f4e7adde78e4e4adc19fab68)
+++ b/openpaperwork-gtk/src/openpaperwork_gtk/fs/gio.py	(date 1711078177905)
@@ -3,6 +3,7 @@
 import logging
 import os
 import tempfile
+import platform
 
 try:
     from gi.repository import Gio
@@ -581,7 +582,7 @@
         return True
 
     def fs_get_mime(self, uri):
-        if os.name == 'nt':
+        if platform.system() in ['Windows', 'Darwin']:
             # WORKAROUND(Jflesch):
             # Gio.File.query_info().get_content_type() returns crap on Windows
             # (for instance '.pdf' instead of 'application/pdf').

7. Start paperwork with paperwork-gtk

If I look at all the workarounds necessary for Windows, I guess there are plenty of hidden bugs that we need to sort out.

Anyway, you should probably decide how you want to distribute Paperwork on MacOS. I see two possibilities:

1. Using a homebrew formula
2. Use gtk-osx as recommended by PyGObject (Application Deployment - PyGObject)

I really don’t have any experience with packaging but I tend to the homebrew approach because it’s easier.

Regarding the CI you requested I’ve found https://circleci.com/ which is also used by Gnome but I haven’t looked into that.

@jflesch Let me know if I should focus on packaging or create a CI runner for the tests.

[jflesch]

Nice. Don’t hesitate to submit merge requests for the portability patches like the one you mentioned.

Anyway, you should probably decide how you want to distribute Paperwork on MacOS. I see two possibilities:

I don’t own a Mac, so I can’t choose. You’re the one doing the portage to MacOS, so you’re the one deciding. I can only advise you.

My advise: Paperwork is intended to be as simple to use as possible (goal not entirely reached yet). So, to start, you can use whichever method you like. But eventually, I suggest that you switch to the method the most usual for MacOS users (.dmg files I guess ?).

If we have continuous deployment setup and running (see below), after each build, we can upload resulting binaries directly on download.openpaper.work. That’s how it’s done for Windows and AppImage builds: builds triggered by changes on the branches master/testing/develop go directly to download.openpaper.work.

Whatever you decide, please keep me posted regarding installation instructions. Once you deem your work fit for release (and once we have CI/CD), I will add them to the website.

Regarding the CI you requested I’ve found https://circleci.com/ which is also used by Gnome but I haven’t looked into that.

Sorry, I should have specified: I’ll only accept opensource solutions. No proprietary solutions, ever (except regarding the target OS I guess … ).

There is maybe one other option. A MacOS VM
We can do the same thing than for Windows:
openpaper.work is actually running in a VM on top of a Proxmox host running in my basement. Beside it, there is also a Windows VM running on this same host, used to make the Windows builds. In the past, I’ve already built a MacOS VM on this Proxmox host. Unfortunately they tend to be one or two major versions of MacOS behind, are slow as hell, and must be reinstalled from scratch at each major update. That’s why I was reluctant (and still is ) . Still, for CI/CD, unless we have a better option, if it good enough for you, I can rebuild a MacOS VM and we can work with that.

By the way, in order to comply with the license GPLv3, Paperwork’s build process must be documented for each platform (ex: linux, windows). So if you write complete build instructions for MacOS, I should be able to set the CI/CD up by myself on the VM.

[fabwu]

Ok in that case I’ll continue to try and create a .dmg file. I’m not quite there yet but as soon as it works I’ll post detailed build instructions and we can setup a VM on your Proxmox.