-
Notifications
You must be signed in to change notification settings - Fork 5
Short history of MaweJS
The roots of MaweJS lie around 2005. From around -95 I was drawing cartoons. I hated to draw 'intermediate panels', panels that only take the story forward but have no interesting graphical elements. I started to replace them with text. Eventually I replaced more and more panels with text, until the cartoons were more like graphic novels in that sense, that they were more text and less pictures.
I started to wonder, that if I like to tell a story, do I really need to draw it?
My first real text-only stories date around 2005.
At first I wrote them on regular text editor. I can't remember which one, but I am a programmer and used the same editor for both codes and stories, so a good bet would be gedit.
Eventually my stories grew larger. I started to split them to separate files. I was already using LaTeX: I made my Master's Thesis with it, and I knew it can handle larger texts. It was pretty logical to start writing stories to LaTeX format. So, I splitted my stories to multiple text files and used my coding editor to work with them, quite the same way I do coding.
LaTex format is just not really meant to write story manuscripts, but for layouting text. I started to build "text-to-LaTeX" converter named "texifier". Moreover, I realized that if the text is in multiple files, managing them gets harder. I had one "index file" with LaTex \include directives to control the order of text files in the draft.
What you get if you combine a programmer and a writer? You get a home-brewn writing software - both MOE and yWriter share this same background! I really tried to find myself an editor which does the thing I want, but couldn't find any.
So, meet MOE, Markus' Own Editor.
MOE was written with Python & GTK. Its main feature is that the text is split to smaller pieces, which can be rearranged with drag-n-drop. MOE saves the text in XML format, as it was back then one of the best supported hierarchial file format.
MOE file structure is such, that it has scene elements, which contain text and all sorts of attributes, like description and such. The other element is group, which act just as folders do in file systems - in MOE, you can have arbitrary deep trees.
In MOE, manuscript text and comments are in the same tree. The groups and scenes are marked if they belong to the draft, or if they are comments.
I really used MOE happily for years. It had its drawbacks, but it worked. I had something like 150 stories crafted with that, from which around 30 was published.
MOE is structured editor just like yWriter, Manuskript and Scrivener. It differs from them only by available features, and quite rough GTK-like outlook.
MOE has some nice features. For example, compared to software like yWriter, MOE has much more flexible way to make scenes. Pressing Alt-X at the middle of the scene will split the scene at that point. Pressing Alt-M will merge this scene to its predecessor. Or was it vice versa, scene was merged to its precedessor, can't remember anymore (MOE does not start in modern Linux/Python systems, so I have not used it in years).
NOTE: Now I remember. It was just the other way, pressing Alt-M merged the scene to its precedessor. Why this way? Because this way the cursor stayed at the merged part, and if you pressed Alt-X right after, you got the same situation as before (except that the scene description was now merged to previous one, and Alt-X didn't split descriptions)
The other drawback - believe or not! - was the arbitrary deep tree structure. I made it because why not? The GTK TreeView component don't care how deep your tree is. But eventually it became very clear to me, why yWriter and other such writer's editors have fixed tree depth (yWriter has chapters which can contain scenes; nothing more).
The real drawback in MOE - just like other similarly operating software like yWriter, Manuskript and Scrivener - is that you are looking your story from very, very narrow window. You craft it seeing just one scene at time. If you get ideas to other scenes while writing, you need to go to that scene, add it there, and get back.
Getting the touch to entire story, in MOE you need to export it to RTF, open it with OpenOffice and get back to editor to fix it. More modern structured editors probably have "draft preview" feature, where you can read your full draft without needing to export it.
Because of this, with MaweJS, not only I have already an export preview - I also eventually want it editable!
To overcome the real drawback of MOE, I was thinking, that hey, this is software, can't it just put all the scenes in one element, following each other, and edit them there? Just list them like they are listed in the index, and place a TextBox to edit them?
Meet Mawe (Mawe, Advanced Writer's Editor)
Mawe keeps the story internally in a tree just like MOE (and other structured editors), but it expands the tree to a text block to edit the story.
My first sketches really did literally what I said. I created a GTK Group and inside it, I created one TextArea for each scene. I added together the checkbox to include/exclude it from draft, and then another TextArea containing the scene description (synopsis).
I fought a long time with all sorts of issues due this approach. For example, just listing the scenes to a GTK Group does not take care about the scene grouping. Other hard issue was cursor movement: I wanted arrow and page keys to work, and spent lots of time to catch the keys and decide where to go.
It was doomed right from the beginning. I realized that I need to get the scenes for editing in one single TextArea. That really helps with cursor movement, but you still have problems with scene grouping. To solve that, I added special paragraphs, "scene breaks", so that when switching the TextArea buffer back to tree I would know where scenes start and end.
With this feature, you can edit your story just like in Notepad, Word or Googledocs. What makes Mawe different from those, is that it still has (in principle) the DnD-able index to reorganize your story just like MOE had.
With Mawe, I also ditched the idea of arbitrary deep trees. Mawe has two layers: parts and scenes (in principle; MawePY UI can handle just one part).
Why the group of scenes was named as "part"? yWriter uses "chapter" for that purpose. There are three reasons:
-
MOE used "group" as a name for scene groups. When developing Mawe, I didn't want to use the same name, so that I don't mess with the old implementation.
-
Nor MOE or Mawe really don't divide story to chapters and scenes. You can split scenes arbitrarily, just to move text around, and you really just gather scenes to a group to move them around. In MOE and Mawe, "chapter" is something you decide when exporting. You can choose, if you make the chapters from parts/groups or scenes to your draft. The main reason for this is that this really depends on the length of the story, length of scenes, length of groups, and number of both.
-
When coding Mawe, and when I named the current draft as body (following the HTML convention), it just sounded really cool to call the groups
body.partsin the code :D Yes, if you go to look the MaweJS code, there is stillstory.body.headandstory.body.parts:D
MawePY (Mawe written with Python/GTK) is really a great story editor! Honestly! It has all the basic features current MaweJS has and even more. Just few days ago MaweJS finally got folding feature, which was in MawePY years ago.
Its only drawback is that it was written with Python and GTK. As such, it can only be used "off-the-shelf" by Linux users. And even more importantly, while following the GTK development, I realized that GTK is not going to get big face-lifts anymore. Its main purpose is to make accessory software for Linux. I jealously looked the HTML, CSS and JavaScript front getting more and more features, which I could have lots of use in MawePY.
MawePY really has lots of unfinished features. For example, it does not have DnD-able index like MOE did. But the sole reason for those missing features is that I realized that going with Python/GTK won't take me anywhere. I just lost my motivation to go forward with that path.
At this point it is good to understand, that text and story editors like MOE, MawePY, Notepad and Manuskript, are not really programming challenges. They don't contain any really difficult algorithms inside. They are much more a User Interface challenges. The real challenge is to make the internal story representation as easy and fluent to edit as possible.
That is why I was looking especially improvements in the GUI side. I was already looking towards ElectronJS when I started sketching MawePY, but as I was much more familiar with Python and GTK, I decided to go that way. I really thought that GTK would get releases to take it somewhere on par with HTML, CSS and JavaScript. So many GTK features already borrowed the ideas from that front.
It became clear that that will never happen. If I would like to continue developing my Mawe, I would need to write it in some other platform.
I decided to go with ElectronJS, and here we now are.
Say hello to MaweJS