Updated go + go-qml environment?

Applications
#1

Due to the switch to an aarch64 Xperial 10iii I have lost one of my most prized applicatoins, TrollBridge.

Trying to update this to 4.4 and aarch64 was quite the goose chase, which finally ended in failure for me.

From go’s stout refusal to build stuff with dependencies and NOT cloning stuff from github, making it hard to build on OBS, via the issue that old Go versions avilable for SFOS (such as the venerable jolla_go project) do not support arm64, to the fact that go-qml is not only deprecated, but never added support for arm64, and the fact that it lacks native support for Sailfish/Silica, to the final failure of me merging four different branches of go-qml to get that support.

If anyone who actually knows what they’re doing could look into this it would be highly appreciated.

Some pointers:

I know there’s a couple of Go-based apps out there for Sailfish, I believe they would also benefit from an up-to-date and working variant of go-qml.

2 Likes
#2

Don’t know much about go, etc., but I got curious when I saw your post… I was able to get go working by installing it on my Devuan lxc container, and symlimking to /usr.

Screenshot_20220606_002
Screenshot_20220606_0021080×2160 293 KB

Then, I tried to build troll bridge from @bundyo 's github, and hit errors about ‘include’ files missing. I installed gopkg.in/qml with ‘go get’ command, which fixed that error, but then ended up with ‘function body missing’

Screenshot_20220606_001
Screenshot_20220606_0011080×2160 562 KB

…which error also showed up when I installed gopkg.in/qml, before I tried to use it. So, I guess there’s some missing core package, or something?

1 Like
#3

Thanks for trying! That matches up with parts if my goose chase experience.

For go-qml that error is there because there is no asm for arm64 I think and generally because this official package is dead/unmaintained.

The other repo has that arm64 support as well as fixes for 1.12 go, but go get apparently does not check out all required files.

But all are missing the SailfishOs bits, which are afaik only in that patch I linked. And that one contains other fixes as well which makes it not apply on modern versions.

2 Likes
#4

Hey guys!

Not really sure that old Go QML code will compile, especially for 64bit. I also need to somehow get it running, as the new OM-1 is not working with it.

Meanwhile I’ve started reimplementing Troll Bridge in Rust with the qmetaobject crate (the way Whisperfish is made). Since for the first release I plan to reuse the existing QML files, it hopefully won’t take as much time. I even saw what the problem with OM-1 connection is - Olympus cameras return “OPC” for connectmode (which probably means Olympus Private Connection), while OMDS changed that to just “private”.

I’ll keep you informed on the progress. Currently the QML bridge is partially done and queries to the camera can be made, but not yet parsed.

2 Likes
#5

That is great to hear thank you.

Let me know if I can test anything, I have a OM-D e-M5mkII.

(I also have an OM-1, but the 1970s version so that’ll be of little help… :slight_smile: )

1 Like
#6

Not yet, but probably soon. Now implementing the image list (which should be the hardest part and may take several days).

1 Like
#7

This is somewhat tangential, but I wanted to point out that @karry is working on libraries, among other things, for camera control. I’m working on a, still primitive, stop motion animation app, and the intention is to eventually integrate camera control (primarily for time lapse photos and stop motion animation workflows) using those libraries.

@karry 's library work, https://github.com/Karry/TimeLapse , includes a (V4L, GPhoto2 or Qt Camera API). I’m wondering if Olympus support is ‘given’ or extra work?

My prelim. stuff (based on an old timelapse app from years ago) https://github.com/poetaster/harbour-stopmotion

2 Likes
#8

gphoto supported devices: gPhoto - Projects :: libgphoto2 :: supported cameras

1 Like
#9

Olympus cameras can be controlled, but I didn’t go in that direction, as the protocol is not open (excluding that of Olympus Air, which is). However, it is based on simple HTTP requests, so it might be reverse engineered by sniffing the traffic between the camera and the Android app. When I complete the rewrite, I might take a look at it.

2 Likes