Allow override of theme directory

[jmclain]

Rick,

How would you feel about allowing the theme directory location being overridden in the mm config file?

A little searching shows that the theme directory is referenced in three locations:

• AppModel.cs where the theme sub-directories are iterated to get theme names.
• MarkdownDocument.cs where the theme is loaded for processing.
• MainWindow.xaml.cs where the theme directory is opened via the ui.

It would not take much work to put the override in the mm configuration file and reference it where required, using the default theme locations as a fall back. Currently "PreviewThemes" is referenced in 4 lines of code.

My current use case for this is I want to share custom themes between the release version of mm and a debug version of mm. Additionally it would be nice to keep custom themes in a common location to keep them under source control.

If you think it's worthwhile, or at least an acceptable modification I'll volunteer to make the changes and submit.

Thanks,

Joe McLain

[jmclain]

Okay, I've jumped the gun and gone ahead and started this, should be done later in the day (California time). One change from my initial thought is rather than replacing the theme directory we'll have an alternate directory where more themes can be located; if a theme has the same name as one in the default theme directory it will override it.

Note: I'm isolating all this in a ThemesLoader class to keep the actual hacking of mm code to a minimum.

[RickStrahl]

I'm not really sure I want to integrate this as just this makes things more confusing for people to create custom themes. It seems of dubious value to me. What's wrong with just pushing themes with version numbers or specific naming into the preview folder?

[jmclain]

What's wrong with just pushing themes with version numbers or specific naming into the preview folder?

It's buried in an application subdirectory inside of AppData->Local. No matter how you document it that is not a good location for data that is manipulated by a user, even an advanced user. In addition it is unlikely to be a path that gets backed up, better to locate it where Dropbox or OneDrive can pick it up.

If you do not allow a user to specify a specific directory in the configuration file, then choose a specific location in Documents (or whatever microsoft's preferred document location is now). Personally I prefer a user selected location (or both).

How about Documents->Westwind->Markdown Monster->Themes to be documented for the average user, AND a "secret" ExtendedThemesFolder in the configuration file for more advanced users?

[jmclain]

I've implemented it. Here is a link to a gist with the source of the loader.

ThemesLoader

Let me know what you think.

Thanks,

Joe McLain

[jmclain]

I've worked with this for several days now and using an external theme directory seems to work well (once I figured out a template needs a "mark of the web" to keep the web browser control happy).

[jmclain]

This is working well for me. I'm working on getting a pull request ready as well as several example themes, and notes on what it takes to make it all work. That should allow you to make a judgement on whether it's a good fit for MM.

[RickStrahl]

Joe,

This seems overly complicated to me and frankly makes it more confusing for people who want to customize because now you're going to have to keep script files in sync. MM uses preview.js to handle a few custom scenarios like hash scrolling and preview syncing that have to be present so no matter what that script has to be linked each time. So now you either have to copy it or hardcode a reference link into templates.

I think in order for this to be managable for users themes need to be stored in a single place. I'm open to perhaps moving that to %appdata% because effectively this is the 'user' configuration location where all other user customized data lives and can be backed up and moved (and stored on DropBox for sharing), but there are a few issues with that since now this would have to be also handled post install for portable installs.

[jmclain]

Hey Rick,

I understand your concern but disagree. The code is written and I'm working on a few examples which will allow you to look at a working system; if you don't like it so be it, it's your project and if you feel you need to reject my idea then that's fine with me. In case of rejection I will propose another hook in mm that would allow this to be done via an addin.

I'd also like to note that previews will work without preview.js being loaded, albeit without the special features you mentioned. As to keeping preview.js, font awesome, and the colorizer code up to date; since mm lives in a fixed location the most recent versions can be referenced without issue.

I don't see this feature as being used by the "average" user, but by users who want to integrate mm with static site building, or document generation. My usage falls into both those categories.

Thanks,

Joe McLai

[RickStrahl]

Jim, I'm closing this since there is no further actionable task on this. Maybe lets reveiw this in a bit - you said you were thinking of some other way of doing this that might be more generic.