Quote:
Originally Posted by travger
Two links? One to wikipeda and one to local machine?
Often enough wiki has more info than I'm willing to read and also I might not want to go to the web, but it's nice to have the possibility in reach. File in local machine would be wonderful - some people could want excel or word to mark books they have, some would be content with text, and some may have even video of the author...
I imagine it being not 'open with', but rather like format in book details panel - if I click on it, it opens with appropriate reader.
And if those files could be stored somewhere next to/in Calibre files... (so that in making backup I won't forget them)
|
Wonderful example of why I am not sure I want to go here.
Moving from one to two links is 20 times the work (1-N table associations and the like). Ensuring that clickable links work everywhere (book details, library display, content server) is more work. I mean no criticism here. You are absolutely correct to point out the logical consequences starting down a path. Of course, a user will want to manage the application used to open a particular link type, and of course any data should be in known places (although along with kiwidude I am not convinced that the library is that place). These issues should be thought of in advance, and comments like yours help.
@kiwidude: integrating an authors database into the GUI beyond single line management and/or ensuring that the lifetime of an author is independent of all book references is far beyond where I am willing to go.
@kovid: the difficulty here is that the authors table must be extended to have another column for the link (assuming a 1-1 link/author relationship). This creates problems of management, of consistent availability (can it be clicked in book details but not content server and the library view?), and of meaning (is extension sufficient for open/with?). I do agree that having a default link template for authors in book-details would be reasonably straight-forward.