-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Digikam, closes #8 #9
base: master
Are you sure you want to change the base?
Conversation
Hold off on this one. I'm experiencing some runtime errors (crashes on previewing some photos, freezing while viewing thumbnails). Will diagnose. |
Still experiencing runtime errors; fresh install/first run runs fine. Second run locks up. |
|
||
def patches | ||
# Preserve CMake files (needed by Digikam) | ||
{:p0 => 'https://gist.github.com/tlvince/7960812/raw/f96e2f2d1a681c6329da9fc9ac3dbf6c18577b0a/marble-homebrew-cmakelists.diff'} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
preserving CMake files seems like a useful addition to homebrew itself.
could this patch be turn into a generic helper?
@tlvince what do you think about inlining patches into formula? I personally prefer to keep patches checked in to the repository. Either inlining or storing patches under, say, /patches seems better for me. Ideally, KDE apps should not need patches at all, but that's a long-term goal. |
Another question is opencv dependency. It's in homebrew-science. I'm not sure I like the dependency on another tap. What do you think about having opencv clone here? |
Just compiled it. Digikam doesn't crash for me, but I can't see any images in the library. |
I think this is a matter of style. I can see the benefit of inlining the patches as to keep them together in one place. I chose to put these in a separate gist for the maintainability and possible reusability.
I'm not sure on Homebrew's stance on this, but I'm wary of duplicating formulae as it increases the maintenance burden. Also, the homebrew-science contributors are probably more experienced/better maintaining them. Do you think a readme note (asking the user to tap homebrew-science if they want to use Digikam) would suffice?
Are you running it on a fresh database (i.e. letting it scan your photos directory)? |
Yes, fresh database (2 photos). Digikam tells me it has 2 photos, but shows nothing. |
Hi tlvince, adymo. Are you still interested in getting digikam working on homebrew? I just tried to get digikam to build based on your repo. I've used the latest stable versions of marble (4.13.2) and digikam (4.1.0). Apart from the url/sha1, I've used tlvince's file unchanged - the patches seem to apply successfully.
Now digikam builds, and runs. But with the same result: it shows no thumbnails. |
@strank, still interested, but don't have the time at the moment. Your contribution would be appreciated. WRT the thumbnail issue, it might be worth reporting upstream. NB, I currently run Macports just for Digikam, which works besides some stability issues and is outdated (still on the v3 branch). |
Good news: I just had to rebuild the system config cache with After a bit of testing, all the basic things seem to work, including the map display, geo information, the light table and image editor, and all metadata. The only way to make it crash that I found is to select the "table view" - no idea what could cause that. |
Created a new pull request so you can try it more easily. |
I am successfully able to build and run Digikam with this.
Notes:
-DDIGIKAMSC_USE_PRIVATE_KDEGRAPHICS=on
). There are a few other formulae to write if we want/need to support shared libs.'Unknown CMake command "FLEX_TARGET".'
). I tried using brew's newer version of flex (depends_on 'flex'
) to no avail. I suspect we may also have to write a formula for hugin. Disabling the plugin (via a patch) works for now.