I just wanna present here the idea for a new Calibre Import plugin. I'm interested to know whether such a plugin would be of any value and whether I should take the burden of publishing it.
I worked on such a plugin privately. It imports a Calibre database into Joplin with the following features:
Use a hierarchical Genre field to create notebooks in Joplin.
Create notes from the Ebooks in these genres
Each note contains a title, a cover, a link to the book and comments in a Spoiler block (extendable by additional metadata)
The last thing (Spoiler block) could be made configurable
Also a user-defined Content field can be displayed
Certain features are configurable, for instance the Genre field
I'm looking forward for any comments and suggestions
Jürgen
I find what you're proposing quite fascinating, but I'm not sure how I'd use it. I did a similar thing with Tap Forms, but in Tap Forms you can have as many databases as you want. Not sure how it would work with Joplin. I do keep a list of references in Joplin, and I suppose it could be used that way.
I tend to group my books not by genre, but by author. A single author could have books in multiple genres. Each author gets his own note with each book listed within it. The author could have multiple series of books in different genres and I need to track those read and owned, those borrowed from the library, those listened to from Audible or Chirp etc. - Those purchased but not read.
Calibre places the list by date which is very useful and also provides an author list. I rate and edit the metadata in Calibre.
However, often there is an author with a series of say 15 books and I've read 5 of them, and have 2 later ones purchased on sale which I might read, or...
Anyway, that's how I do it. Calibre is a subset of the books I've read.
I use Calibre here, mostly for side-loading my Kobo ereader; I have a separate database where I actually maintain a library of both my ebooks and paper books. I can't quite get my head around copying the details to Joplin, however...
What did spark my interest was your attributes plugin. Can you tell me how you came to choose the:
///attributes:style=list-style-type:none
syntax for implementation? I was looking at attributes recently, hoping there might have been some sort of close-to-standard definition anywhere, but it seems like no one has been able to agree. Python attribute lists offer something like this:
///attributes:style=list-style-type:none
1. LIST ITEM 1
In this case a CSS style is used but you can also use other attributes like this:
///attributes:class=para-class
and then adapt your style sheet accordingly (for instance at the beginning of a md page). It's also possible to have a comma separated list of attributes.
At the end I just invented an own block for markdown-it!.
Thanks for the extra info, it seems like a neat solution. I will definitely install the plugin and have a play around. At the moment I'm mostly looking for a markdown alternative to div blocks which can run into issues when switching back and forth with rich editors and so on. The block quote solution should work I find it cumbersome cumbersome to use. I'm also looking at the admonition plugins for their ability to style a larger block.
I had some curious problems where the attribute plugin didn't seem to be working properly on my existing profiles, but when I installed JoplinPortable (v2.12 or v2.13) using fresh profiles then the plugin worked - with or without all the plugins I've been playing with. I played with disabling and completely removing other plugins, lots of different Joplin configurations, and nothing seemed to be working until ... it suddenly started working, and I still don't know what the earlier problem was.
Once I got the attribute stuff going it seemed to work very well. I was hoping that the wysiwyg editor in Joplin would leave the '///' lines alone, but it doesn't (probably never actually sees the raw markdown). So I still have to be careful in Joplin not to use the wysiwyg editor. Nothing new, and nothing this plugin has any control over.
I think Joplin needs different translators for the preview and and wysiwyg editors, so the latter gets translations only for markdown it can cope with in both directions. I was able to simulate something like it by disabling the plugin before "accidentally" going into the wysiwyg editor - there were still some extraneous new lines on return, but at least the unrecognised markdown wasn't totally lost.