mirror of
https://github.com/laurent22/joplin.git
synced 2024-11-27 08:21:03 +02:00
Doc: Fixing typos (#5644)
This commit is contained in:
Andreas Deininger
GitHub
parent
f7a18bac2a
commit
6393996694
@ -17,9 +17,9 @@ Then, in the directory where you plan to develop the plugin, run:
|
||||
|
||||
yo joplin
|
||||
|
||||
This will generate the basic scafolding of the plugin. At the root of it, there are a number of configuration files which you normally won't need to change. Then the `src/` directory will contain your code. By default, the project uses TypeScript, but you are free to use plain JavaScript too - eventually the project is compiled to plain JS in any case.
|
||||
This will generate the basic scaffolding of the plugin. At the root of it, there are a number of configuration files which you normally won't need to change. Then the `src/` directory will contain your code. By default, the project uses TypeScript, but you are free to use plain JavaScript too - eventually the project is compiled to plain JS in any case.
|
||||
|
||||
The `src/` directory also contains a [manifest.json](https://github.com/laurent22/joplin/blob/dev/readme/api/references/plugin_manifest.md) file, which contains the various information about the plugin that was set in the inital generation of the scaffolding, such as its name, homepage URL, etc. You can edit this at any time, but editing it after it has been published may cause users to have to download it again.
|
||||
The `src/` directory also contains a [manifest.json](https://github.com/laurent22/joplin/blob/dev/readme/api/references/plugin_manifest.md) file, which contains the various information about the plugin that was set in the initial generation of the scaffolding, such as its name, homepage URL, etc. You can edit this at any time, but editing it after it has been published may cause users to have to download it again.
|
||||
|
||||
## Setup Source Control
|
||||
|
||||
|
||||
@ -81,7 +81,7 @@ Then you will resume fetching the results using this query:
|
||||
|
||||
curl http://localhost:41184/notes?order_by=updated_time&order_dir=ASC&limit=10&page=2
|
||||
|
||||
Eventually you will get some results that do not contain an "has_more" paramater, at which point you will have retrieved all the results
|
||||
Eventually you will get some results that do not contain an "has_more" parameter, at which point you will have retrieved all the results
|
||||
|
||||
As an example the pseudo-code below could be used to fetch all the notes:
|
||||
|
||||
@ -126,7 +126,7 @@ To retrieve all the tags that start with `project-`: **GET /search?query=project
|
||||
|
||||
# Item type IDs
|
||||
|
||||
Item type IDs might be refered to in certain object you will retrieve from the API. This is the correspondance between name and ID:
|
||||
Item type IDs might be referred to in certain object you will retrieve from the API. This is the correspondence between name and ID:
|
||||
|
||||
Name | Value
|
||||
---- | -----
|
||||
|
||||
@ -31,7 +31,7 @@ To do so, first enable developer mode in [chrome://extensions/](chrome://extensi
|
||||
## In Firefox
|
||||
|
||||
- Open [about:debugging](about:debugging) in Firefox.
|
||||
- Make sure the checkox "Enable add-on debugging" is ticked.
|
||||
- Make sure the checkbox "Enable add-on debugging" is ticked.
|
||||
- Scroll down to the Joplin Web Clipper extension.
|
||||
- Click on "Debugging" - that should open a new console window.
|
||||
|
||||
|
||||
@ -24,4 +24,4 @@ Tap on the **burger icon ≡** in the top left corner, and select **Configuratio
|
||||
|
||||
## CLI
|
||||
|
||||
Type `:help config` for information on how to set config values nad for the complete list of available options.
|
||||
Type `:help config` for information on how to set config values and for the complete list of available options.
|
||||
|
||||
@ -8,7 +8,7 @@ Most of all, your donation will make it possible to keep up the current developm
|
||||
|
||||
Platform | Link
|
||||
--- | ---
|
||||
Paypal | [](https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=E8JMYD2LQ8MMA&lc=GB&item_name=Joplin+Development¤cy_code=EUR&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted) |
|
||||
PayPal | [](https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=E8JMYD2LQ8MMA&lc=GB&item_name=Joplin+Development¤cy_code=EUR&bn=PP%2dDonationsBF%3abtn_donateCC_LG%2egif%3aNonHosted) |
|
||||
GitHub Sponsor | [](https://github.com/sponsors/laurent22/)
|
||||
Patreon | [](https://www.patreon.com/joplin)
|
||||
Bank Transfer | **IBAN:** FR76 4061 8803 5200 0400 7415 938<br>**BIC/SWIFT:** BOUS FRPP XXX
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# 1.Idea - Create documenation hub
|
||||
# 1.Idea - Create documentation hub
|
||||
- Make a screening of available options of how apps to be utilized to organize documentation better and simplified access to information.
|
||||
You can start with:
|
||||
- [Read the Docs](https://readthedocs.org/)
|
||||
|
||||
@ -4,27 +4,27 @@
|
||||
Joplin has a young but well proven history. It all started by single idea but is rising more and more commitment as well as demands.
|
||||
|
||||
Joplin is about to make another big step to answers these demands by being an organization at Google Summer of Code 2020.
|
||||
During the young history of the GSoC campaign it was noticed that it would be a greate help if documenation is centralized and making it a continuous read. The current documentation tells when to do what and how clearly. In addition, the source code of Joplin is clean and well strucutred, so it is easy to understand.
|
||||
Nevertheless, there are additional and essential information scattered around on the Forum and GitHub which rely on an active community, so that are being shared with them who need them. It can be said that this happens very well but it is aggreed that this situation has to be improved to free resources for working on the source coden and lower entry barriers for new contributors.
|
||||
During the young history of the GSoC campaign it was noticed that it would be a great help if documentation is centralized and making it a continuous read. The current documentation tells when to do what and how clearly. In addition, the source code of Joplin is clean and well structured, so it is easy to understand.
|
||||
Nevertheless, there are additional and essential information scattered around on the Forum and GitHub which rely on an active community, so that are being shared with them who need them. It can be said that this happens very well but it is agreed that this situation has to be improved to free resources for working on the source code and lower entry barriers for new contributors.
|
||||
|
||||
For these reasons, all students and Joplin users and developers are welcome to participate in the hopefully first year Summer of Docs program with Joplin. Here's how.
|
||||
|
||||
Mentors, administrators and students: read [Season of Docs](https://developers.google.com/season-of-docs) occasionally. Also read the [Season of Docs FAQ](https://developers.google.com/season-of-docs/docs/faq).
|
||||
**Most IMPORTANT, read this page carefully, line by line. We don't want to quote pharagraphs from this page answering question in the forum.
|
||||
Moreover, watch/subscribe the topic [GSoC 2020 live blog](https://discourse.joplinapp.org/t/gsoc-2020-live-blog/6219) as this page here contains rather static content whereas the mentioned topic is updated much more freuqently.**
|
||||
**Most IMPORTANT, read this page carefully, line by line. We don't want to quote paragraphs from this page answering question in the forum.
|
||||
Moreover, watch/subscribe the topic [GSoC 2020 live blog](https://discourse.joplinapp.org/t/gsoc-2020-live-blog/6219) as this page here contains rather static content whereas the mentioned topic is updated much more frequently.**
|
||||
|
||||
All participants will need a Google account in order to join the program. So, save time and create one now. In addition, all participants need to join the [Joplin Forum](https://discourse.joplinapp.org).
|
||||
|
||||
---
|
||||
|
||||
# Instructions for students
|
||||
Students wishing to participate in Season of Docs must realize, that this is a important professional opportunity. You will be required to produce applicable and readable documenation for Joplin in 3 months. Your mentors, will dedicate a portion of their time to mentoring you. Therefore, we seek candidates who are committed to helping Joplin and its community long-term and are willing to both do quality work, and be proactive in communicating with your mentor(s).
|
||||
Students wishing to participate in Season of Docs must realize, that this is a important professional opportunity. You will be required to produce applicable and readable documentation for Joplin in 3 months. Your mentors, will dedicate a portion of their time to mentoring you. Therefore, we seek candidates who are committed to helping Joplin and its community long-term and are willing to both do quality work, and be proactive in communicating with your mentor(s).
|
||||
|
||||
You don't have to be a proven technical writter - in fact, this whole program is meant to facilitate to support Joplin and other Open Source communities by techinal writters. However, experience in technical writting and/or coding experience is welcome.
|
||||
You don't have to be a proven technical writer - in fact, this whole program is meant to facilitate to support Joplin and other Open Source communities by technical writers. However, experience in technical writing and/or coding experience is welcome.
|
||||
|
||||
In general it can be said, that question shall be asked early and clearly, given everyone the possibility to understand why you want to have this question answered and how it helps to achieve the project's goal.
|
||||
|
||||
Before you can be accepted as a student we expect you to communicate very activily with the community and contributors and summerize what could help them most and link that work on your proposal.
|
||||
Before you can be accepted as a student we expect you to communicate very actively with the community and contributors and summarize what could help them most and link that work on your proposal.
|
||||
If your idea is related to codebase documentation it is welcome that you fix little bugs. You may browse the GitHub Issues to find some simple tasks. See the good first issues which are a good way to make yourself familiar with the code base.
|
||||
|
||||
You should start learning the components that you plan on working on before the start date. Support can be found in the forum and on our dedicated discourse channel.
|
||||
@ -42,7 +42,7 @@ Students who neglect active communication will be failed!
|
||||
|
||||
First of all, please read the above referenced resources and the [GSoC FAQ](https://developers.google.com/open-source/gsoc/faq). Pay special attention to the **Eligibility** section of the FAQ.
|
||||
|
||||
We stronly recomment to follow the recommented steps, see next section, closley. It is slightly differs from the steps given for the closed GSoC application period.
|
||||
We strongly recommend to follow the recommended steps, see next section, closely. It is slightly differs from the steps given for the closed GSoC application period.
|
||||
The procedure reflects some of the lessons learnt in the GSOC 2020 campaign, so you may compare the recommended steps and scan the change history of the [GSoC 2020 live blog](https://discourse.joplinapp.org/t/gsoc-2020-live-blog/6219).
|
||||
|
||||
## Recommended steps
|
||||
@ -52,10 +52,10 @@ The procedure reflects some of the lessons learnt in the GSOC 2020 campaign, so
|
||||
3. Take a look at the [list of ideas](https://joplinapp.org/gsod2020/ideas/). You can have you own idea added by posting it in the [Features category](https://discourse.joplinapp.org/c/features)
|
||||
4. Come up with project that you're interested in and discuss it in [Features category](https://discourse.joplinapp.org/c/features) if a corresponding does not already exist.
|
||||
5. Write a first draft and get someone to review it
|
||||
1. Remember: you must link to work such as commits in your proposal. A private place will be created wihtinn the forum for that purposes.
|
||||
1. If you want to add functionality to the codebase or documenation, have it approved [Features category](https://discourse.joplinapp.org/c/features)
|
||||
1. Remember: you must link to work such as commits in your proposal. A private place will be created within the forum for that purposes.
|
||||
1. If you want to add functionality to the codebase or documentation, have it approved [Features category](https://discourse.joplinapp.org/c/features)
|
||||
1. **IMPORTANT**: If you contribute to the codebase do only one contribution at a time and wait until it is approved.
|
||||
6. Submit your proposal to the mentors writting a private message at `@mentors` in the [Joplin Forum](https://discourse.joplinapp.org) and wait for their feedback
|
||||
6. Submit your proposal to the mentors writing a private message at `@mentors` in the [Joplin Forum](https://discourse.joplinapp.org) and wait for their feedback
|
||||
8. Submit proposal using [Google's web interface](https://summerofcode.withgoogle.com/) well ahead of the deadline. You can update it at anytime, even the final proposal.
|
||||
9. Submit proof of enrolment well ahead of the deadline
|
||||
|
||||
|
||||
@ -4,6 +4,6 @@ Pre-releases are available for the desktop application. They are pretty much lik
|
||||
|
||||
You can help the development of Joplin by choosing to receive these early releases when updating the application. If you find any bug or other issue, please report it on [GitHub](https://github.com/laurent22/joplin/issues) or the forum (if you do not have a GitHub account). Any bug report during the pre-release phase is invaluable to us, as it allows making the app more reliable before making it available to more people.
|
||||
|
||||
In general it is safe to use these pre-releases as they do not include any experimental or unstable features. Hundreds of users run them without any issue. Morever even if you do find an issue, you can report it and it is usually fixed very quickly as these bugs are given the highest priority.
|
||||
In general it is safe to use these pre-releases as they do not include any experimental or unstable features. Hundreds of users run them without any issue. Moreover even if you do find an issue, you can report it and it is usually fixed very quickly as these bugs are given the highest priority.
|
||||
|
||||
To have access to these pre-releases, simply go to [Configuration > General](https://github.com/laurent22/joplin/blob/dev/readme/config_screen.md) and tick the box "**Get pre-releases when checking for updates**".
|
||||
|
||||
@ -12,7 +12,7 @@ The user can copy the token in the Clipper configuration page and provide it dir
|
||||
|
||||
The token can also be requested programmatically, as is done for the web clipper extension. It works as below:
|
||||
|
||||
- The client calls `POST /auth`. The server responds with `{ auth_token: "AUTH_TOKEN" }`. This `auth_token` is different from the regular token - it is just used to authentify the client.
|
||||
- The client calls `POST /auth`. The server responds with `{ auth_token: "AUTH_TOKEN" }`. This `auth_token` is different from the regular token - it is just used to authenticate the client.
|
||||
|
||||
- The application displays a message asking the user to Accept or Reject the access request.
|
||||
|
||||
|
||||
@ -64,13 +64,13 @@ Enabling/disabling E2EE while two clients are in sync might have an unintuitive
|
||||
|
||||
- Although messy, Joplin supports having some clients send encrypted items and others unencrypted ones. The situation gets resolved once all the clients have the same E2EE settings.
|
||||
|
||||
- Currently, there is no way to delete encryption keys if you do not need them anymore or if you disabled the encryption completely. You will get a persistant notification to provide a Master Key password on a new device, even if encryption is disabled. Entering the Master Key(s) password and still having the encryption disabled will get rid of the notification. See [Delete E2EE Master Keys](https://discourse.joplinapp.org/t/delete-e2ee-master-keys/906) for more info.
|
||||
- Currently, there is no way to delete encryption keys if you do not need them anymore or if you disabled the encryption completely. You will get a persistent notification to provide a Master Key password on a new device, even if encryption is disabled. Entering the Master Key(s) password and still having the encryption disabled will get rid of the notification. See [Delete E2EE Master Keys](https://discourse.joplinapp.org/t/delete-e2ee-master-keys/906) for more info.
|
||||
|
||||
## Types of keys
|
||||
|
||||
There are two types of key:
|
||||
|
||||
- **Data keys**, which are used to encrypt Joplin items, such as notes, notebooks, tags, etc. when E2EE is ernabled. A data key is generated when the user enables E2EE. Data keys are also dynamically generated when a user shares a notebook with another user. In this case, we create a separate key, so that the recipient can only decrypt this specific notebook.
|
||||
- **Data keys**, which are used to encrypt Joplin items, such as notes, notebooks, tags, etc. when E2EE is enabled. A data key is generated when the user enables E2EE. Data keys are also dynamically generated when a user shares a notebook with another user. In this case, we create a separate key, so that the recipient can only decrypt this specific notebook.
|
||||
|
||||
- **Public-private key pairs**, which are used to transfer secrets between users.
|
||||
|
||||
@ -97,4 +97,4 @@ At this point, both users have a copy of the key and can share notes over E2EE.
|
||||
|
||||
A user can only have one PPK.
|
||||
|
||||
PPKs are generated automatically when E2EE is enabled and when the user synchronises. They are then stored in info.json on the sync target. The key is genrated during sync because otherwise multiple clients could generate a PPK, and then there would be a conflict to decide which PPK should be kept. By doing it during sync, it ensures that only one PPK is generated because the synchronizer fetches first info.json - and only generates a PPK if none is already present.
|
||||
PPKs are generated automatically when E2EE is enabled and when the user synchronises. They are then stored in info.json on the sync target. The key is generated during sync because otherwise multiple clients could generate a PPK, and then there would be a conflict to decide which PPK should be kept. By doing it during sync, it ensures that only one PPK is generated because the synchronizer fetches first info.json - and only generates a PPK if none is already present.
|
||||
|
||||
@ -12,11 +12,11 @@ The events are tied to a particular parent ID - in other words it's only possibl
|
||||
|
||||
## What is a change event
|
||||
|
||||
An event can be "create", "update" or "detete" and is associated with a given file. The client uses this info to apply the change locally - creating, updating or deleting the file as needed.
|
||||
An event can be "create", "update" or "delete" and is associated with a given file. The client uses this info to apply the change locally - creating, updating or deleting the file as needed.
|
||||
|
||||
Attached to the event, is also a copy of the file metadata, so the client doesn't need to a do a second request to fetch it.
|
||||
|
||||
Internally, the event also stores the file name and parent ID. This is used when an item is deleted since in that case the item ID only would not be sufficient to know where the item was initally stored.
|
||||
Internally, the event also stores the file name and parent ID. This is used when an item is deleted since in that case the item ID only would not be sufficient to know where the item was initially stored.
|
||||
|
||||
## Event compression
|
||||
|
||||
@ -88,4 +88,4 @@ The client would then follow this logic:
|
||||
- If the file is present, delete it.
|
||||
- If it is not, skip the event (not an error).
|
||||
|
||||
It might seem we could derive the "create" events simply by looking at the files in the directory - all files that are there would implicitely have a "create" event. The issue however is that it's not possible to reliably iterate over the files in a folder, because they might change in the meantime. The change events on the other hand provide an ID that can be used reliably to iterate over changes, and to resume at any time.
|
||||
It might seem we could derive the "create" events simply by looking at the files in the directory - all files that are there would implicitly have a "create" event. The issue however is that it's not possible to reliably iterate over the files in a folder, because they might change in the meantime. The change events on the other hand provide an ID that can be used reliably to iterate over changes, and to resume at any time.
|
||||
@ -13,7 +13,7 @@ The process to share is then:
|
||||
|
||||
- First, the sharer calls `POST /api/shares` with the notebook ID that needs to be shared.
|
||||
- Then invitations can be sent by calling `POST /api/share_users` and providing the share ID and recipient email.
|
||||
- The recipient accept or reject the application by setting the status onn the `share_users` object (which corresponds to an invitation).
|
||||
- The recipient accept or reject the application by setting the status on the `share_users` object (which corresponds to an invitation).
|
||||
|
||||
Once share is setup, the client recursively goes through all notes, sub-notebooks and resources within the shared notebook, and set their `share_id` property. Basically any item within the notebook should have this property set. Then all these items are synchronized.
|
||||
|
||||
@ -21,7 +21,7 @@ On the server, a service is running at regular interval to check the `share_id`
|
||||
|
||||
### Why is the share_id set on the client and not the server?
|
||||
|
||||
Technically, the server would only need to know the root shared folder, and from that can be find out its children. This approach was tried but it makes the system much more complex because some information is lost after sync - in particular when notes or notebooks are moved out of folders, when resources are attached or removed, etc. Keeping track of all this is possible but complex and innefficient.
|
||||
Technically, the server would only need to know the root shared folder, and from that can be find out its children. This approach was tried but it makes the system much more complex because some information is lost after sync - in particular when notes or notebooks are moved out of folders, when resources are attached or removed, etc. Keeping track of all this is possible but complex and inefficient.
|
||||
|
||||
On the other hand, all that information is present on the client. Whenever a notes is moved out a shared folder, or whenever a resources is attached, the changes are tracked, and that can be used to easily assign a `share_id` property. Once this is set, it makes the whole system more simple and reliable.
|
||||
|
||||
|
||||
@ -64,4 +64,4 @@ If it's lower than the client supported version, the client does not allow sync
|
||||
|
||||
If the user click on the link to upgrade, upgradeState becomes MUST_UPGRADE, and the app restarts.
|
||||
|
||||
On startup, the app check the upgradeState setting. If it is MUST_UPGRADE it displays the upgrade screen and starts upgrarding. Once done it sets upgradeState back to IDLE, and restart the app.
|
||||
On startup, the app check the upgradeState setting. If it is MUST_UPGRADE it displays the upgrade screen and starts upgrading. Once done it sets upgradeState back to IDLE, and restart the app.
|
||||
@ -292,7 +292,7 @@ The following commands are available in [command-line mode](#command-line-mode):
|
||||
Possible keys/values:
|
||||
|
||||
sync.target Synchronisation target.
|
||||
The target to synchonise to. Each sync
|
||||
The target to synchronise to. Each sync
|
||||
target may have additional parameters which
|
||||
are named as `sync.NUM.NAME` (all
|
||||
documented below).
|
||||
|
||||
Loading…
Reference in New Issue
Block a user