>it’s a slow app >it’s ugly >it’s poorly designed >nothing else even comes >the task was so monumental

I think what's going on here is that Calibre is implemented for free in spare time in Python with an eye toward being accessible to all audiences and feature complete. So, it's neither super fast, nor super pretty, nor super elegant. But everyone can build up a library of ebooks without much effort and then browse around and read them, highlight them, and sort them in various ways.

You're welcome to submit patches that hide everything behind a hamburger menu and make the scrollbars vanish and crap like that.

That’s actually not an easy patch — I looked into it and the way the QT layer works — not even diving into the codebase underneath — doing anything more than an icon pack/skin is nearly impossible — at least with my level of skill and the amount of time I would be willing to put into it.

As I said, I’m super grateful Calibre exists and I think software is better for it existing. I also fully understand why there haven’t been other attempts to do what Calibre does — because it’s a shitload of work and the userbase is niche.

Design is something that can't simply be tacked on after the fact either. It's something that must be embraced by the core developers and influences plenty of decision making.

Plenty of people don't have good design taste but can still be useful software, so I hope it doesn't deter them.

Although there may be a correlation between poor interface design being reflected in the backend. From naming schemes, to modelling the data, to managing complexity, saying no to certain features, etc are all things that cross over into the design world.

Calibre is just a qwidgets based pyqt program. Since its as KDE project the "modern" UI stack would be Kirigami QML and you can use QWidget::createWindowContainer to embed QtQuick parts in a QWidgets program. With signals and slots they can still communicate, so you can peacemeal replace parts of the UI like that, but looking at the sources the main window is composed of about 30 different parts between a half dozen folders so thats pretty immutable.

Immutable is the right word. I was trying to “fix” the new dark mode in Calibre 4 (it’s bad and clearly not tested — the default hyperlink colors are nearly unreadable and the hover-over color in the library menu are impossible to read), and while I could fix the CSS in some parts (which was the dev’s dismissive answer to the bug report on how dark mode is legitimately broken), other parts can’t be fixed without using overly-complex plugins (that have to apply overrides every time you start the app) or ripping apart the source in a way that is not worth the effort.

My solution was to use a different Mac app to “force” Calibre to ignore the systemwide setting and use its light mode instead.

Over the last few years reading HN comments a part of me can't help but think that the more criticism leveled at an application or technology the more useful it is for end users. This is probably true for Node, PHP, MySQL and Wordpress to name a few. Kovid Goyal should take the criticisms a sign Calibre is very useful to end users.

I totally agree. In my case, it’s definitely a case of “I bitch because I care” — and I am very appreciative of the app and the hard work that has gone into it. I cannot imagine doing all of that myself and making the app free at that.

I do think it’s a shame the codebase is such that seems to prevent meaningful contributions/collaboration that might improve things — but Kovid has done something amazing, make no mistake.

And more to the point — we all complain about Calibre, yet no other app exists that even does a fraction of what it does.

> “I bitch because I care”

This. Or:

"I WANT it to be better."

It's sad that the response to that is often "Stop bitching or stop using it", "Make it yourself", or "If you don't like it why don't you go somewhere else?" (and it's often from other users who try to speak on behalf on the developers.)

> I cannot imagine doing all of that myself and making the app free at that.

The only reason we are here talking about it is because its free software. Its not even about price, its about how Calibre evolved thanks to a community that grew around it. Maybe someone could start a proprietary ebook library program, charge for it, and make a living that way. But it would get orders of magnitude less usage and have done that much less good for the whole of mankind as a result. And the work of one person, or even a small team, is unlikely to accomplish all the features Calibre has because few people will recognize the collective needs of all book readers the way an open bug tracker and merge requests can.

I guess there is something to be said about applications purely focused on user needs and not engineering. MS Excel and MS Access applications vs applications developed by engineers using the latest framework. On a personal level I was happy Drupal end user because whilst I am a developer I am not a web developer. Drupal 7 was useful to me it allowed me to create useful web applications similar to using MS Access on the desktop. I cannot even get the well engineered Drupal 8 running because I honestly don't have the time to first learn things like Composer.

Stroustroup's version of this (about C++, of course): “There are only two kinds of languages: the ones people complain about and the ones nobody uses.”

The problem is that, even if true, this chestnut doesn't say anything about whether the criticism is justified or whether the degree and correctness of criticism is commensurate what one would expect of a quality product given the language/software's usage.

Because otherwise it would no be talked about on HN.

Nobody cares about the myriads of ugly, bad designed apps that are not useful.

A counter point, nobody cares about the well engineered apps that have not been completed or do not have features useful to the end users.

It could be that, the more users a product has, the more criticism it will receive (say, if one percent of users always complain). I also know I sometimes complain about some software I really like, as it would be completely perfect for me with this or that one additionnal feature.

The last line reads needlessly dismissively. Someone, quite rightly, making an observation that the user interface/experience could do a little work is not analogous to someone suggesting the app should become the victim of poorly thought-out modern design trends.

Modern design trends != usability. Calibre is in need to usability and performance improvements.

That's pretty much what I said.

> Calibre is implemented for free in spare time in Python

Well it was Python. The number of C extensions means they can't go back without many hours of work and hundreds of thousands (or millions) of LOC cleaned and tested.

For instance, I recall a LZMA decompression C/Python script in the Calibre source. Python 3.3 added LZMA in the stdlib, but they're stuck maintaining their handrolled one.

I'm missing details. I learned quite a bit from that codebase awhile back.

> without much effort

I remember trying Calibre years ago and figure out how to use it was enough trouble that I just shelved it. Your post reads as though UX doesn't matter much, but that's far from reality.

Anecdotally, I had the opposite experience. From the first time I loaded up Calibre, I mostly understood how it worked.

Perhaps it just clicked with me easier than with others, but other than the "bare bones" interface, I think it's a reasonably intuitive program.

I run it on a server and use calibre-web as a frontend. Has a nice UI and works well for my purposes:

https://github.com/janeczku/calibre-web

Interesting. I wonder if you could embed something based on calibre-web in an Electron app. It'd be one way to get a better UI in a more accessible way...

I just use chrome for this:

chrome.exe --app="https://url.of.calibre.web"

Removes the top bar and shows the favicon as the application icon. You can create a shortcut/.desktop and it'll act pretty much like an electron app would.

But you still gotta run the 'web app' somewhere, responding on some port (even if only on localhost)?

With the new server backend that has been released where you can add remove books and modify metadata etc. It would be lot easier to build a different frontend. The Calibre Dev is quite open to take patches that increase functionality without taking away previous functionality so he would be probably open to adding more functions in the server.

How is this better then running the standard calibre in daemon mode. I sync my library to a vps and do this:

/usr/bin/calibre-server --daemonize --enable-auth --url-prefix=/calibre --port 8000 --enable-local-write --log /home/user/calibre_log /home/user/user_library

I feel similarly - I use Calibre because it's the least-worst option. I truely appreciate the effort the devs put in, because I know how complex it is and that I wouldn't expend the effort myself.

But it certainly has some performance and UX issues. For me personally, I'd prefer to focus on getting the UX right, then I wouldn't care so much about the performance

Isn't this the case for a lot of tools?

For me Thunderbird is one of those - there's no better open source mail client to be found and you use it because it works (most of the time).

The problem with this is that creating GUIs is very complicated as there's just too many different frameworks and specific stuff to know to achieve this. In my opinion interface design on computers is kind of broken just because there's no standard that works for every system. I don't want to implement things 4 or 5 times to get the same result.

If I could I would contribute to those apps because I have good ideas for UX/UI but I'm nowhere near learning all the stuff I need to know to do so I'm afraid. Maybe when I'm really old and retire it's still as crappy as it is and I'll find the time.

In the meanwhile at least we have tools like Calibre and Thunderbird and I'm very thankful for the work the Dev's put into them! :)