New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] revamp docs #119

Merged
merged 27 commits into from Nov 9, 2017

Conversation

Projects
None yet
3 participants
@mathieudutour
Contributor

mathieudutour commented Oct 10, 2017

Fix #9, Fix #15, Fix #32, Fix #72, Fix #109

@bomberstudios

Added some comments

Show outdated Hide outdated pages/index.md Outdated
Show outdated Hide outdated pages/index.md Outdated
Show outdated Hide outdated pages/index.md Outdated
## Sections
Lots of great community ideas for Sketch features are better implemented as plugins rather than as part of the core product. This way users can easily pick and choose the functionality they want, by installing the right set of plugins. The Sketch team tracks possible plugin as GitHub issues on the [plugin-request repository](https://github.com/sketchplugins/plugin-requests/issues). If you're looking for a great plugin to build, have a look at the issues.

This comment has been minimized.

@bomberstudios

bomberstudios Oct 23, 2017

Contributor

Not sure what we're trying to say here, but we're definitely not keeping track of requests on that repo. What is the message we want to send?

@bomberstudios

bomberstudios Oct 23, 2017

Contributor

Not sure what we're trying to say here, but we're definitely not keeping track of requests on that repo. What is the message we want to send?

This comment has been minimized.

@mathieudutour

mathieudutour Oct 23, 2017

Contributor

That's what is writing on the repo tho. I wanted to make sure people don't come in this repo with plugin requests. See #112

I think it could be nice to have a place to have keep requests so that devs looking for side-projects can have a place to turn to. (could be useful for CS as well).

I don't really care about where or what that place should be but we need to make clearer where discussion should go:

  • bug report about API -> API repo
  • typo about the docs -> this repo
  • questions -> sketchplugins.com
  • plugin request -> another place

The other reason I want to separate it is that sketchplugins.com is getting some post about people with job ads, it would be a shame if it turns to a job board :/

@mathieudutour

mathieudutour Oct 23, 2017

Contributor

That's what is writing on the repo tho. I wanted to make sure people don't come in this repo with plugin requests. See #112

I think it could be nice to have a place to have keep requests so that devs looking for side-projects can have a place to turn to. (could be useful for CS as well).

I don't really care about where or what that place should be but we need to make clearer where discussion should go:

  • bug report about API -> API repo
  • typo about the docs -> this repo
  • questions -> sketchplugins.com
  • plugin request -> another place

The other reason I want to separate it is that sketchplugins.com is getting some post about people with job ads, it would be a shame if it turns to a job board :/

Show outdated Hide outdated pages/index.md Outdated
Show outdated Hide outdated _layouts/sidebar-page.html Outdated
Show outdated Hide outdated _guides/publishing.md Outdated
@@ -1,8 +1,8 @@
---
title: Scripting Preferences
title: Dev Environment

This comment has been minimized.

@bomberstudios

bomberstudios Oct 23, 2017

Contributor

I'm not entirely in love with the title change, but I understand where this is coming from.

Do we have alternatives for this title?

@bomberstudios

bomberstudios Oct 23, 2017

Contributor

I'm not entirely in love with the title change, but I understand where this is coming from.

Do we have alternatives for this title?

This comment has been minimized.

@mathieudutour

mathieudutour Oct 23, 2017

Contributor

That's because I want to expand this section with some skpm explanation (hence, not only "Scripting Preferences" but more "Development Environment"

@mathieudutour

mathieudutour Oct 23, 2017

Contributor

That's because I want to expand this section with some skpm explanation (hence, not only "Scripting Preferences" but more "Development Environment"

This comment has been minimized.

@mathieudutour

mathieudutour Oct 23, 2017

Contributor

or "Dev Setup", or "Dev tools"

@mathieudutour

mathieudutour Oct 23, 2017

Contributor

or "Dev Setup", or "Dev tools"

This comment has been minimized.

@bomberstudios

bomberstudios Oct 24, 2017

Contributor

"Development Environment" sounds good : )

@bomberstudios

bomberstudios Oct 24, 2017

Contributor

"Development Environment" sounds good : )

This comment has been minimized.

@mathieudutour

mathieudutour Oct 24, 2017

Contributor

Yeah but it doesn’t fit in the side bar haha

@mathieudutour

mathieudutour Oct 24, 2017

Contributor

Yeah but it doesn’t fit in the side bar haha

We're telling our plugin that we want to run the `onOpenDocument` function when a document is open, so let's add that in `my-action-listener.js`:
```js
export function onOpenDocument (context) {

This comment has been minimized.

@bomberstudios

bomberstudios Oct 23, 2017

Contributor

This assumes we're using skpm, maybe we can simplify this example, for the sake of clarity?

@bomberstudios

bomberstudios Oct 23, 2017

Contributor

This assumes we're using skpm, maybe we can simplify this example, for the sake of clarity?

This comment has been minimized.

@mathieudutour

mathieudutour Oct 23, 2017

Contributor

That's exactly what we need to decide. Either we decide to go full-on skpm or not but if we don't, nothing will be clear because var onRun = function (context) {} is really unclear.

I think that people who do not want to use skpm can understand it by themselves. We just want to make sure that people getting into it can understand, which means picking the easiest way.

There should be another document, probably living in the skpm documentation, explaining what it does behind the scene so that people can do it by themselves if they choose to and explaining all the weird CocoaScript quirks but that's definitively not a "getting started" document.

@mathieudutour

mathieudutour Oct 23, 2017

Contributor

That's exactly what we need to decide. Either we decide to go full-on skpm or not but if we don't, nothing will be clear because var onRun = function (context) {} is really unclear.

I think that people who do not want to use skpm can understand it by themselves. We just want to make sure that people getting into it can understand, which means picking the easiest way.

There should be another document, probably living in the skpm documentation, explaining what it does behind the scene so that people can do it by themselves if they choose to and explaining all the weird CocoaScript quirks but that's definitively not a "getting started" document.

This comment has been minimized.

@bomberstudios

bomberstudios Oct 31, 2017

Contributor

Ok, let's go with this then : )

@bomberstudios

bomberstudios Oct 31, 2017

Contributor

Ok, let's go with this then : )

Show outdated Hide outdated _guides/first-plugin.md Outdated
@intemperie

This comment has been minimized.

Show comment
Hide comment
@intemperie

intemperie Nov 3, 2017

Contributor

I slightly tweaked the code styles, so we don't have those issues you mentioned before. I hope you like it :)

Contributor

intemperie commented Nov 3, 2017

I slightly tweaked the code styles, so we don't have those issues you mentioned before. I hope you like it :)

@bomberstudios bomberstudios merged commit b8e6fbf into gh-pages Nov 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment