Disappointed in organization options

[chaley]

Originally Posted by Starson17

Your ln, fn tweak is the only "tweak" I've actually heard about. Is the "tweak" option flexible enough to add new buttons the way he seems to want?

Yes, its a simple matter of programming.

Kovid added 'tweaks' to introduce options that he didn't think needed to be settable in the GUI. There are currently two of them, stored in the personalization file tweaks.py (for me on windows 7 in C:\Users\charles\AppData\Roaming\calibre). The tweaks are:

# The algorithm used to assign a new book in an existing series a series number.
# Possible values are:
# next - Next available number
# const - Assign the number 1 always
series_index_auto_increment = 'next'

# The algorithm used to copy author to author_sort
# Possible values are:
# invert: use "fn ln" -> "ln, fn" (the original algorithm)
# copy : copy author to author_sort without modification
# comma : use 'copy' if there is a ',' in the name, otherwise use 'invert'
author_sort_copy_method = 'comma'

The tweaks could help control generation of alternate GUIs, but I think that such a use wouldn't be wise. The code would be full of if/then choosing which widgets to create, making maintenance a nightmare.

I use your exact search option a lot (I didn't know you wrote that one.) Did you also write the regex search option?

Thanks. And yes, the regexp is mine; it seemed like a natural extension and was easy to add. I am glad that someone is using it -- must mean that it works.

[kovidgoyal]

@rchiav: I'd be fascinated to hear exactly how you propose to add more flexibility to calibre's classification system. Give me a concrete proposal that meets the following criteria, and I'll be more than happy to add it to my TODO list

1) It needs to be integratable into the existing UI schema with a minimum of disruption. By that I mean, it should not make doing what can be done today harder. I am somewhat flexible on this. If the change is useful/cool enough I can be persuaded to relax it.

2) It needs to apply to a set of use cases that is proportional to the amount of disruption it causes. So if it is a small change/addition then it need only solve a handful of use cases or even a single one and if it is a large one...

3) If it is a replacement for some other system in calibre, it needs to be a superset of that system.

4) It needs to solve more problems than it creates (this is really just a re-statement of (2))

5) It needs to be a concrete proposal. The more concrete it is, the more likely it is to get done. If it comes with a patch it's likely to get done in a few weeks, as lots of people in this thread will confirm.

And let me assure you that you continue to be welcome in this forum. I enjoy the occasional scrap, keeps the blood flowing

[Starson17]

Originally Posted by chaley

Thanks. And yes, the regexp is mine; it seemed like a natural extension and was easy to add. I am glad that someone is using it -- must mean that it works.

It works great and I probably use it more than the exact match. It can find some records I just can't find in other ways. Thanks again.

[Starson17]

Originally Posted by kovidgoyal

And let me assure you that you continue to be welcome in this forum.

Ditto. You are very welcome here. I like different points of view. This thread really does remind me of chaley's first thread. What a loss to Calibre development that would have been if he'd felt unwanted.

[ficbot]

Kovid- how about a 'source' field to track where the ebook comes from? I am using tags for this but it means cluttering up my tags list with 5 or 6 extra entries. A 'source' field would solve this problem...

[kovidgoyal]

@ficbot: Adding specific columns to meet specific demands will very quickly lead to chaos. Instead, at some point in the future I will add the ability for user to define their own columns.

[Guns4Hire]

Originally Posted by kovidgoyal

@ficbot: Adding specific columns to meet specific demands will very quickly lead to chaos. Instead, at some point in the future I will add the ability for user to define their own columns.

Definitely looking forward to this.

[Worldwalker]

Originally Posted by kovidgoyal

@ficbot: Adding specific columns to meet specific demands will very quickly lead to chaos. Instead, at some point in the future I will add the ability for user to define their own columns.

I'm definitely looking forward to this.

You might want to consider the "source" column, though, because it would be of use to just about any calibre user who gets their books from more than one place. I've been using the "publisher" field for this, and using tags for publishers when they're important, but that's kind of bass-ackwards. Like many (perhaps most) ebook aficionados, I have my preferences in book sources, mostly due to their formatting, file quality, cleanup, etc., so I need to keep track of the source in order to make it easier to tell when I can replace a book from a higher-quality source. Unlike most other possible fields I could think of, this one really may be of enough universal benefit to be worth adding.

I know what you mean about the chaos, though. I feel for you. Years ago, I was selling some fairly popular software in a tiny niche market, and my users kept asking for more and more features to be added to its scripting language. I resisted for exactly that reason. If I'd extended it to incorporate every feature request, it would have ended up not only harder to learn and understand, but huge, slow, and impossible to maintain. I'm big on general-purpose tools. You don't want to have to have a different hammer for every kind of nail.

In more direct reply to rchiav:

If I invited you over for dinner, would you criticize my food, my cooking, even my teacups (ignoring the shocked looks on the faces of the other dinner guests), and demand that I cook something special just for you? No? Then don't do it with calibre. We're all guests at Kovid's table. We didn't buy the food, we didn't cook it, and most of us aren't even helping with the dishes. If we don't like what he's serving, we can always go home and cook our own.

[ficbot]

Thanks for the info! I do use the publisher field fr the publisher but some to think of it, I am not sure why as it is very seldom important. Maybe I can co-opt that field for the name of the source.

[kovidgoyal]

I'd like to understand a little more about the need for a special column. As I see it, there are two advantages to a column as opposed to a tag.

1) Sorting (this is not really an advantage for a field like source as far as I can see)

2) Easy reference (the contents of a column are easily visible, while a tag can be hard to spot if there are a lot of tags).

I agree that (2) is an advantage. However, I don't really understand the use case.

I tag books by source in my own library. If I'm in the mood for books from a certain source, I just use the tag browser or type in the search and then browse over the books in the main view.

[Worldwalker]

It does the job, anyway. There are a few publishers I actually care about, mostly due to the collectible nature of some of their books, so I just use a tag for them. Still, a dedicated source field would be nice, so the publisher field could go back to tracking publishers. Out of all the things calibre needs, though, I figure that's pretty far down on the list, and not worth even a formal feature request.

At some point, when I actually get my physical library sorted out, I'm going to add a tag for whether I own the book in physical form as well, and if so in what format(s). ThinkGeek sells a little barcode reader that could scan the ISBN ... hmm, I wonder if using that plus blank books would make it practical to use calibre to index my physical library as well?

@Kovid:

The advantage of a column over a tag (and the reason I'm using the Publisher column for that at the moment) mostly has to do with the PRS's Collections. When I have books from here, PG, Feedbooks, Baen, yadda, yadda, yadda, the number of added Collections cluttering up my PRS would start to really get out of hand (as if it isn't already, though not as badly as our friend with the 99 tags on his 17 books). If excluding tags from collections (via [] or whatever) is implemented, this will be much less of an issue.

Isn't there some form of source/distributor/etc. field in the epub standard? If so, having access to that through calibre might be a Good Thing.

[theducks]

Originally Posted by Worldwalker

It does the job, anyway. There are a few publishers I actually care about, mostly due to the collectible nature of some of their books, so I just use a tag for them. Still, a dedicated source field would be nice, so the publisher field could go back to tracking publishers. Out of all the things calibre needs, though, I figure that's pretty far down on the list, and not worth even a formal feature request.

At some point, when I actually get my physical library sorted out, I'm going to add a tag for whether I own the book in physical form as well, and if so in what format(s). ThinkGeek sells a little barcode reader that could scan the ISBN ... hmm, I wonder if using that plus blank books would make it practical to use calibre to index my physical library as well?

I was thinking exactly the same
I already have a commercial handheld barcode scanner.

[kovidgoyal]

Excluding tags from becoming collections via [] will be in the next release.

[Worldwalker]

Originally Posted by kovidgoyal

Excluding tags from becoming collections via [] will be in the next release.

Have I mentioned lately that I love you?

[Sabardeyn]

Originally Posted by Worldwalker

Isn't there some form of source/distributor/etc. field in the epub standard? If so, having access to that through calibre might be a Good Thing.

I'm not at all sure what metadata fields, and the acceptable content, are included in the epub standard. (Been to the site, but I'm not a programmer and most of what I read made little or no sense.) But some of what users want added might be a metadata related issue.

Some of the things we're asking for are what amounts, at least as I see things, as data that should inherently be a part of the book itself. Just as their is an Author, Publisher, ISBN, etc that would be found on a copyright page or frontispiece. A portion of the problem may well be that we're looking for metadata that is not yet a part of the official epub standard and so isn't being included in anyone else's ebook formats either.

I wanted a Version field (version numbering for the body text of the ebook, not any of the containers / scripting). Worldwalker is looking for a Source field. I am sure that others are asking for other material to be included (Artist/Illustrator for manga or comics, etc).

Anyway, perhaps differentiating between calibre's file management requirements and an ebook's metadata needs to be clarified? Effectively they overlap, so from the User's viewpoint you get a thought process of absolute(calibre metadata = ebook metadata) AND vice versa. Unfortunately this thought process might not be the case. While I understand that you do not want to add unnecessary fields to calibre, nor compliance breaking metadata to an ebook (in any format), something might need to be done. The user defined fields will be of help, but I am not sure it will be enough ultimately.

I've thought that calibre was using a subset of the entire range of available metadata fields on a well crafted ebook file. It wasn't until Worldwalker's comment quoted above that it occurred to me this might not be the case. (Yes, I did assume not all ebooks are well crafted, but still...)