github-actions[bot]
commented
2 years ago Closed r-pufky closed 1 year ago
github-actions[bot]
commented
2 years ago 
thelamer
commented
2 years ago Our gui baseimage actually uses xrdp and guacamole. The actual rendering of Chinese characters is possible but the user would not be able to type them in https://github.com/linuxserver/gclient#keyboard-layouts , this is a guacamole limitation at the time, it cannot translate the keypresses into the correct x11 codes for xrdp currently. Also VNC connections would not be possible but rdp on 3389 would be.
r-pufky
commented
2 years ago Our gui baseimage actually uses xrdp and guacamole. The actual rendering of Chinese characters is possible but the user would not be able to type them in https://github.com/linuxserver/gclient#keyboard-layouts , this is a guacamole limitation at the time, it cannot translate the keypresses into the correct x11 codes for xrdp currently.
Do you know if unicode control characters are supported from the interface (e.g. for å - windows: alt+0229 linux: ctrl+shift+0229)?
Also VNC connections would not be possible but rdp on 3389 would be.
My image was primarily designed to serve digikam through a webface, with VNC being a optional feature to use because of the base image. I think VNC vs. RDP is not a hard requirement in that regard.
thelamer
commented
2 years ago It's not an issue with control characters it's the code lacking the ability to use the characters properly. Instead of keydown concept where you send a literal key the input from the browser is translated directly into x11 keycodes. From there the guacd server sends those keycodes to xrdp, both guacd and xrdp need to know what the keyboard layout is for the characters to land on the remote desktop. Right now that list of keyboard layouts is all that is supported. You can set a keymap image level (in Linux) and if the user uses an English qwerty on the machine they are accessing from it will work, but in general I can't imagine when this would be applicable. Long answer is it is mostly Europe and NA support, RU and Asia is missing until someone takes the time to map out support. https://github.com/apache/guacamole-server/tree/master/src/protocols/rdp/keymaps
In general our gui baseimage uses RDP because of the performance, sound support, and pixel perfect rendering. It's a better overall experience especially full screen. Localization is definitely in the con column.
thelamer
commented
2 years ago @r-pufky did you want this still open? I went through the issues and things you mentioned and added everything we could. But universal localization is a no go.
As far as kitchen sink style for support stuff like firefox could be installed, but in general Arch is pretty good about depends: https://archlinux.org/packages/extra/x86_64/digikam/
Is anything missing here? https://github.com/linuxserver/docker-digikam/blob/master/package_versions.txt they have a pretty heavy depends tree.
r-pufky
commented
2 years ago Heya, thanks for the ping; I haven't had a good block of time to specifically dig into this. I'm going to turn up a LS digikam image and see what the deltas are before following up on this bug with specifics. I think for the most part the LS will work.
I'll try and find some time this weekend to dig into it a bit more.
On Wed, Mar 2, 2022 at 11:28 AM Ryan Kuba @.***> wrote:
@r-pufky https://github.com/r-pufky did you want this still open? I went through the issues and things you mentioned and added everything we could. But universal localization is a no go.
As far as kitchen sink style for support stuff like firefox could be installed, but in general Arch is pretty good about depends: https://archlinux.org/packages/extra/x86_64/digikam/
Is anything missing here? https://github.com/linuxserver/docker-digikam/blob/master/package_versions.txt they have a pretty heavy depends tree.
— Reply to this email directly, view it on GitHub https://github.com/linuxserver/docker-digikam/issues/17#issuecomment-1057298624, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEOQPQNXVYV6XFSBE3KAMTU566NXANCNFSM5NVEHWCQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
r-pufky
commented
2 years ago I've tested both containers; here are the open issues outside of the localization comment discussed above:
A browser installation is required to proxy login and cache credentials. There is not a default browser configured in the ls/digi container currently.
Import: Import -> Import from Smugmug Export: Export -> Export to Smugmug
A browser window is launched to auth to the import/export in question, then returning to digikam to finish the process.
Digikam hangs indefinitely at the 'Logging in to SmugMug service ...'. See screenshot:
This was resolved in my container by including a long term support firefox browser to proxy login. See: https://github.com/r-pufky/digikam/issues/12
Exiftool is used to modify additional exif data for images.
exiftool is run providing for additional exif data manipulation.
Digikam fails with execve: No such file or directory.
Installing exiftool and ensuring it is in the user's path should resolve this issue. See: https://github.com/r-pufky/digikam/issues/11
If the digikam window is closed, it is not auto-relaunched; resulting in a black screen until the container is restarted.
Digikam automatically restarts.
Black screen. No action can be taken.
If the process exits, it is restarted.
thelamer
commented
2 years ago You can right click the desktop to launch a terminal or digikam. You are inside a full DE (openbox) in our baseimage not a sandbox.
Fire up a terminal and try sudo pacman -Sy perl-image-exiftool firefox and see if that resolves it.
As far as auto relaunching that is something we don't do, doesn't really apply here, but people can run multiple windows or close an app if not in use. But we always provide a way to launch the embedded app from the openbox menu. Menu here : https://github.com/linuxserver/docker-digikam/blob/master/root/defaults/menu.xml
Firefox entry example here: https://github.com/linuxserver/docker-webtop/blob/arch-openbox/root/defaults/menu.xml#L6
Mobile right now, but if installing those two packages works I can PR that in when I get back to a computer, or you can if you want to.
github-actions[bot]
commented
2 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
r-pufky
commented
2 years ago Confirmed that latest image changes built from repo address remaining open issues that can be resolved -- thanks for the changes.
I'm going to push one last update on my image and writing migration instructions to the LS image.
Thanks for the help!
github-actions[bot]
commented
2 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Desired Behavior
I've stopped using docker for containers for about two years now, but still support my digikam (100k+ ~400k internally ) and steam (10k+ ~90k) images.
I'd like to discuss migrating existing digikam user install base to the linuxserver.io/digikam image, with feature parity & minimal migration impacts.
Current Behavior
See repository here: https://github.com/r-pufky/digikam currently, I think there are a few things to touch on:
Alternatives Considered
Let me know what you think. This is just a discussion starter to see what your thoughts are and potential ways forward while minimizing any user interruption.