Tried Scriv 1.7.1 for Windows on Wine 1.6.2-7 (SolydX debian distro, 32-bit):
Good news: scratch pad works as advertised.
Bad news: attempt to take a snapshot of a binder page causes instant freeze; cannot recover.
Did not attempt further testing; uninstalled from Wine. Will wait for linux .deb package of Scriv 1.7.1
Did you try deleting the camera_click.wav file with the snapshot sound? That has been known to fix snapshot crashes in the past.
Yes! I’m pleased to report success with your suggestion. Deleting that .wav file solved the Snapshot problem.
At the risk of offending Linux guru-niks with this “obvious” info, here is the path required to reach that offending file: /home/[username]/.wine/drive_c/Program Files/Scrivener/resources/
I’ll proceed to run my Wine version through the wringer; I’m not too concerned with the full “feature set” so much as I want all the basic functions to run reliably. Again, this is on a 32-bit “rolling release” distro of Debian linux, so someone else’s mileage may vary, esp. the 64-bit versions.
I prefer the Linux variant of Scrivener, as I’ve never much cared for the poor screen font display of apps running under Wine. But, that said, there are a few Win apps not available via Linux repositories that are priceless (to me) and I accept the Wine appearance. (One such app is the shareware word processor, “Atlantis” … which can open a multi-megabyte .doc file blazingly fast, and save it as a very acceptable .ePub rendition with one click … again, blazingly fast. Don’t try that with Open/LibreOffice. You’ll die of old age, first. Even running under Wine, Atlantis is rock-solid stable and irreplaceable.)
Another thing you’ll want to do is upgrade WINE. 1.6.2 is out of date, since there are significant improvements to core functions in the 1.7 tree that Scrivener relies upon. (Namely the API for the C++ runtimes and directx handling.) WINE is one program where the stable tree is not the one you want to be using.
Font display can be improved.
Install winetricks (it may already be installed.)
Then: wintricks fontsmooth=rgb
This cleared it up for me.
Google around on this issue. There are solutions.
Thanks for the Wine 1.7 tree update advice. I tore my hair out trying to find/install and get to work the 1.7.xx Wine .deb packages. Not an easy thing (I did get 1.7.18 installed via dpkg after finding “unstable” repos in Debian site, but no apps would open. Something was incomplete/broken/unlinked.)
Problem solved, and my advice to others: install “Play On Linux” and let it do all the heavy lifting. Using the POL window menu choices, I downloaded Wine 1.7.19 (latest version). POL installed all the dependencies, put it into a virtual drive, and then acted as a front end to (manually) browse and install Scrivener 1.7.1. It even put a lovely Scrivener-logo shortcut on my XFCE desktop!
(Remember to open the POL virtual drive folder, navigate to the Scriv rresources, and kill that snapshot .wav file!)
Color me tickled. Thanks.
shrugs I compile my own. It’s not difficult.
uhuh … yup 
Here’s a direct quote from the “About Debian Linux” page: “…compiling programs can be a frustrating experience. You can run into all kinds of errors due to outdated library files, certain assumptions made by the programmer (which don’t hold true on your system), and numerous other causes. Save yourself some grief and use packages whenever possible or at least use pre-compiled binaries if they’re available for your particular system.”
My experience over the last five years or so is that it’s exceptionally easy to corrupt/mess up a Linux installation, and find oneself lost in a swamp with only alligators for guides.
My biggest complaint about the Linux universe is that most of the documentation is seriously out of date, fragmented, incomplete, ‘under construction’ or written in arcane geek-speak that assumes one already knows the answer and needs only the Cliff’s Notes condensed reminder.
Other than that, I love it … but I try to stick to the “safe” repository binaries and synaptic or apt-get .deb packages. Which is one reason I really like SolydXK distro … altho a rolling release, the crew tests all the updates before inflicting them on the community. Breakage is quite rare.
I agree. And one other challenge is that when you search the Internet for solutions to your problem, it’s not a simple answer. There are zillions of different answers and most are (as you said) outdated, or outright wrong. This has been my experience anyway. I carefully follow the instructions that are supposed to fix my problem, and sometimes they work. Sometimes they don’t. And sometimes they hose your computer so bad you have to reinstall everything from scratch again. By the time I have everything reinstalled and configured again, I’ve blown a couple of days or nights, just to get back to where I was in the beginning - the original problem still needs solved. What a kick in the groin. It is especially frustrating when you have a favorite program (like Scrivener) that you can’t get to work right. I still am going to stick with Linux because the benefits outweigh the negatives. I’m really really sad that I couldn’t get Scrivener to work though…and I’m not going to hose the system again trying. I’m waiting until there is a “real” Scrivener release that is supported. I’ll pony up and pay for that in a heartbeat.
Because of what I do on a computer, half my OS is custom compiled, the other half is stock Slackware. The only time I’ve had issues is when I was stuck on a distro that assumed use of a package manager and is stupid about it. (Like Debian and Arch Linux.)
If you have the dependencies to run WINE, you’ve likely got the dependencies to compile it. Uninstall the old version, untar the source, go into the tools directory in the WINE source, type “./wineinstall”. (without quotes.)
Otherwise the old standby of “./configure && make && sudo make install” still works for WINE.
Garpu … because I trust your expertise (far greater than mine in this area) I’ll do just what you recommend … following the steps you list. I’ll report the results back here.
Two things are for certain: first, any effort is justified to escape the persistently perverse World of Windows; and, second, Linux is a never-ending learning experience … which is not a bad thing.
You’re better off using the script in wine-some-version/tools. If it fails, nothing will happen. If you choose to go the manual route, then it’ll tell you what step to do next. (I don’t think you need to do “make dep” before running “make,” but the stuff spewed to console will say. You always used to have to build dependencies, but I believe that changed.)
Also, if it does fail, there might need to be some other step taken to get the correct architecture. For me, I set a shell variable first (since WINE is a 32-bit program.) Other distros require other steps, and each one is a little different in that regard. If my pre-caffeinated memory serves, then WINE should compile out of the box as 32-bit. (Which is fine…I’ve had better performance with it as 32-bit. 64-bit WINE isn’t widely recommended yet.)
To verify version: wine --version
Good luck! Just remember, if something blows up and it gets installed anyway, doing “sudo make uninstall” (without quotes) in the source directory will uninstall it. (To keep things neat, I always unpack source tarballs into ~/src, but that’s a convention I’ve been using ahwile. I always keep a prior version of WINE around as source in that directory, just in case. If it’s already built, all I have to do is uninstall the new one, reinstall the old one, if the new version is buggy.)
Anything you compile should go into /usr/local, so it shouldn’t mess with system stuff. I woudln’t advise changing the install path.
As promised, a report: 
(I’m being a bit ‘verbose’ with this, in case some other ‘newbie’ needs the info.)
I followed the suggestion & made a ~/src folder; put the unpacked Wine source file there. That’s a handy place to keep that kind of stuff.
Apt-get removed the old wine installation; this also removed the playonlinux app. CD’d to the new wine-install source ‘tools’ folder and issued the ./wineinstall command.
Got called for a freetype-dev dependency; went to synaptic & looked it up; freetype was installed but not the development lib. Installed that; went back to ./wineinstall command.
Holy eyeblur, Batman! Talk about scrolling lines o’stuff. I chuckled when the installer script suggested it might be a good time to go take a lunch break; over an hour later, it finished compiling and after a ‘root’ password call for install, all was done.
Did a ‘wine --version’ command; got “wine-1.7.19” result.
Went to the Wine menu on my desktop (it remained from the previous install and Scriv item was still there); clicked on Scriv 1.7.1 … fired up & ran. Perfect.
Navigated to the ~/.playonlinux folder, deleted it and those megabytes of files.
Color me tickled. 
Thanks, Garpu!
Woohoo!
Yeah, a lot of distro docs make compiling your own source to be way scarier than it really is. If you’re doing something with a system thing, it’s probably best to use an official package. (And less trouble, unless you absolutely NEED something custom.) Compiling something like WINE or some other program goes into /usr/local/bin so it doesn’t crap on other things, in case you screw something up. (In the case of WINE, it does need to be current.)
WINE does take awhile. They advise you to go watch a movie or grab a snack before gcc starts to build. My favorite Easter egg in compiling stuff was for the Enlightenment window manager: it would check for Bass ale in your fridge during the configure step.
If you game, Playonlinux is kind of nifty, since not all games work with the most current version of WINE. (Like Hearthstone is currently broken.) For instance, I’ve got about 8 different WINE prefixes for various things. PoL takes care of that management for you.
Earlier I had made this comment:
Color me “corrected!” Since compiling and installing the latest version of Wine from the WineHQ website, and running Scriv for Windows ver. 1.7.1 … I’m delighted to say that the apps running under Wine look every bit as good as the Linux apps. I’m finding that it’s virtually indistinquishable to differentiate between my core selection of Win/Wine apps, and the regular lineup of Linux apps, as far as speed, appearance, and stability go. Talk about having the best of both worlds!
That said (in my opinion 
), the Debian folks are really not doing themselves or the user base any favors by lagging so far behind with Wine .deb package updates in the repository.
One trick you can do is investigate the fontsmoothing settings either in the WINE registry or via winetricks. That makes a big difference, too.
And as long as you’re doing font things, “allfonts” and “corefonts” via winetricks helps a bunch, too. (YMMV…every distro does font handling differently, but at least corefonts is one way to make WINE programs look spiffy.)