Disappointed in organization options

[itimpi]

I find it incredible that the ePub standard does not yet have an official way of defining a Series Name and Series Index. If you are a fiction reader this is something that one uses heavily.

[kovidgoyal]

calibre uses a set of metadata that is not entirely supported by any ebook format. The ePub and FB2 standards are probably the most comprehensive, but calibre supports metadata that neither include in their specifications.

[chaley]

Originally Posted by kovidgoyal

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

Sorting (well, displaying) is useful when looking at multiple things at once. Considering source: I often want to look at where I obtained books from a set of authors (or some other set). Selecting the authors then looking at each set of tags is very tedious. Another, less frequent use is looking at the source of books I have recently read, so that I can 'correct' (that is, buy) any books where I don't have a legitimate physical or electronic copy. (This is not an invitation to start a discussion on piracy.) I have other uses involving other 'organizational' tags such as to read (separate for my wife and me), priority, read date, and a few others.

The tag-as-column enhancement I proposed plus the [] tag change would satisfy all my requirements without adding any new specific columns. However, if someone wants to use SQL to manipulate the information, or to use calibredb to extract and manipulate it, then real columns could be preferable.

[ficbot]

For me the advantage would be that I have six tags for source and it clutters up my tag list and makes browsing harder. One field would replace six tags. Often I do like to browse by source so I can check with paid-for books I have not yet read (as opposed to which free ones).

[rchiav]

Originally Posted by 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

Like I said before, I'm not trying to propose that anyone do something a specific way, but when I have the time, I will write up some use cases and a potential proposal. The idea I have has now grown to be more than just keeping track of if someone has completed their cleanups and edits.

From other responses here including in this thread, there seems to be a concern with cluttering up tags by using them to keep track of things like source or status or whether the book is read or not, etc... Kovid also has a very valid concern about adding to many fields.

So the requirement would seem to be the ability to not add a new field for everything that anyone would want to organize books by, but also not over clutter tags at the same time. I have the start of an idea but I'll wait until I can write it up so it's a little easier to follow.

I pulled down the source the other day but I haven't had a chance to look at it yet. I've used Python some, but I've never done any GUI development with it so that will take a little bit to get up to speed on. I also don't have a tremendous amount of time with two kids (6 and 2), a job and all the stuff that goes with that, but I'll see what I have time to look at.

[DoctorOhh]

Originally Posted by rchiav

I pulled down the source the other day but I haven't had a chance to look at it yet. I've used Python some, but I've never done any GUI development with it so that will take a little bit to get up to speed on. I also don't have a tremendous amount of time with two kids (6 and 2), a job and all the stuff that goes with that, but I'll see what I have time to look at.

The manual does a good job of explaining the development environment. It's all Greek to me but I think it would be great to get another programmer looking at ways to make Calibre better.

Recently there have been 3 or 4 programers who have added quite a few ideas and a lot of code to see those ideas become part of the package.

In my limited way I have even contributed to the effort by stumbling through the creation of five recipes of local newspapers and sites of interest.

Glad to have you considering contributing to the project.

[frabjous]

You know, you can skip calibre's GUI altogether and just use the many and rich command line tools calibre comes with. Then you can keep your files in whatever directories you like and still get almost all the power calibre offers. Heck, you could write your own GUI that served as a wrapper for calling those tools in your own way. (And it wouldn't need to be written in python.)

I use ebook-convert, ebook-meta and pdfmanipulate several times a week. But I almost never fire up calibre's GUI, and definitely don't keep my files in its Library folders. Used in this way, calibre is already more flexible than you may realize.

[rchiav]

Originally Posted by frabjous

You know, you can skip calibre's GUI altogether and just use the many and rich command line tools calibre comes with. Then you can keep your files in whatever directories you like and still get almost all the power calibre offers. Heck, you could write your own GUI that served as a wrapper for calling those tools in your own way. (And it wouldn't need to be written in python.)

I use ebook-convert, ebook-meta and pdfmanipulate several times a week. But I almost never fire up calibre's GUI, and definitely don't keep my files in its Library folders. Used in this way, calibre is already more flexible than you may realize.

I was actually thinking about using it that way and then writing something quick and dirty in Powershell to create a GUI just to keep track of their status. In my tests, invoking each of those commands was pretty slow, more than likely because (I'm assuming) of using py2exe and the fact that it has to extract everything needed, including python. Calibre seems to open slow as well, but that's just a one time thing when you load it the first time. You seem to pay that penalty every time you invoke the command line programs.

I actually like the library and I don't really need separate file system folders... just an option to quickly organize. If I went the custom GUI route, I'd still want to use calibre's library, and waiting for and parsing it's output every time I'd need to collect that information again would make things too slow.

I'm still planning on writing something up, but I just haven't had the time yet.

[Starson17]

Originally Posted by rchiav

Calibre seems to open slow as well.

Some important speed improvements were just found and will appear in the next release. I suspect they won't impact the initial load time much, but they greatly improve the speed when making changes to metadata inside the GUI.

[rchiav]

The initial slow load time isn't a big deal when you're using the full blown app. Sure, faster would be nicer, but you forget about it once the app is open. It's just if you were going to wrap the command line functionality in another app, that's where I noticed it more... and I don't think I would have followed through with that even if it was fast, so no big deal.

[ficbot]

I don't mind the slow load time, but converting anything to mobipokcet is positively glacial. Converting to other formats is brisk and snappy. I don't know what the issue is, but whenever I work with mobi files, it takes 3 times as long.