We need to add an sbt task to generate a favicon from the navbar_brand.png file.

The recent fix for #70 helps (thanks!) but there is still a problem with the machinery that attempts to guess which highlighter to use. Can we not support GFM style where you say

```scala

or java or whatever to mark code blocks and indicate desired highlighting? My particular issue is that I have blocks for which I don't want any highlighting at all (no syntax is indicated after the ```) and they end up looking very strange.

When the user clicks on "save as gist", a popup dialog should appear to let him select the following data:

• Description of the gist
• Filename for the included gist
• Checkbox to select if the gist is intended to be public or private.

Running ~makeMicrosite always recompiles the site (ending up in an infinite cycle), instead of waiting for a new written update in the docs. I would like ~makeMicrosite to behave the same way ~compile does, the task is only executed if I have modified a markdown or resource file.

We can use the repo tags/releases to allow publishing of multiple microsites, one for each version.
Not sure how much work would be involved in this since we would need to compile each one of those versions so potentially we would need isolated copies and move to those commits to generate the site while keeping the latest config active. Ideas on how to achieve this are welcome. We already have use cases where folks are requesting this feature typelevel/cats#1369 (comment)

We will change the structure in header menu.

The current layouts built through scala-tags should be divided into partial layouts (aka "includes"). These should be generated and used in the actual layouts (through the {% include %} directive in Jekyll).

Also, all configuration variables (i.e.: site name, repo url, etc...) should be added to the generated config.yml as custom variables, so users that incorporate external layouts have access to them.

Create another task publishMicrosite which concatenates makeMicrosite+ andghpagesPushSite` (from sbt-ghpages) that requires:

git.remoteRepo := "[email protected]:{your username}/{your project}.git"

For that we need include ghpages.settings.

We need more images in our own docs showing for example results after customizations. Now that most of our microsites are themeable we can have a few examples with nice combinations of colors that folks can use as a starting point for their own project sites.

Might be nice to gen a link to gitter up in the header since it's pretty standard these days.

Ref: https://github.com/codemirror/CodeMirror/tree/master/mode/clike

Currently it seems that sbt-microsites is built only from master branch. There should be a mechanism to support multiple versions that can be selected by a dropdown or similar navigation element. Versions could be generated from git tags or from configuration file which maps versions to git branches or commits.

The font size of the landing page in sbt-microsites is a little bit small. Is it possible to increase it for a better UX in high-resolution screens?

We need designs for the decoration and the modal window that the Kazari plugin uses. The needed elements would be:

• For the decoration around the snippets of code:
  • Button to run the snippets of code
  • Button that shows the "edit" modal window.
  • Area to show evaluation results (i.e.: an error or "evaluation OK" or whatever).
• "Edit" modal window:
  • Design of the modal window itself, appearing over the screen taking about a 90% of it (over a translucent black background).
  • Button to run the code.
  • Button to login to GitHub (if needed), or to save the edited code to a Gist.
  • Button to close the modal window and go back to the main screen.
  • Area to show evaluation results (i.e.: an error or "evaluation OK" or whatever).
  • IMPORTANT: design for the edit textarea IS NOT needed. We're using a plugin called CodeMirror that handles all that, and allows for customizable themes.

Documentation on how Kazari works and how to use it should be added to the project.

We will fix some bugs about styles for microsites

We should remove the icons from the column footer in the microsite.

Hey, great project over here.

Planning to use this in a project I will release soon. I have one nitpick, though: when I go into the sbt-microsites documentation website there's an ugly transition of the left menu. At first, it appears in the middle of the screen and then you see it move towards the left.

This behaviour is reproducible when browsing through the sbt-microsites docs website, and even in the cats repo. It happens both when going through links and at load time. Check, for instance, this. It may be caused by a delayed javascript callback.

It would be nice if I could say something like

micrositeVariables := Map(
  "version" -> version.value,
  "org"     -> organization.value
)

or something like this, and push them forward into Jekyll so that I could say {{microsite.version}} in my markdown … keeping versions correct in doc is always a problem. A good default map might include version, name, description, and org.

You may have something like this in mind already. If not maybe I can hack it up? wdyt?

Kazari should use the evaluator client to make requests and handle responses. Work to make the evaluator client compatible with Scala-JS is being done as part of scala-exercises/evaluator#32.

Last stage to have Kazari ready for use. We need:

• Rework project structure to make Kazari not a plugin but just a Scala JS project to generate the actual plugin.
• Publishing Kazari should include the resulting script (marked with a version number) in the repository.
• Sbt-Microsites should generate the needed html meta tags and include the JS calls to Kazari to active the plugin. Settings will be available for users to configure Kazari from the sbt-side.
• Sbt-Microsites should retrieve the JS code from the aforementioned script uploaded to GitHub.

We should add unit tests for the UI functionalities.

Users should be able to edit pages directly by providing links to either Github or other VCS as configured via settings to go to actual sources on each one of the generated pages.

This will allow lib maintainers to get easy low hanging fruit style contribs from their users to increase lib engagement.

Existing generated pages don't link to anchor links generated from # blocks.

When visiting a microsite, often the styles take a long time to load so you see the page without style for a second or so before the styled version loads.

For me, this can be seen on both these sites:
https://47deg.github.io/scalacheck-datetime/
https://47deg.github.io/fetch/

Add documentation about the highlightTheme in the Customizing Section, since it's important when you are defining the style of your microsite.

We are using this plugin to generate its microsite. At this moment, we are using the default styles, images and resources provided for the plugin. This is the result:

https://47deg.github.io/sbt-microsites/

We should:

• Create better default styles and resources for the plugin, locating them at https://github.com/47deg/sbt-microsites/tree/master/src/main/resources . Color palette by default: https://github.com/47deg/sbt-microsites/blob/master/src/main/scala/microsites/MicrositesPlugin.scala#L72
• Create the resources for the sbt-microsites microsite. We can put everything under this path https://github.com/47deg/sbt-microsites/tree/master/docs/src/main/resources/microsite

Both previous tasks might be the same if you consider it. @israelperezglez ^^

Image resources with extensions different than PNG (i.e.: jpg, jpeg, ico, webm, gif...) are not copied from the jekyll folder to the final site processed folder. This seems to be a problem with the microsite command in the makeMicrosite sequence of commands.

Currently generated microsites do not support favicons. We need to enable this functionality based on the default naming convention along with an override via sbt setting

Scala Code not always is being well-displayed. Rob Norris has provided useful feedback around this issue. Here a couple of examples with different hightlight themes (default and color-brewer):

As you can see, the comment starting with // guessing loop with … is not well-interpreted since the keyword with is being highlihted, and it shouldn't.

CC @tpolecat

Some design twinkering is needed to launch the first version of Kazari:

• Update CSS so the button bar of Kazari correctly attaches itself to the code snippets divs (without any padding as now) (see attachment).
• Avoid Kazari button bar to change paragraphs coming after it (see attachment).
• Also improve Kazari button bar to hide the overlapping border lines at the bottom of the bar.
• The error/success bar should have the corner radius applied only to the bottom corners, as well as being closer to the button bar.
• Take current highlight.js color scheme and apply it to the Kazari button bar.
• Use the same color scheme for the CodeMirror modal editor if possible.

It would be nice, for certain environments, to be able to configure the microsite so that the View On links could point to a different URL. This assumes the project is hosted on Github but maybe you would like to to point to something like: http://myInternalServer/git/projects/user/projectname.

A few instances:

• Github header link
• View on Github jumbotron button
• View on Github footer link

We could use this plugin to achieve this new functionality https://sidecar.gitter.im/, with a couple of settings like:

• gitter-sidecar: A boolean to set this feature (enabled by default).
• gitter-channel: To add a link in the top nav.

Documentation needs a complete review regarding content and language.

Markdown tables are css formatted without paddings and a consistent style.
Example (note that Platform commands and Description are together):

Many Scala projects are already using Microsites we should add a table with screenshots to the README with their permission so other devs considering it get proper references of usages in the wild.

Let's add a section in the README where scala libs using sbt-microsites can get listed so newcomers considering using it have some reference implementations.

Hey all,

I'm looking to include a mathjax js import in the microsite for Algebird (twitter.github.io/algebird), but it doesn't look like I can inject this into a page template at the moment. Am I missing something? If not, would it be possible to create a new key for the sbt plugin that accepts a list of JS libraries to load?

Thanks!

I found the code block which creates the Jekyll configuration. Would it be possible to take one from, let's say, src/main/resources/microsite/ if it exists?

The reason I looked at this is because of slight rendering problems in typelevel/scala#117 which I believe come from a missing Kramdown configuration option (input: GFM).

If I try to load the sbt-microsites plugin on a git worktree in a different dir than my original clone, I get an error like

org.eclipse.jgit.errors.NoWorkTreeException: Bare Repository has neither a working tree, nor an index
	at org.eclipse.jgit.lib.Repository.getWorkTree(Repository.java:1245)
	at org.eclipse.jgit.treewalk.FileTreeIterator.<init>(FileTreeIterator.java:88)
	at org.eclipse.jgit.api.StatusCommand.call(StatusCommand.java:139)
	at com.typesafe.sbt.git.JGit.hasUncommittedChanges(JGit.scala:84)
	at com.typesafe.sbt.SbtGit$$anonfun$buildSettings$8$$anonfun$apply$8.apply(SbtGit.scala:116)
	at com.typesafe.sbt.SbtGit$$anonfun$buildSettings$8$$anonfun$apply$8.apply(SbtGit.scala:116)
	at com.typesafe.sbt.git.DefaultReadableGit.withGit(ReadableGit.scala:35)
	at com.typesafe.sbt.SbtGit$$anonfun$buildSettings$8.apply(SbtGit.scala:116)
	at com.typesafe.sbt.SbtGit$$anonfun$buildSettings$8.apply(SbtGit.scala:116)
	at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
	at sbt.EvaluateSettings$MixedNode.evaluate0(INode.scala:175)
	at sbt.EvaluateSettings$INode.evaluate(INode.scala:135)
	at sbt.EvaluateSettings$$anonfun$sbt$EvaluateSettings$$submitEvaluate$1.apply$mcV$sp(INode.scala:69)
	at sbt.EvaluateSettings.sbt$EvaluateSettings$$run0(INode.scala:78)
	at sbt.EvaluateSettings$$anon$3.run(INode.scala:74)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

I'm finding that I want my repo's README and the index page for my microsite to be the same modulo front matter. This would be easy to hack up … would this be useful or am I just being weird?

The default styling doesn't paint borders around tables, which makes them slightly strange looking.

What I would really like I think is an option that makes formatting exactly like what GH does, if that's an easy thing to do (no idea).

We should consider integrating https://github.com/sbt/sbt-release plugin, in order to facilitate the release process.

On the sbt-microsites microsite it has a reference in the head to the .DS_Store file that should not be there.

CodeMirror has some facilities to force the scroll to jump to certain line numbers. Look if it's possible to go directly to the first line of the snippet where the user clicked on edit, as that's probably his main point of focus when clicking there.

Needed for library adoption we should include footer text and links or badge "Built with github.com/47deg/org" or similar

Some issues in the remote evaluator surfaced while developing the Kazari plugin. This ticket covers the remaining work to make Kazari available once the remote evaluator is ready to support it.

Currently the size of the resulting plugin after executing fullOptJS and merging it with the JS dependencies script is almost 1.5 MB. As soon as the plugin is in a stable state we should look into ways of reducing its size (i.e.: searching for an alternative to using Futures - as including ExecutionContexts seems to beef up the script by ~500KB) and maybe process the script with further optimizations/minimization processes after it's already generated as part of the fullOptGenerate task.