search

tweecode / twine

UI for creating hypertext stories
http://twinery.org
657 stars 97 forks source link

Ability for Header Authors to add functionality to application #107

Closed greyelf closed 10 years ago

greyelf commented 10 years ago

Currently there is a situation where some Story Authors are choosing not to upgrade to the latest official Twine 1.4.1, and are instead using a modified version of Twine 1.3.6 alpha due to it offering better supporting their Story Format header of choice. (SugarCube)

Some of features in the modified version could be added to the office version but others are specific to the SugarCube header.

Because the different Headers (Jonah, Sugarcane, SugarCube, etc) support different features/default macros, there appears to be a need for the ability to allow the Header Authors to influence/change how the Twine GUI works depending on the Header (Story Format) selected.

This would reduce the amount of hard-wiring required to support a feature that is not common to all Headers.

Contained within this branch is a very basic example of a Header class system, which allows a Header Author to supply a Python class file along with their "header.html" file, this class could contain code that changes the application.

The basic example allows Header Authors to do the following:

  1. Indicate what name to show in the Story Format list.
  2. Indicate which external files to embed within the generated output. eg. jonah/code.js if Jonah; sugarcane/code.js if Sugarcane
  3. Allow for different endtag formats. eg. both endtag_name and /tag_name formats.
  4. Indicate which macros support nesting. eg. IF and SILENT by default; other headers may include others.

Other functionality like, which macros also behave as links and need highlighting, can be added as needed.

greyelf commented 10 years ago

I asked about this in Issue: 102 - Determination of required file paths for platform Darwin but received no feedback. The locations that files are sourced from within the OSX version of Twine is inconsistent:

Location of script files: scriptPath = os.path.realpath(os.path.dirname(sys.argv[0])) NOTE: This value is accessed by the rest of the application via the app.getPath() method.

Location of header directories: NOTE: The Header file itself is within a sub-directory named based on the StoryFormat

Location of Footer files: app.getPath() + os.sep + 'targets' + os.sep NOTE: The Footer file itself is within a sub-directory named based on the StoryFormat

Location of Engine files: app.getPath() + os.sep + 'targets' + os.sep

Location of the App's Icon: 'icons' + os.sep + 'app.ico' NOTE: Found based on the current working directory of the Application, may be different to scriptPath icons directory.

Location of other Icons: app.getPath() + os.sep + 'icons' + os.sep

So as you can see:

  1. The order of determining the header file location is different between StoryFrame and Tiddywiki
  2. The footer file (if it exists) is always in relationship to the scriptPath
  3. Engine code is always in relationship to the scriptPath
  4. The App's icon is vague in its location

My assumptions (which could be wrong due to no feedback):

  1. OSX header files can be sources from one of two locations, with one location overriding the other. eg. either all at one location or all at the other.
  2. A StoryFormat's Footer file if it exists should be at the same location as the Header file

Either way all this is contained within two methods within app.py: determinePaths() and loadTargetHeaders(), so it should be simple to change