Hacker News new | past | comments | ask | show | jobs | submit login
Foliate – A simple and modern GTK eBook viewer (github.com)
299 points by lulouie 13 days ago | hide | past | web | favorite | 112 comments





I'm using Linux and trying to find a e-reader recently. Here is what I tested on Arch:

Calibre: Failed to open

Okular: Ugly, cannot modify margin

bookworm: No two-page view, only scrolling-mode, and scrolling-mode cannot get the reading progress

zathura: too simplify resulting in not know how to use

lector: cannot recognize epub......

Buka: cannot open the book. (I don't get the logic flow, create a list first, then import the book, then crash)

Until I found Foliate, it support two-page view w/ progress bar, it support epub will in different language (I test en_US and zh_TW), fast lookup (gtrans, Wiktionary, Wikipedia), good UI, ...etc


> Calibre: Failed to open

Perhaps this says more about Arch than it does Calibre.


yep, is because Arch (basically because qt5 upgrade...), and with the issue on it: https://bugs.archlinux.org/task/63051

$ calibre

Fatal Python error: PyQt5.QtCore: Unable to embed qt.conf

[1] 13321 abort (core dumped) calibre

At that moment, I didn't have time to workaround on it :(


Ah, too bad. It's the crappiest of the bunch UX-wise, but nothing comes close to it feature-wise.

I don't use it to read (I have an e-reader for that purpose), but I'd be lost without Calibre for ebook management.


I really wish there was a practical alternative to Calibre for general ebook organization purposes. It's extra-painful that Books.app on Mac could almost fit that role, except that it doesn't let you edit enough metadata for your own imported files to properly manage series/publisher stuff.

I recently used Calibre to convert a pdf to epub. I agree the UX is lacking, but it works.

Ah, the joys and pain of a rolling release :)

Sorry for the snarkiness in my previous comment, if you get the chance perhaps you can look into helping with this issue. Contributing to the distributions I use has taught me a lot about the tools I use every day.


This has been fixed last week. Try update your system.

dont you dare!

Regarding Zathura the most readily available resource can be found by running man zathura and man zathurarc. The same info is of course on the web.

It does 2 page view, optionally shows progress, and with the mupdf backend supports epub and pdf and a few more.

Now it doesn't support mobi but calibre can automatically create an epub from the mobi on import.

Calibre is still useful in 17 different ways even if you don't actually use it to read the book.


I switched to Zathura and don't look back. I now read my PDF in my own color scheme[1] and totally love the keybindings.

[1] config: https://pastebin.com/raw/NwYB0JNf


Thanks.

This is how it looks: https://i.imgur.com/7LVLJZQ.png


Running Arch as well and I use the Calibre Flatpak to manage my Kindle. I plug it in every month or so and haven't had any failures in the last year. I've found that Flatpaks solve the problem of some older programs not working well on Arch or some programs not getting updated on Debian.

I've never personally used it for epub, but apparently mupdf works with epub files. It's my go-to PDF viewer at least. Just be sure to read the man pages as most operations are keyboard hotkeys.

Mupdf is a better backend for zathura than it is a reader in its own right. It's UI is lacking most notably lacking the ability to access the index.

Make sure you use mupdf-gl rather than mupdf-x11; then press 'o' for toggling the outline/index/table of contents.

Thank you.

foliate seems a great thing, but

    /usr/bin/com.github.johnfactotum.Foliate


 .. come on

This scheme of naming binaries is popular amongst Elementary os apps. Maybe that's were the Dev took the idea from.

I don't mind it, and if it bothers you, you can easily alias it to something else


It is a scheme used by Flatpak.

The package prefix is mandatory, in order for flatpaks not to stomp on each other.


To be exact Flatpak only requires that for exported data files. Since binaries are not exported they can be named anything.

Binaries are not exported, but helper launch scripts are (those that do "exec flatpak run ...").

Oh alright, I didn't realise that

of course, after you locate the binary in your fs

Fbreader is nice, I've only used Calibre for converting ebooks not sure you can read in it.

you can reader using Calibre, it's far from being a good reader

https://news-cdn.softpedia.com/images/news2/calibre-ebook-re...


If you open a .mobi in Calibre it takes tens of seconds, on a reasonably fast system, to open small (<2meg) books. I'd agree with the other comments here - Calibre is great in terms of it being powerful (web server to serve up books directly to a kindle without having to plug it in, search is ok once you know how to use it) but has a terrible UI (I shouldn't have to google to discover how to search my local library).

I've been using Calibre-Web[1] as a frontend for the Calibre database, visiting it with my Kobo Auro H2O.

It will do neat things like convert to Kindle & email to the Kindle address with a button press as well so I can give access to my mum and so she can seamlessly read the epub books I have in my library on her Kindle.

It doesn't look great on the Kobo, but I can navigate pretty quickly to download a book, and I hardly ever have to touch calibre itself.

It's pretty easy to get set up running headlessly on a server somwhere.

[1] https://github.com/janeczku/calibre-web


I liked FBReader until I realized it wasn't displaying the blank lines used by the book series I was reading to separate sections in a chapter. Undoubtably the ebooks' CSS was bad, but other readers, like my Sony e-ink device, displayed them OK.

I am currently using https://github.com/burtonator/polar-bookshelf and its one of the amazing software i use daily.

Calibre's ebook-viewer is tolerable when your distro doesn't break Qt5/Calibre; I think that's an Arch problem, unfortunately.

The epubreader addon for Firefox is not perfect, but it is pretty good. It would be better if it would:

- reflow on window size change

- allow me to pick any system font to read in


Impressive, you've tried so much e-readers except the right one: FBreader.

Bookworm definitely has a two-page view. I'm using it on Elementary OS

Two-page view in Bookworm is problematic. See https://github.com/babluboy/bookworm/issues/199

pandoc+emacs. I also use the read-aloud package, which all together makes the best ereader+TTS experience. (However I run the TTS over the lan on a mac, because FOSS text-to-speech is awful.)

Well you forgot FB Reader

Ever tried Evince?

Evince doesn't support EPUB, and the request for support has been marked as WONTFIX (see https://bugzilla.gnome.org/show_bug.cgi?id=539347).

However, Atril, which was originally forked from Evince, does support EPUB rather well.


I test it on macOS, it can't work will with epub from Kobo :(

Ecosystems are tough. I'd never used meson, so I installed it using apt-get. I tried to build Foliate, and got an error about wrong arguments to `project()`. Searching for the error brought results about a wrong version, so I uninstalled meson and reinstalled it using pip. The installation completed fine. I went to run Foliate (com.github.johnfactotum.Foliate, if that wasn't somehow obvious), and I got an error from GJS (JS ERROR: SyntaxError: invalid property id @ resource:///com/github/johnfactotum/Foliate/js/main.js:57 JS_EvaluateScript() failed).

If it's obvious to anyone else what's wrong here, it's not obvious to me. Isn't one of the advantages of interpreting the code on the target platform supposed to be portability? If so, why is it I so seldom can can get anything written for GJS, or Node, or a Python program not my own, to install and run without a three-hour yak shave?

I'm sure this is a great project, and I mean no disrespect to the author, who did a better job of installation instructions than most — but I'm tired of installation being such a pain. It's almost, but not quite, enough to make a guy run Windows.


> Searching for the error brought results about a wrong version

One of the bullet points from the Meson website:

> * fun!

So if I understand correctly, this modern build tool created to replace all the extant time-wasting build tools got memorialized in Debian in a half-baked state where it's not compatible with future versions.

Also-- the fact that you had to leave the hardened bank vault of apt through the screen door of pip... to install a thing to build other things to run on your system.

I love it.

> If so, why is it I so seldom can can get anything written for GJS, or Node, or a Python program not my own, to install and run without a three-hour yak shave?

... is the question that explains why Electron exists. Every comment on HN about its size, memory usage, and insecurity doubles as a critique of all the problems you just hit with a Linux system.

Electron: "Memory and disk space is cheap enough, but your time will never be."


It's worth mentioning in this context that the thing making Foliate difficult to build and run on older platforms is the fact that it's written in modern Javascript (and therefore needs a modern version of gjs): https://github.com/johnfactotum/foliate/issues/45

I don't like Electron — I've brought some of my problems on myself by my love of using minimally-capable old hardware — but this is by far the best statement of the argument for it I've ever heard.

I propose on building native tools that have all relevant libraries statically linked. Yeah, executable will grow in size, but it's the best of both world : portability, speed and not using javascript.

[flagged]


Snark isn't ok here and personal attacks will get you banned. Would you mind reviewing https://news.ycombinator.com/newsguidelines.html and sticking to those rules when posting to HN? We'd be grateful.

Hi, author of Foliate here. It sounds like you're using something like Ubuntu 16.04 or similar? Foliate currently requires GJS >= 1.52 and Meson >= 0.40.

There's an open issue here on supporting older systems: https://github.com/johnfactotum/foliate/issues/45


I'm using Debian 9.8 Stretch, released in February.

Hi,

I've using Linux as my primary desktop at work and home for going on 25 years.

If you want to use newer software you should pick a distribution that is geared for that.

Debian stable is for people that DON'T want new software or even to try new software.

You are at odds with your choices.

Either switch to Testing, Unstable or pick an Ubuntu strategy ie Long term or every 6 months.

Of these choices Ubuntu is actually more conservative then Testing or Unstable as it walks forward in a predictable time based manner.

Good luck.


That's one perspective, and it has merit. Others tell me, "You should use a stable release and build software you need from scratch — that way, you get the best of both worlds!" In either case, it seems like writing new software using bleeding-edge versions of libraries and tools is not really necessary; if you hang back a couple releases, it makes matters much easier. Backward compatibility is much easier to achieve than forward.

(I don't have enough experience with GJS and WebkitGtk to know if slightly older versions would have been workable here, though I believe that approach to be valid in most cases.)


A library from 1 to 6 to 18 months ago is not "bleeding edge" in any way shape or form.

You are making software reactionary arguments for people doing a lot of work to support you touristing their software from an ancient, long out of date software distribution (which is what people that use Debian Stable want).

If you are going to make bug reports or even comments you really would be better to state you are on Debian Stable from the beginning, it's actually rude to make people think you are on a reasonably supportable distro without warning.

Flatpak is probably your best choice to encourage people to be even able to support your distribution choice going forward. The sandbox also has some attendant benefits that will bear more fruit in the future.


> In either case, it seems like writing new software using bleeding-edge versions of libraries and tools is not really necessary; if you hang back a couple releases, it makes matters much easier.

I believe this is precisely what Foliate does. It depends on meson 0.40 (released Apr 2017) and gjs 0.52 (released Mar 2018). Sixteen months old dependencies can hardly be considered bleeding-edge.


You are clearly right, and I assumed wrongly.

> released in February.

Yeah, that's not how Debian stable works.


It's when the point release was done[0]. Obviously not everything was new then. I'm assuming most people who package applications for Linux have an understanding of how Debian works.

[0]: https://www.debian.org/News/2019/20190216


> Obviously not everything was new then.

Nothing was! Debian stable doesn't update packages (not even minor releases or bugfixes). They only backport security fixes or very critical bugfixes.

Debian 9 was freezed on 2017-02-05. You'll have the version of every package from this date, point release don't change that.


We're not disagreeing — please stop trying to raise an argument where there is none!

My only reason for giving the point release date was to say that it's a supported release. You're reading a lot more into my tiny comment than I ever put into it.


> it's a supported release.

Calling it "supported" in the context of the ability to build arbitrary software is misleading. It's supported by Debian for the particular packages included in Debian's package repositories - nothing less, nothing more.


why don't you make a configure script that detects and warns about these requirements?


Yes, I finally installed it via Flatpak. What a fun adventure! First, I had to install Flatpak with apt. Then, I downloaded the Foliate .flatpakref. I installed it with `flatpack install com.github.johnfactotum.Foliate.flatpakref`, which worked the first time!

No, it didn't. Of course, Flatpak let me know that my user account didn't have the ability to configure the remote repositories the Foliate flatpakref specified. I could have searched for the right way to do it, but installing as root seemed to work, and it runs fine as a regular user, too!

But, of course, it doesn't. It doesn't have the ability to open files from most folders. I see by searching that you set sandbox permissions in an application manifest file, but I'm not sure I'm that attached to doing any more of this.


Installing it via "flatpak install foliate" didn't work? Downloading the .flatpakref seems like an unnecessary step to me but I'm on a different distro (openSUSE Tumbleweed).

edit: I can also open files from anywhere on my PC. Could it be that the flatpak on Debian Stretch is not correctly configured?


I'm pretty sure your edit nails it: flatpak on my moldy Debian doesn't work correctly as a non-root user, and the alternative of running it as root and then running the application as a normal user was neither intended nor foreseen.

I did finally install Debian testing, and it looks like the flatpak problems are resolved, but I decided not to bother installing foliate because of the nearly 700MB of dependencies it wanted over my rural satellite connection. C'est la vie.


I went ahead and burned the data: for Science! After the dependencies were all downloaded, it works correctly and completely. It's a fairly nice ebook reader application, and it only took three days and replacing my operating system to get it.

But then you can't make changes to the app! You're stuck with a read-only copy.

You can build your own Flatpaks from source, too. In fact that's probably how a lot of development is done these days around GNOME and its wider community when using Gnome Builder. You make a change, and Gnome Builder builds a Flatpak and runs it for you so you can test it.

After cloning the project, all you should have to do is to ./src/main.js and the shebang should take care of the rest (running gjs, node, python etc).

Why complicate things? build-steps are the root of all evil.


Just looking at the source and finding out it's JavaScript.

Although I'm probably living in a cave and didn't use Linux often on the desktop since years, it is common practice now to write Gtk/Gnome apps in JS? I tought Vala was the cool language for that kind of apps...


> I tought Vala was the cool language for that kind of apps...

I think you’re about ten years behind the trend.


Nope, new applications are commonly being written in Vala.

For example bookworm, a GTK eBook viewer.


I didn't say all new applications were being written in JS, did I? So any number of counterexamples does not disprove what I said. We were talking about the trend of what people were looking at using now.

Ok, please: what language are people using when they want to create gnome software ? Or the trend of what people are looking at using, if you prefer. Edit: switched two words.

It uses epub.js which i think is really cool for rendering the documents. The UI looks pretty impressive as well. For anyone coming from Calibre, this would look amazing

Kudos to the developer for seeing a need and building something that fills that need with a clean UI. As a developer, I get that the quickest path to building a well featured eBook reader meant building on top of ePub.js.

However, purely from an idealistic engineering perspective (I know, some people do not care at all about that), having to rely on the DOM + a fully featured JavaScript engine to render an ebook is just... insane.


Well, epub is just special HTML. I don't think you strictly need JavaScript, but it's about the easiest way to work with and render HTML. And I imagine rendering PDF is a whole lot messier.

GJS is the easiest way to write Gtk/Gnome apps these days, and it uses the native controls

I saw JavaScript and for a moment, and I was like - "Oh no, not electron again", and moment later I was happy to see that it was not Electron!

Saw that too and dismissed the project.

My PC has plenty of resources, but if I'm going to use a browser to read books, I might as well upload it to Google Play Books and use the browser I already have open for other things. It has the same functionality and my progress and bookmarks are synced across devices.

Granted, epubs are easily converted to HTML, but I shouldn't need an additional few hundreds Mb of RAM to read a 5Mb file.


Wow, I didn't see this coming. I always had this problem in Linux to the point I am going to ditch Linux for windows the moment wsl2 becomes stable. But this app is literally awesome. I wish Gnome foundation would stop acting stupid as hell and start funding projet like this and make it official Gnome project.

Thank you so much.


I think the problem is that funding probably comes from Redhat and/or FSF. One of those is interested in business uses and the other doesn't have a lot of money.

I'm starting to think everyone who can write code should try to contribute what effort they can to an open source project. I'm starting to see how a lot of small individual contributions add up over time. A project still needs a good maintainer and vision though, and that's a lot of work for someone.


I'm glad to see hyphenation was taken into account, even if it requires some extra packages. On the Android epub readers I've tried it never seemed to work (maybe they only support English if at all?).

I like how it gives an option for margin size. It even allows 0 margin! One of the most annoying things about Google Play Books is that it puts pretty big margins to left and right and you have no control over them, so my phone's screen is wasted on a lot of empty space. Amazon Kindle is better because it provides a narrower margin option but I would prefer just 0 margin on my phone.

Also the app itself looks nice and native, good job.


Why don't use the compilable language? Nobody think about resources these days.

How do you know they didn't consider resources?

If you want to compile a language you're going to need a compiler and a linker. Do you know how much water it takes to compile a single executable? Water that's better used irrigating a field which could support hundreds of well-written python and bash scripts.


In this case, I don't know how much it matters--EPUB is basically HTML, so you are going to be based around a browser-like component anyway. Might as well code the UI in js.

This isnt electron, GJS uses native GTK controls

README mentions a dependency on webkit2gtk, probably only for the ebook rendering but it's not far from electron in that case.

Yea, webkit2gtk is pretty heavy (or at least it seems that way when trying to compile it), but it might have been the easiest way to render epub files as their render is pretty similar to HTML.

It's all about tradeoffs and I don't think this one is too bad. I'm glad it isn't a pure electron app.

Now we just need decent open hardware for Linux tablets! I'd love to use this program to read books on one of those mythical open source tablets that can run KDE Plasma.


Are there any open hardware eink ebook readers?

I don't think there are any.

However, you easily can install alternative readers on Kobo ereaders, see here for a list of some hacks:

https://www.mobileread.com/forums/showthread.php?t=295612


There's the BQ Cervantes, which runs FOSS software, but Kobo's open source community seems much more active.

https://github.com/bq/cervantes

https://blog.bq.com/es/bq-ereaders-developers-program/


This will be great to use on the Librem 5 when it's released! (https://puri.sm/products/librem-5/)

I wanted to give it a try, but attempting to build a Debian package fails.

$ dpkg-buildpackage

...

gpg: skipped "John Factotum <50942278+johnfactotum@users.noreply.github.com>": No secret key gpg: dpkg-sign.LHxm7FS6/com.github.johnfactotum.foliate_1.4.0.dsc: clear-sign failed: No secret key

dpkg-buildpackage: error: failed to sign .dsc file

edit: build does indeed work and I could use the viewer, building a Debian package fails though.


I had the same issue and got it to work with dpkg-buildpackage --no-sign

Any reason why this can't be cross platform? Seems to be mostly using supposedly cross platform libraries like GTK...

AFAIK GTK cross platform effort was always secondary. Now from version 3 even more so.

I see no reason why it wouldn't work. Try building it on your platform of choice

I dual boot everyday. I want to have equivalent software for both Linux and windows, to not to change my workflow too much.

I am using Freda in Windows to read ebooks.

I was worried about what to use in Linux. The Calibre viewer simply doesn't have the same quality as Freda.

Foliate is great, and I no longer worry about this. Thanks for the heads up.


What makes it "modern"?

In my case, the most competitive UI in desktop e-reader

It does look pretty and it's probably very usable on a tablet, but on a full-featured computer (i.e. one equipped with keyboard and mouse) it's inefficient and idiotic.

Your comment is overly hostile. The author is present, you could give some constructive feedback instead of insulting the design.

I actually disagree with you, the UI seems elegant and very usable on desktop. Maybe smallish window size on screenshots give impression that it's more suitable for tablet?


Ok, idiotic was not the right word. I apologise.

Could OP or someone else give an overview of how web-based interfaces work on native apps like this, without using something like electron? Is there a full js interpreter, dom, css parser, etc in something like Foliate?

In the readme I see:

   The following are runtime requirements:
   gjs (>= 1.52)
   webkit2gtk
So my guess is that it's just using webkit for the html rendering.

I think it is mostly done by: https://gitlab.gnome.org/GNOME/gjs

Looks really nice. I am wondering who is reading eBooks on their computer though. Isn't it annoying to be reading a whole book on your computer?

I read programming ebooks on my computer while typing out the programs into Vim. As I learned from Zed in his C book that you must type out the code examples if you’re going to learn from them, which I’ve found extremely useful.

Otherwise for long form reading sections I switch back to my Kindle, tablet, or paper book.

The other times I read on my computer are shorter academic papers, reference, and sampling the first chapter of books before switching them to my Kindle or tablet.


Very cool! Lately I rarely see good new GTK applications coming out so this warms my heart. :)

Does it support multiple tabs? It doesn't seem to from the screenshot.

Currently there's no tabs support. But it does support multiple windows.

Looks great! I've been looking for a good e-reader for Linux lately.



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: