Update about the new Plume

Hello everyone !

You will find here a more detailed update more “developer oriented”.

I decided long ago that Plume would use SQLite as its internal database. It’s a lot easier than the XML tree I used in the first version. Aspects like relationships are built-in and it gave me new ideas.

From the start, I feared a lack of fluidity in the GUI, so I went to see what I could do with asynchronous database management. I wrote “something” with a QThread in PyQt. My test cases gave me success at random. Even with a great IDE like PyCharm, it was a pain to debug and to know what was happening in the other threads. Two weeks ago, I switched back to C++ / Qt 5 on Qt Creator. Quickly, I created a C++ library dedicated to the database. Then, I learned how to use SIP to wrap this library so I could import it in my Python code. And surprise… it works !

Well, I still encounters a few strange behaviors. For instance, the first database method used after loading a database will give me 0 or an empty list. I’ll see to fix that later since I lost enough time as it is.

The final version of Plume will keep this C++ library, below the GUI written in Python. I feel that I’m gaining momentum and that the API is getting somewhere. Now, I’m being able to access a project’s database with a simple :

title = data.writeHub().getTitle(project_id, paper_id)

My inspiration for the GUI design will be Qt Creator. I’m already able to display several projects at the same time on the structure tree.

From now on, I’ll give regular updates with screenshots if those are available.

Cyril Jacquet

2 thoughts on “Update about the new Plume

  1. Why not use the filesystem as the database? Metadata and revision history (you are integrating a revision-control software, right?) can live conveniently in invisible dot-folders like .meta and .revhist, for example. Characters, places, objects, research can all go in their own handy little folders. Cross-linking files can be easily done with any lightweight markup language, or programmatically with a document processor with each (auto)save. Plenty of appropriate tools are already available for this.

    Or maybe I have the wrong idea about what, exactly, an a relational database does or how to use it? Regardless, I would dearly love to see the new edition use a file structure editable in any text editor if or when an author finds themselves on a computer without Plume, or a phone or tablet. For my books, I’ve been making extensive notes and moderate edits in DroidEdit on my Android-based phone, so the ability to do this is important; at least to me.

    1. Hello Charles,

      Earlier in the year, I played with this sort of construct and have been able to pinpoint difficulties. You have the OS peculiarities (ex : hidden files vs “.xxx” files, forbidden characters), then you have the lack of ordering. Finally, detecting when a file was modified by the user’s hand. I did all that and Plume was not responding in a timely manner.

      So, I’ll say Plume can’t work directly from this sort of structure. A relational database like SQLITE 3 is cross-platform, supports Unicode (think of asian languages), and allow easy growth and modification of the structure for future versions. What I want to be done later is an export to a directory structure, and a way to import a change.

      Cyril Jacquet

Leave a Reply

Your email address will not be published. Required fields are marked *