It would be much easier to test the new beta if it would fail gracefully when missing gstreamer (particularly libgstapp). I can’t imagine that gstreamer is really required for the most fundamental elements of Scrivener. I expect it must just provide support for some types of media files in the “Research” collection.I would think it should be possible to just disable these features if libgstapp isn’t available.
The problem is that it’s a dependency nightmare. I’m on a 64 bit linux without official package support for 32 bit gstreamer, and I’ve been compiling lib32 packages for hours (and filling up my SSD - I have 260MB of these already, and the end is not yet in sight). It’s staggering how many libraries need to be rebuilt! I do really want to test this beta. I love Scrivener on Mac. I would much rather have no gstreamer capabilities than have to do a day worth of cross-compiling, though.
For me, a 64 bit version of the beta would solve the problem as well (since I have gstreamer installed, just the 64 bit version), but it would still be better to fail gracefully. I can easily imagine wanting to work on my writing on a small netbook where I have no use for gstreamer, and where I don’t feel like spending half a GB of extra drive space to install its requirements.
Another possibility would be to include the required library, which might be possible to build quite small, if Scrivener only uses a small subset of the capabilities (for example, I have to install 32 bit libraries for access to usb block devices to build libgstapp. It seems very unlikely that Scrivener cares at all about usb devices).
Hi. I’m kind of upping this topic in order to agree with grahamcummins.
Compiling lib32-gstreamer-base is really a nightmare on Archlinux. There are an awful lot of deps depending on other lib32 deps, which also depend on other lib32 stuff. And so on.
I’m not exaggerating: I gave up when I reached the fourth “recursive call” on my package manager.
Frankly, I’m not a Scrivener user, I just wanted to give it a try (someone told me it was great). But I gave up, I’ll stick to LaTeX for now. Maybe some other time, when the dependencies won’t be as complicated as now (or when a real 64 bits version will be released*). No hard feelings, though: I really, really look forward to trying this application… but when it’ll work from scratch.
*Really, you should seriously consider providing an x86_64 version. More and more Linux distros encourage their users to switch to a 64 bits OS.
Edit. — Had to add a smiley in order to make this post a bit more cheerful (which is its original intent).
I wasn’t a Scrivener user either the first time I tried it. As a Arch 64bit user I feel your pain. I also came from and still use Latex. But only as part of a toolchain that starts with Scrivener and only for the versions not destined for users of Word.
I was able to work with Scrivener long enough to experience the undeniable benefits of using it. Focus on the product and not the process. Our household now shares a license for the Windows version which I am using in an XP VM until the new beta is released. I will continue with this workflow for projects where importation of files or extensive PDF research is required and continue to “beta” the Linux version until it is ready for prime time at which point I will purchase a Linux license…
Work with what is here so far. There is nothing even close in the FLOSS world yet. The software presents a way of working with a project that is unique and needs to be experienced.
That would be an option if I had a Windows (which is not the cas: no VM, no Windows partition, as a matter of fact, I don’t even own a Windows licence).
Moreover, I’m a student, which means that even if I had a Windows (that’s always manageable), I’m not willing to throw 35 bucks on a software licence that will be used in a WM and then have to buy it again when the non-beta Linux version comes out if the software suits me.
But I might give a shot at the Windows evaluation version under WINE if it works fine, and then wait for a compatible Linux release. I’m aware that Scrivener is quite unique and powerful and really would love to try it.
A Linux VM under Linux? Why not.
I’ll condiser using that with the 1.2.1 beta if a 64 bits version isn’t released. For now, the Windows version with WINE is less memory-consuming, though (I’m quite limited by the amount of RAM here, in order to speed up my computer, I had to switch to a very lightweight WM).
I’m very pleased that there is a new Linux beta. It’s great to see continued support for Linux. I would like to reiterate that I will certainly buy another license (I own a Mac license) as soon as one is for sale for (64 bit) Linux.
I hear that there are more troubles with 64 bit in this beta, however. This is too bad, since nearly all modern machines are 64 bit, and I think that many Linux users prefer to run them with a 64 bit OS. I’d like to see some feedback from other users on this forum, but of the Linux users I know personally, not a single one runs 32 bit on their primary machine anymore.
As with the previous release, however, I can’t quickly get far enough along to even find out if I experience the reported “RTF” 64 bit issue, since this beta still has the exterior dependency on a 32 bit gstreamer. Thus, here I am (on a new laptop, running Arch 64 bit) compiling 32 bit versions of about a hundred packages from AUR. I also have a Gentoo box now, and perhaps I will try to compile for it, in hopes that the dependency tree can be reduced somewhat by Gentoo’s highly flexible “USE” optimization. I don’t know how much time I can devote to that, though.
It seems that the fastest solution, for this issue, and also the RTF issue, would be to build a 64 bit version of the Beta. Is this difficult to do? Way back in the 1.1.0 Beta release, a 64 bit version was announced “in a few days”, but AFAIK it never appeared.
EDIT:
Well, the good news: After all the compiling is done, The new Beta seems to work well for me (on 64 Bit Arch Linux with extensive lib32 libraries added). I haven’t tested it extensively, but I’ve opened and edited some quite complex projects from Mac. I haven’t seen any sign of an RTF editor problem. Yay!
I with you on this one…but alas, the person who first reported the “RTF Reader” error was running on a 32-bit system…so maybe there’s something else going on in this particular case. But your point is still valid.
I stand corrected. I got to that thread by following a comment “DOA on my 64 bit system” in the “1.2 beta released” thread.
Anyway, as per my edit above, I don’t see any such issue on my 64 bit system. It’s working well. Just had to build a bunch of stuff (and strange stuff too. Sane. Avahi. Udev/systemd. I can’t imagine how automatic network printer and scanner identification are required by Scrivener, or even by gstreamer. I suspect that the AUR dependency graph is more extensive than necessary). None-the-less, if you have a 64 bit Arch Linux, there is light at the end of the tunnel
I am seeing one rather minor issue with handling of non-inline annotations in my Mac projects. These aren’t supported in Linux or Windows AFAICT, but in Linux, mousing over the anchor of such an annotation brings up a fly-over box which, I expect, should show the text of the annotation, but which, in fact, is solid black. I’ll post this glitch to it’s own thread. Other than that, it looks good.
For those attempting this on 64 bit Arch Linux (as at least two above users are) then using a tool like aurget to manage dependencies makes life much easier. It still takes a while - but is much less of a headache!
