include browse-ocrd submodule / executable
Opened this issue · 4 comments
This would need:
CUSTOM_DEPS += libgirepository1.0-dev(or more GTK stuff?)pip_install
Oh, wow, I'm honored!
I just tested it from a fresh ubuntu-18.04.4-desktop-amd64.iso installation and I needed these packages:
CUSTOM_DEPS += libcairo2-dev libgtk-3-dev libglib2.0-dev libgtksourceview-3.0-dev libgirepository1.0-dev pkg-config cmake
pkg-config and cmake were needed for opencv-python-headless and everything else for GTK. After that pip install browse-ocrd succeeded.
I have some hesitations about the inclusion in ocrd_all:
- I was wondering if it is a good idea to include browse-ocrd in ocrd_all, because it will drag in a lot of GTK/desktop package dependencies to ocrd_all, and that might become annoying for pure server usage (but with OCRD_MODULES it's easy to select/deselect modules, so maybe that's ok).
- I have absolutely no idea if this can work in a Windows or macOS environment, and I won't be able to maintain this. Actually it's only ever tested on Ubuntu18.04 and 20.04
- I'm not sure if the code is mature enough, I'm still trying a lot of things, restructuring the code, there are unimplemented things and quite some possibilities for crashes
- Also I'm still not sure if it should become more of a mets.xml viewer or editor. My use case as a scan/preview tool needs some editing capabilities (that is: delete via right-click in the pagebrowser), but I don't want to take the responsibility for broken mets files ;)
So, with that said, if it is ok for you, it's ok for me. And I would be happy if more people would use it.
I understand and share your concerns @hnesk, appreciate your pragmatism. But let's keep this issue open and revisit later once the tool has matured and we have discussed how ocrd-browse would fit into the ocrd_all stack.
@hnesk thanks for your thorough explanation!
* I was wondering if it is a good idea to include browse-ocrd in ocrd_all, because it will drag in a lot of GTK/desktop package dependencies to ocrd_all, and that might become annoying for pure server usage (but with OCRD_MODULES it's easy to select/deselect modules, so maybe that's ok).
That's a good point. So far we have tried to eliminate X11 dependencies whereever we can (e.g. prefering opencv-python-headless over opencv-python). But we never had any actual dedicated GUIs to begin with (except for debugging facilities).
We could include your module in such a way that unsupported platforms don't install it when using ocrd_all natively (see conceptual discussion in #147). For our Docker prebuilds, we should probably exclude it.
* I have absolutely no idea if this can work in a Windows or macOS environment, and I won't be able to maintain this. Actually it's only ever tested on Ubuntu18.04 and 20.04
Understood. Don't bother!
- I'm not sure if the code is mature enough, I'm still trying a lot of things, restructuring the code, there are unimplemented things and quite some possibilities for crashes
That's true for most modules though (except for the crashes). But since will not be part of the productive processes, and already has value, I don't think we should be too concerned about this.
* Also I'm still not sure if it should become more of a mets.xml viewer or editor. My use case as a [scan/preview tool](https://github.com/hnesk/browse-ocrd-physical-import) needs some editing capabilities (that is: delete via right-click in the pagebrowser), but I don't want to take the responsibility for broken mets files ;)
Of course. If users change their METS with anything other than a processor, they must be sure to keep backups etc. This is similar to the case with ocrd-sanitize.
So, if there are no other objections, I'll make a PR along those lines.