Working Proof of Concept: "AppImage with everything", prepared on Arch, can download from D9 on CentOS

[Dirk Hohndel]

> On Aug 2, 2017, at 3:33 AM, Lutz Vieweg <lvml at 5t9.de> wrote:
> 
> On 08/01/2017 06:18 AM, Dirk Hohndel wrote:
>>> https://transfer.sh/2tLny/subsurface-4.6.4-2-x86_64.AppImage
>> 
>> Really cool.
>> Is that a stock 4.6.4? What's the version number scheme you use?
> 
> I packaged just the Arch-Linux provided subsurface binaries, as in:
> https://www.archlinux.org/packages/community/x86_64/subsurface/
> https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/subsurface
> - that's also where the numbering "4.6.4-2" comes from.
> 
> Of course, the same could be done quickly for any other version,
> provided it runs fine on some source system.

That makes sense. We don't have a daily/test build for Arch. And that
shouldn't be all that hard to do, anyway. Given all the changes lately
that might be a great idea.

>> I wonder about USB devices like the Cobalt... will they need extra support
>> as well?
> 
> "makeaoi" reports if the "strace" it does while running
> "makeaoi trace somedir subsurface" contains ioctl()s not
> yet supported.
> 
> Looking at
> https://github.com/libusb/libusb/blob/73d15d1f8eee372e0609d072f3df705f7de18214/libusb/os/linux_usbfs.h#L145
> I would assume that usage of libusb does imply using additional
> ioctl()s, but as long as it is documented what parameters/structures
> they take, it is not difficult to add them to the range of ioctls()
> supported by unions-fuse.

OK

>> And then of course that whole BLE mess :-/
> 
> I may later be able to lend a BLE-talking "Perdix" for trying this.
> (Of course we would know sooner if somebody owning such a device
> would try. :-) )

I have a Perdix and a Linux system that I could try it on. You seemed to
say that BT wasn't supported at all, that's why I didn't even look, yet.

>>> - Qt5 seems to try using all kinds of modern X visuals and direct
>>>  rendering mechanisms, before it falls back to using plain old X11,
>>>  which is more than enough performance-wise for subsurface.
>>>  Thus I did exclude all the fancy GPU-dependent DRI modules from
>>>  the AppImage, they are not really needed and would probably bring
>>>  a lot of compatibility issues (some even use completely undocumented
>>>  ioctl).
>> 
>> Interesting. Does that have any impact on the visual experience of what
>> is actually rendered on screen?
> 
> I did not notice any visual difference. There might be "tearing" when
> quickly moving the globe in a large-sized "marble" display, but that
> seems of minor cosmetic relevance.

And Marble is going away, anyway. We still have panning and zooming in
the QtLocation based maps, though.

>>> Of course, manually prepared AppImages, built on "older operating systems"
>>> might still be the better / smaller / more compatible(?) solution, I just
>>> thought that since it seems to be a tedious and problematic task at the
>>> moment for the Subsurface maintainers to create more recent AppImages,
>>> I should give the "AppImage with everything" idea a try, since it is really
>>> not much work to create or update such images once a working executable
>>> is available on one machine.
>> 
>> I have managed to fix a couple of the bugs with the current AppImage
>> creation and have a current 4.6.4.675 image up that I hope people will
>> test...
> 
> Ah, I see, in https://subsurface-divelog.org/downloads/test/
> 
> I will try to compare both AppImage versions (but can still only try the D9).

The AppImage needs more work for sure. The one I posted crashes :-(
That's on my todo list, but I may run out of time before heading on non
diving, non hacking family vacation.

/D