I thought your suggestion was driven by the number of users who complained here about the library structure. Those are exactly the users who wouldn't find your hidden "know-what-you-are-doing" plugin, and wouldn't understand why their library was being changed by Calibre. If the abstraction options were pointed out to them, and they changed the abstraction to a "better" naming format, they'd be upset by normal Calibre operation. As I said, the only reason they want a "better" library structure and a different naming format is to make it easier to do things that might interfere with Calibre's library management.
Quote:
|
I feel that by making storage means a choice calibre would benefit in the end. Surely, initially there would be more bugs detected, some code reworks done, but in the end the codebase would be more stable as a result.
|
A worthwhile goal if stability was an issue now, but it's not. I don't see any stability issues that abstraction would help with.
Moreover, it's been my experience that the more sophisticated the user, the
less they feel a need to control the library structure. You're building a fix that only sophisticated users can safely use, and almost none of them seem to need or want it.
Quote:
|
That's assumming Kovid still likes to develop and manage calibre - if he's getting weary of it, and thinks often of the time when he could finish all the goals for calibre he set for himself, and switch to something more interesting, that would be one more unneccessary complication, and my arguments don't apply. I have some projects like that...
|
This shows you are definitely very new here. Calibre is actively being developed and major changes are made frequently. There are whole sections of the interface being reserved for future enhancements that are on the development road map.