On Tue, 4 Feb 2020 22:28:53 +0100, Nicky D. wrote: > it has been a while since LL released their last Linux capable viewer. To > get things started > again I brought 6.3.6 up to Linux support: > https://bitbucket.org/NickyD/viewer-linux > https://bitbucket.org/NickyD/viewer-flatpak (for the flatpak build > scripts) > > As I know the chances to see a penguin fly are bigger than get a release > from LL, I also created a flatpak that users can install and run > (instructions below).
I fail to see the advantage of a flatpak, when the current distribution method (i.e. bundling libraries that are likely to lack on the user's system, or that have been patched) do work nicely... Flatpaks are huge and bloated with stuff that the viewer won't really need (but are just non-essential dependencies to some libraries it uses). The alternative to both flatpaks and dynamic libraries bundling in the viewer distribution is to statically link all libraries that are likely to be missing on the user's system. That's what software like Firefox or Blender do for their pre-compiled Linux binaries distributions. > Differences in the Linux version: > - Uses SDL2 rather than SDL (so the "OS" version can be used). That's an interesting and useful change, that I'll probably pick-up for my own viewer: SDL2 is the path to the future anyway (with Wayland support, even though the latter is likely to stay inappropriate for running the viewer in the foreseeable future, since NVIDIA proprietary drivers don't support it and Open Source NVIDIA drivers are way too slow or right out incomplete). However, I would recommend to keep linking statically SDL2 to the viewer binary, since SDL2 is far from a mandatory prerequisite in many Linux distros (i.e. it is not always installed by default). > - Uses GTK3 instead of GTK2, again to not have to compile the old GTK > version. I solved the GTK dependency a looong while ago... By removing it entirely ! The viewer depends on GTK under Linux only for the text clipboard (and it is not even properly implemented with it), and for the file selector (which lacks proper threading, or causes threading bugs/slow downs when threading is attempted). My solution has been to re-code the clipboard stuff directly with Xlib primitives (with proper primary and secondary paste buffer support) and to code an XUI file selector, that also works for Windows and macOS by the way, with a code that is beautifully simple and largely OS-independent (only a few #if LL_WINDOWS here and there to deal with Windows file system peculiarities, such as with hidden files and drive volume names), since it relies on llcommon classes to deal with OS-dependent stuff. An alternative, if you want to keep an OS-dependent file selector, would be to migrate to Qt's: easier and cleaner to implement in C++... > - OpenAL instead of FMODEX, there's no way to download FMODEX anymore. > Once FMOD Studio gets into the viewer I add it to the Linux release. I got support for FMOD Studio in my viewer for a long while too. Quite easy to implement based on FMOD Ex implementation. The only loss is support for the (rarely used) OSS backend in FMOD (but OpenAL can use it, and I got both OpenAL and FMOD Studio supported in my Linux viewer). > - No KDU. I obviously don't have access to LLs version of KDU and won't > use the one I have for Firestorm. OpenJPEG does a good job anyway (pretty much as fast as KDU too, when compiled with SSE2/3 support). Just make sure to use a SL-compatible version (I use a heavily patched v1.4.0.635 personal fork, with security fixes and SSE optimizations backported from v2). Here again, OpenJPEG is best statically linked to the viewer (I even integrated its sources to the viewer sources, since they are so specific/heavily modified). > - GStreamer 1.0 instead of VLC. GStreamer being part of the OS it gets > updated by the OS (Flatpak in this case) rather than shipping some ancient > VLC version. I totally agree with you. Beside, like I already explained back in 2016 in this list, GStreamer would also be a better choice for Windows and macOS users: it only needs to be installed once and for all (i.e. no need to bundle a huge amount of libraries with the viewer, like is the case of VLC) and solves all software patent issues (users can choose what CODECs they install on their system, depending on where they live and/or how "sensitive" they are towards the patent issues). I use Gstreamer for all OSes in my viewer: never got a single complaint from any user for doing so... > - dullahan/CEF is added. So it got the usual web browser as Windows/OSX got. > - It's obviously unsupported. I provided and kept up to date the sources for a Linux-compatible Dullahan since November 2015 on my site... That could count as "support", I think... :-D Another thing you might want to look at is getting rid of the deprecated, unsupported and utterly buggy dbus-glib dependency. I solved this a long time ago by coding DBus support based on glib-gio (see llappviewerlinux.cpp in my viewer sources): it's very clean and small code, that also does properly work (dbus-glib got a timeout bug, unless you use a very old version that no distro would provide any more nowadays, anyway). Henri. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
