mirror of
https://github.com/laurent22/joplin.git
synced 2024-12-24 10:27:10 +02:00
Doc: Moved all GSoC ideas to single document
This commit is contained in:
parent
5d0ba460ae
commit
13be56a2e3
@ -1,19 +0,0 @@
|
||||
# GSoC: Collaboration
|
||||
|
||||
We need a way to share notes with other users, or publicly, and to collaborate on notes with other users. This is useful for companies, to collaborate on projects for example, but also for individual users when they want to share their notes with other people.
|
||||
|
||||
The basis for this would be the [Joplin Web API for Nextcloud](https://github.com/laurent22/joplin-nextcloud/), which is currently used to share a note publicly, and which can be extended for other uses. There is a [discussion thread](https://discourse.joplinapp.org/t/joplin-api-in-nextcloud-prototype/) about it in the forum.
|
||||
|
||||
## Features
|
||||
|
||||
The features we are looking to implement are:
|
||||
|
||||
- Sharing a note publicly and allow the people you shared the link with to edit it.
|
||||
- Share a notebook publicly.
|
||||
- Share a note or notebook with the given Nextcloud user.
|
||||
|
||||
For now, we limit the scope to Nextcloud but later the Nextcloud app (which is essentially a PHP app) could be extracted and made to work with other backends.
|
||||
|
||||
## See also
|
||||
|
||||
- [Feature Request: Multiple synchronization targets #1293](https://github.com/laurent22/joplin/issues/1293)
|
@ -1,9 +0,0 @@
|
||||
# GSoC: Hierarchical Tags
|
||||
|
||||
One of the most asked-for feature in Joplin is support for hierarchical tags. This would allow users that heavily rely on tags to organise them into a hierarchy, as is done for the notebooks.
|
||||
|
||||
The feature would need to be implemented for the three clients (Desktop, Mobile, Terminal).
|
||||
|
||||
## See also
|
||||
|
||||
- [GitHub issue: Hierarchical tags](https://github.com/laurent22/joplin/issues/375)
|
@ -1,14 +0,0 @@
|
||||
# GSoC: Sharing on Mobile
|
||||
|
||||
The mobile application allows sharing text from any application to Joplin. However it is not currently possible to share images or to share selected text with Joplin.
|
||||
|
||||
## Features
|
||||
|
||||
- Allow sharing an image or file from any application to Joplin
|
||||
- Allow selecting some text in an application (in a browser for instance) and share it with Joplin
|
||||
|
||||
## See also
|
||||
|
||||
- [Mobile - Add share menu #876](https://github.com/laurent22/joplin/issues/876)
|
||||
- [Turtl’s sharing - Choose who you share with and what they can do.](https://turtlapp.com/features/)
|
||||
- [Turtl Documentation - App architecture](https://turtlapp.com/docs/architecture)
|
@ -1,81 +0,0 @@
|
||||
# GSoC: Support for multiple profiles
|
||||
|
||||
The applications should support multiple profiles so that, for example, one can have a "work" profile and "personal" profile. This will also make it easier to share notes because for example a "work project" profile could be created and share with co-workers.
|
||||
|
||||
## Specification
|
||||
|
||||
Provide a way to switch profiles from the app:
|
||||
|
||||
- The user clicks on a menu and select change profile
|
||||
- The list of available profiles is displayed
|
||||
- User selects on of the profile
|
||||
- The app closes and re-open and load the selected profile
|
||||
|
||||
### Changing the structure of the profile directory
|
||||
|
||||
The structure of the profile directory needs to be changed for this to work.
|
||||
|
||||
Currently, the profile is organised like this:
|
||||
|
||||
* ~/.config/joplin-desktop/
|
||||
* resources/
|
||||
* database.sqlite
|
||||
|
||||
If we want to support multiple profiles, the config directory should be changed like so (in a way similar to Firefox or Thunderbird multi-profile support):
|
||||
|
||||
* ~/.config/joplin-desktop/
|
||||
* PROFILE_ID_1/
|
||||
* PROFILE_ID_2/
|
||||
* etc.
|
||||
* profile.ini
|
||||
|
||||
The PROFILE_ID_x directories will be named with a UUID and contain the same profile as above with the "resources" and "database.sqlite" file.
|
||||
|
||||
`profile.ini` will tell what profiles are available. It's content will be like this (same as Firefox):
|
||||
|
||||
```ini
|
||||
[Profile1]
|
||||
Name=Personal
|
||||
IsRelative=1
|
||||
Path=cdb4ar19.Personal
|
||||
|
||||
[Profile0]
|
||||
Name=default
|
||||
IsRelative=1
|
||||
Path=Profiles/ts6eud8o.default
|
||||
Default=1
|
||||
|
||||
[Profile2]
|
||||
Name=Work
|
||||
IsRelative=1
|
||||
Path=Profiles/ts9akd8o.work
|
||||
|
||||
[General]
|
||||
StartWithLastProfile=1
|
||||
Version=1
|
||||
```
|
||||
|
||||
Since the profile directory is changed, there should be a migration step that will convert old profiles to the new structure when the app starts.
|
||||
|
||||
### Switching profiles
|
||||
|
||||
To switch profile, save a value to the Settings called "next_profile_id", then close and restart the app. When the app starts it loads "profile.ini", then checks the value of "next_profile_id", and uses that to choose and load the right profile.
|
||||
|
||||
### Locking per profile
|
||||
|
||||
Each app needs to make sure that a given profile can only be open by one application, so there should be form of lock. If a profile is locked, it means it's already opened by another application, so the current application should close.
|
||||
|
||||
Locking should be implemented in such a way that if an app crashes, the lock is released. So probably some form of in-memory lock.
|
||||
|
||||
### Desktop implementation
|
||||
|
||||
To restart the app use the built-in Electron function: https://electronjs.org/docs/api/app#apprelaunchoptions
|
||||
|
||||
### Mobile implementation
|
||||
|
||||
On mobile, give a try to this package to restart the app: https://www.npmjs.com/package/react-native-restart
|
||||
|
||||
## See also
|
||||
|
||||
- Forum thread: https://discourse.joplinapp.org/t/can-i-run-a-second-instance-of-joplin/110
|
||||
- GitHub issue: https://github.com/laurent22/joplin/issues/591
|
@ -1,29 +0,0 @@
|
||||
# GSoC: Nextcloud notes integration (Web client)
|
||||
|
||||
## What is the goal of the project
|
||||
|
||||
There is the community's wish to have the notes integrated Nextcloud, so that Notes can be sought by Nextcloud itsself. Although this idea focuses on Nextcloud it shall allow to extend it to other collaboration applications going beyond the current scope of [Synchronisation](https://joplinapp.org/#synchronisation).
|
||||
|
||||
There is already the [web application](https://github.com/foxmask/joplin-web) what may can be integrated in collaboration application.
|
||||
|
||||
There is also a [Joplin Web API for Nextcloud](https://github.com/laurent22/joplin-nextcloud/), which is currently used to share a note publicly, and which could be extended to other uses. There is a [discussion thread](https://discourse.joplinapp.org/t/joplin-api-in-nextcloud-prototype/) about it in the forum.
|
||||
|
||||
## Features
|
||||
|
||||
Feature parity with the desktop client is not needed and would be out of scope.
|
||||
|
||||
These are the features that would be needed to create a minimal web client:
|
||||
|
||||
- Ability to list the notebooks in a hierarchy
|
||||
- Ability to view a note and render the Markdown to HTML
|
||||
- Ability to edit the Markdown note and save it
|
||||
- Handle conflicts when, for example, a note is modified in the web client and, at the same time, it is modified via sync.
|
||||
|
||||
## Who is talking about it
|
||||
|
||||
The idea is outcome of (but not limited to) of some discussion taking place in the Forum and on GitHub:
|
||||
|
||||
- [Support Joplin structure and notebooks #248](https://github.com/nextcloud/notes/issues/248)
|
||||
- [Joplin Web](https://discourse.joplinapp.org/t/joplin-web-web-application-companion-for-joplin/555)
|
||||
- [New search engine in Joplin](https://discourse.joplinapp.org/t/new-search-engine-in-joplin/1479)
|
||||
- [Nextcloud notes integration (Web client)](https://github.com/laurent22/joplin/issues/228)
|
@ -1,71 +0,0 @@
|
||||
# GSoC: OCR
|
||||
|
||||
It seems possible to add support for OCR content in Joplin via the [http://tesseract.projectnaptha.com/](Tesseract library).
|
||||
|
||||
A first step would be to assess the feasability of this project by integrating the lib in the desktop app and trying to OCR an image.
|
||||
|
||||
- Is the image correctly OCRed?
|
||||
- Does it work with non-English text?
|
||||
- How slow/fast is it? Test with a very large image to be sure. It should not freeze the app while processing an image.
|
||||
|
||||
If everything works well, we can add the feature to the app.
|
||||
|
||||
## Specification
|
||||
|
||||
- On desktop app: Create service that runs in the background and process the resources that need to be OCRed.
|
||||
- When a document is OCRed: Append block to end of note that contains the extracted plain text
|
||||
- When attaching resource, ask what user wants to do:
|
||||
- Always OCR all files
|
||||
- Never OCR any file
|
||||
- Always OCR files with extension ".ext"
|
||||
- Never OCR files with extension ".ext"
|
||||
- Can be changed in settings
|
||||
- Right-click resource, or note, to OCR content
|
||||
- Add resource ocr_status on resource table: Can be: none, todo, processing, done
|
||||
- Add ocr_text to resource: must include detailed coordinates, and a way to get plain text back
|
||||
|
||||
**Advantage of it doing that way:**
|
||||
|
||||
- Search engine just works - no need for special indexing of OCR content since it is inside the note directly
|
||||
- Will work with all clients (mobile, desktop, terminal)
|
||||
- When a note is exported to Markdown, it will include the OCR content
|
||||
|
||||
**Format of OCR text block**
|
||||
|
||||
```
|
||||
<!-- autogen-ocr :resource.id -->
|
||||
* * *
|
||||
|
||||
**:resource.title**
|
||||
|
||||
:resource.ocr_text
|
||||
<!-- autogen-ocr :resourceId -->
|
||||
```
|
||||
|
||||
For example, for a resource called "TrainTicket.png":
|
||||
|
||||
```
|
||||
<!-- autogen-ocr 2ee4eec909734f7197654a9a040dfba7 -->
|
||||
* * *
|
||||
|
||||
**TrainTicket.png**
|
||||
|
||||
From: London
|
||||
To: Paris
|
||||
Date: 01/12/2019
|
||||
Time: 15:00
|
||||
...etc.
|
||||
<!-- autogen-ocr :resourceId -->
|
||||
```
|
||||
|
||||
The advantage of this format is that it will render nicely in the viewer, and it will still be clearly identified as OCR content, which means later we can identify these blocks, update them, remove them, etc.
|
||||
|
||||
**Later**
|
||||
|
||||
- Support PDF files - for example by converting each page to an image first, then passing it to Tesseract.
|
||||
- Make ocr_text searchable
|
||||
- Display search results directly on document. i.e. if it's an image, highlight the parts of the image that contain the search text.
|
||||
|
||||
## See also
|
||||
|
||||
- GitHub issue: https://github.com/laurent22/joplin/issues/807
|
@ -1,23 +0,0 @@
|
||||
# GSoC: Additinal protection per note
|
||||
|
||||
**DRAFT**
|
||||
|
||||
Joplin supports E2EE, which means the content is encrypted on the sync target. Locally the content curently is not encrypted.
|
||||
|
||||
We should add a new option to allow encrypting selected text within a note. It would work like so:
|
||||
|
||||
**Encrypting note content**
|
||||
|
||||
- Select some text in the editor
|
||||
- Select menu Edit => Encrypt
|
||||
- The selected text is replaced by encrypted content
|
||||
|
||||
**Decrypting note content**
|
||||
|
||||
- Place the cursor anywhere within the encrypted content.
|
||||
- Select menu Edit => Decrypt
|
||||
- The encrypted text is replaced by the plain text.
|
||||
|
||||
## Problem
|
||||
|
||||
If a user tries this on a resource, the resource should be encrypted too. But what if it is linked from another note? Perhaps this should only be implemented once the one-to-one relationship between notes and resources is enforced.
|
@ -1,17 +0,0 @@
|
||||
# GSoC: Search engine improvements
|
||||
|
||||
The current search engine is built on top of SQLite FTS. An index of the notes is built and this is what is used by FTS when searching.
|
||||
|
||||
While it works relatively well, there is still room for improvement. In particular we would like to implement the following:
|
||||
|
||||
- Remove the need for wildcard queries - for example instead of typing "search*", it will be possible to simply type "search" and results that contain "search" or "searching" will be included. Those that contain the exact match will come first.
|
||||
|
||||
- Search within certain tags (eg. "tag:software search" to search within the notes tagged with "software" and that contain the word "search").
|
||||
|
||||
- Improve relevance algorithm (give a weight to certain criteria, and allow adding new criteria more easily). In particular give more weight to recently modified notes, and less weight to completed to-dos.
|
||||
|
||||
- Allow fuzzy search (for example return results that contain "saerch" for the query "search")
|
||||
|
||||
## See also
|
||||
|
||||
[Search engine improvements](https://github.com/laurent22/joplin/issues/1877)
|
140
readme/gsoc/ideas.md
Normal file
140
readme/gsoc/ideas.md
Normal file
@ -0,0 +1,140 @@
|
||||
These are project ideas. You are welcome to propose your own project ideas, or variations of the ones below.
|
||||
|
||||
# 1. Support for multiple profiles
|
||||
|
||||
The applications should support multiple profiles so that, for example, one can have a "work" profile and a "personal" profile. This will also make it easier to share notes: for example a "work project" profile could be created and shared with co-workers via sync.
|
||||
|
||||
We want to offer this feature by allowing the user to select a profile from the app (eg. "work" or "personal", then switch to it. Switching would be done by restarting the app and loading the selected profile.
|
||||
|
||||
Expected Outcome: The user should be able to select a profile and switch to it.
|
||||
|
||||
Difficulty Level: Moderate
|
||||
|
||||
Platforms: Desktop and/or mobile (at the student's choice)
|
||||
|
||||
Skills Required: JavaScript; React; React Native (for mobile)
|
||||
|
||||
Potential Mentor(s):
|
||||
|
||||
More info: [GitHub issue](https://github.com/laurent22/joplin/issues/591), [Forum Thread](https://discourse.joplinapp.org/t/can-i-run-a-second-instance-of-joplin/110)
|
||||
|
||||
# 2. Collaboration via Nextcloud
|
||||
|
||||
We need a way to share notes with other users, and to collaborate on notes. This is useful for companies, to collaborate on projects for example, but also for individual users when they want to share their notes with other people.
|
||||
|
||||
The basis for this would be the [Joplin Web API for Nextcloud](https://github.com/laurent22/joplin-nextcloud/), which is currently used to share a note publicly, and which can be extended for other uses.
|
||||
|
||||
The main feature we would like to see is the ability to select a Nextcloud user from the app, then share a note with him or her. Once the note is shared, it will appear in the Joplin clients of the other user (via sync). The solution should be generic enough that it can later be used to share a whole notebook.
|
||||
|
||||
Expected Outcome: The user should be able to select a Nextcloud user then share a note with them. That note should then appear in the other user's Joplin clients.
|
||||
|
||||
Difficulty Level: High
|
||||
|
||||
Platforms: Desktop and/or mobile (at the student's choice)
|
||||
|
||||
Skills Required: JavaScript; React; React Native (for mobile)
|
||||
|
||||
Potential Mentor(s):
|
||||
|
||||
More info: [Forum thread about Joplin Web API for Nextcloud](https://discourse.joplinapp.org/t/joplin-api-in-nextcloud-prototype/)
|
||||
|
||||
# 3. Hierarchical Tags
|
||||
|
||||
One of the most asked-for feature in Joplin is support for hierarchical tags. This would allow users that heavily rely on tags to organise them into a hierarchy, as is done for the notebooks.
|
||||
|
||||
Expected Outcome: The tags can be organised into a hierarchy
|
||||
|
||||
Difficulty Level: Moderate
|
||||
|
||||
Platforms: Desktop, Mobile and Terminal
|
||||
|
||||
Skills Required: JavaScript; React; React Native (for mobile)
|
||||
|
||||
Potential Mentor(s):
|
||||
|
||||
More info: [GitHub issue](https://github.com/laurent22/joplin/issues/375)
|
||||
|
||||
# 4. Sharing on mobile
|
||||
|
||||
The mobile application allows sharing text from any application to Joplin. However it is not currently possible to share images or to share selected text with Joplin. We would like to allow sharing an image or file from any application to Joplin. And to allow selecting some text in an application (in a browser for instance) and share it with Joplin
|
||||
|
||||
Expected Outcome: Share images and selected with Joplin
|
||||
|
||||
Difficulty Level: Moderate
|
||||
|
||||
Platforms: Mobile (iOS and Android)
|
||||
|
||||
Skills Required: JavaScript; React; React Native
|
||||
|
||||
Potential Mentor(s):
|
||||
|
||||
More info: [Mobile - Add share menu #876](https://github.com/laurent22/joplin/issues/876)
|
||||
|
||||
# 5. Web client for Nextcloud
|
||||
|
||||
There is the community's wish to have the notes integrated Nextcloud, so that Notes can be sought by Nextcloud itsself. Although this idea focuses on Nextcloud it shall allow to extend it to other collaboration applications going beyond the current scope of [Synchronisation](https://joplinapp.org/#synchronisation). There is already the [web application](https://github.com/foxmask/joplin-web) what may used as a starting point, but it is also fine to start from scratch.
|
||||
|
||||
Feature parity with the desktop client is not needed and would be out of scope. These are the features that would be needed to create a minimal web client:
|
||||
|
||||
- Ability to list the notebooks in a hierarchy
|
||||
- Ability to view a note and render the Markdown to HTML
|
||||
- Ability to edit the Markdown note and save it
|
||||
- Handle conflicts when, for example, a note is modified in the web client and, at the same time, it is modified via sync.
|
||||
|
||||
Expected Outcome: Viewing and editing notes and notebooks from a Nextcloud-based web client
|
||||
|
||||
Difficulty Level: High
|
||||
|
||||
Skills Required: PHP (for the Nextcloud app). For the front-end it can be plain HTML (no JS), or React.
|
||||
|
||||
Potential Mentor(s):
|
||||
|
||||
More info: [GitHub: Nextcloud notes integration (Web client)](https://github.com/laurent22/joplin/issues/228)
|
||||
|
||||
# 5. OCR support
|
||||
|
||||
It is possible to add support for OCR content in Joplin via the [http://tesseract.projectnaptha.com/](Tesseract library). A first step would be to assess the feasability of this project by integrating the lib in the desktop app and trying to OCR an image. OCR support should be implemented as a service of the desktop app. It would extract the text from the images, and append the content as plain text to the notes.
|
||||
|
||||
Expected Outcome: A service on the desktop app that extract text from images and attach it to the note.
|
||||
|
||||
Difficulty Level: High
|
||||
|
||||
Skills Required: JavaScript
|
||||
|
||||
Potential Mentor(s):
|
||||
|
||||
# 6. Password-protected notes
|
||||
|
||||
We would like to add an option to allow encrypting a note or a notebook with a password. When opening the note, the password must be provided to reveal the content.
|
||||
|
||||
Expected Outcome: The user select a note and has the option to encrypt it.
|
||||
|
||||
Difficulty Level: Medium
|
||||
|
||||
Skills Required: JavaScript; React
|
||||
|
||||
Potential Mentor(s):
|
||||
|
||||
# 7. Search
|
||||
|
||||
The current search engine is built on top of SQLite FTS. An index of the notes is built and this is what is used by FTS when searching.
|
||||
|
||||
While it works relatively well, there is still room for improvement. In particular we would like to implement the following:
|
||||
|
||||
- Remove the need for wildcard queries - for example instead of typing "search*", it will be possible to simply type "search" and results that contain "search" or "searching" will be included. Those that contain the exact match will come first.
|
||||
|
||||
- Search within certain tags (eg. "tag:software search" to search within the notes tagged with "software" and that contain the word "search").
|
||||
|
||||
- Improve relevance algorithm (give a weight to certain criteria, and allow adding new criteria more easily). In particular give more weight to recently modified notes, and less weight to completed to-dos.
|
||||
|
||||
- Allow fuzzy search (for example return results that contain "saerch" for the query "search")
|
||||
|
||||
Expected Outcome: To be defined with the student. Depending on what features they would like to implement.
|
||||
|
||||
Difficulty Level: Medium
|
||||
|
||||
Skills Required: JavaScript
|
||||
|
||||
Potential Mentor(s):
|
||||
|
||||
More info: [Search engine improvements](https://github.com/laurent22/joplin/issues/1877)
|
@ -152,10 +152,6 @@ Finally, know that we will never assign you to a project you do not want to work
|
||||
|
||||
## Ideas
|
||||
|
||||
- [Idea: Nextcloud](https://joplinapp.org/gsoc/idea_nextcloud.html)
|
||||
- [Idea: Collaboration](https://joplinapp.org/gsoc/idea_collaboration.html)
|
||||
- [Idea: Hierarchical Tags](https://joplinapp.org/gsoc/idea_hierarchical_tags.html)
|
||||
- [Idea: Search](https://joplinapp.org/gsoc/idea_search.html)
|
||||
- [Idea: Mobile Sharing](https://joplinapp.org/gsoc/idea_mobile_sharing.html)
|
||||
- [Idea: OCR Support](https://joplinapp.org/gsoc/idea_ocr.html)
|
||||
- [Idea: Multi-profile support](https://joplinapp.org/gsoc/idea_multi_profiles.html)
|
||||
Please see below for a list of project ideas:
|
||||
|
||||
https://joplinapp.org/gsoc/ideas.html
|
||||
|
Loading…
Reference in New Issue
Block a user