digidem / comapeo-desktop Goto Github PK
View Code? Open in Web Editor NEWLicense: GNU General Public License v3.0
License: GNU General Public License v3.0
Add Name
Add Name
buttonGo to Map
buttonDone
buttonhttps://docs.google.com/spreadsheets/d/18x135fNGqwryXcBoJGvtNSJJMHuPB48Vp0o1l16UyzY/edit?usp=sharing
Create a shared text component that follows the design patterns of CoMapeo Mobile..
Text
component in sharedComponents
foldertype TextProp = {
// check if it is a MessageDescriptor. If it is a message descriptor translate it using [formatMessage](https://formatjs.io/docs/react-intl/api#formatmessage)
children : React.ReactNode || MessageDescriptor //https://formatjs.io/docs/react-intl/components#message-descriptor
style: React.CSSProperties
}
Leave Project
Use this design but edit content to match mobile
Leave Project
buttonCancel
buttonClose
buttonGo back
buttonLeave Project
Go back
buttonCreate Button following CoMapeo Mobile's design. Button should use Material UI's Button.
type ColorScheme = 'dark' | 'light' | 'ComapeoBlue';
type Variant = 'contained' | 'outlined' | 'text';
type Size = 'medium' | 'large';
type ButtonProps = {
// check if it is a MessageDescriptor. If it is a message descriptor translate it using [formatMessage](https://formatjs.io/docs/react-intl/api#formatmessage)
children: React.ReactNode | MessageDescriptor //https://formatjs.io/docs/react-intl/components#message-descriptor
color?: ColorScheme;
disabled?: boolean;
onPress: () => void;
size?: Size;
testID?: string;
variant?: Variant;
}
Our development docs have some documentation about the project structure but it would also be helpful to have some notes about specific technical choices that were made and why. Examples could include: libraries that are used extensively (for things like component library, state management, localization, and routing), build tooling, release management, etc.
Probably makes most sense to create a separate document for this stuff (something like ARCHITECTURE.md
)
On mobile, we use Expo's SecureStore API to handle storage of the rootkey that's passed to core. We need something similar for desktop, where we securely store the key on a device level. The key is sensitive and therefore it does not seem appropriate to store it via electron-store
(see note in docs).
Seems like safeStorage
is the technically sound option? Minor concern is that it requires some user-intervention, which has UX consequences (at least on macOS, where it prompts you to enter your root password in order to let the app access the keychain).
Open to other options and thoughts. Haven't explored the ecosystem too much so maybe there's something that's appropriate that I missed.
Close
buttonCreate a Project /Start a new CoMapeo Project
buttonJoin a Project/ Join an existing CoMapeo Project
buttonCreate a Project /Start a new CoMapeo Project
buttonJoin a Project/ Join an existing CoMapeo Project
buttonEnter a name for the project
titleAdvanced project settings
dropdown buttonImport config
when Advanced project settings
is openImport config
display file chooserCreate Project
buttonInvite Devices
buttonGo to Map
buttonhttps://docs.google.com/spreadsheets/d/1kpoU-mr-fJyxbAxERqrhC2IyRd3T64YEs8fUDzbAFQY/edit?usp=sharing
To do
Extracted from #18. That PR introduces changes that generally work fine in development, but when building the archive we run into some issues.
Currently, when packaging the app, all packages that are specified as deps are copied over into the packaged application (and live in the node_modules
directory). this is built-in behavior of the vite plugin and as of right now, there is no way to change this (see electron/forge#3570). this results in a rather bloated package size because it essentially copies over a good portion of the node_modules
directory into the archive when it's not necessary to do so. We'll need to adjust the vite configuration to account for this (which was originally mostly taken from a template that they provide, with some adjustments based on issues i found):
build.rollupOptions.externals
field to make sure that only native modules or builtins (e.g. electron
) are not bundledAt the time of writing, Electron 31.1.0 is available. I was going to do this work when the v31 line was initially released, but wanted to wait on better-sqlite3 to publish a release that included compatible prebuilds. Starting from v11.1.0, better-sqlite3 now includes the compatible prebuilds, which makes this work more reasonable to do.
Upgrading should (hopefully) not be problematic in terms of existing app code. Better to do this sooner rather than later, when there's more app code that's reliant on Electron APIs.
Sync
, display No devices are syncingSync
buttonSync
, display XXXX Devices Waiting to Sync with youStop Sync
buttonYou’re all caught up!
buttonYou’re all caught up!
button is clicked, add glowing color redGet Started
buttonhttps://docs.google.com/spreadsheets/d/18x135fNGqwryXcBoJGvtNSJJMHuPB48Vp0o1l16UyzY/edit?usp=sharing
Using electron@30
, we get the following error when attempting to use @mapeo/core
in the main process (technically in the utility process):
/Users/andrewchou/GitHub/digidem/comapeo-desktop/node_modules/@mapeo/crypto/lib/key-utils.js:43
const masterKey = sodium.sodium_malloc(32)
^
Error: failed to create a n-api buffer
at deriveMasterKeyFromRootKey (/Users/andrewchou/GitHub/digidem/comapeo-desktop/node_modules/@mapeo/crypto/lib/key-utils.js:43:28)
at new KeyManager (/Users/andrewchou/GitHub/digidem/comapeo-desktop/node_modules/@mapeo/crypto/key-manager.js:41:23)
at new MapeoManager (file:///Users/andrewchou/GitHub/digidem/comapeo-desktop/node_modules/@mapeo/core/src/mapeo-manager.js:121:24)
at initializeCore (file:///Users/andrewchou/GitHub/digidem/comapeo-desktop/.vite/build/service/core.js:169:20)
at file:///Users/andrewchou/GitHub/digidem/comapeo-desktop/.vite/build/service/core.js:75:40
at ModuleJob.run (node:internal/modules/esm/module_job:222:25)
at async ModuleLoader.import (node:internal/modules/esm/loader:316:24)
at async node:electron/js2c/utility_init:2:17148
at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:138:5)
Node.js v20.14.0
@mapeo/core
uses sodium-universal
under the hood. Seems related to sodium-friends/sodium-native#185. Haven't tried the suggested solutions there yet.
Replacing sodium-native
with sodium-javascript
via sodium-universal
leads to a different issue (missing method due to incomplete implementation):
/Users/andrewchou/GitHub/digidem/comapeo-desktop/node_modules/@mapeo/crypto/lib/key-utils.js:45
sodium.crypto_pwhash(
^
TypeError: sodium.crypto_pwhash is not a function
Invite Device
buttonLeave Project
buttonCancel
buttonParticipant
buttonCoordinator
buttonCoordinator
buttonSend Invite
buttonCancel Invite
buttonSabella - 👾 Dev team, this state should reflect the user waiting for someone to accept invite. So sit for 3 to 5 secs?
Display text Invite Accepted
Display device details
Create a Add Another Device
button
If clicked Add Another Device
button , go back to # 2
Create a Close
button
When device is invited, display device name under Particpant or Coordinator
To better inform us of components that we'd want to implement as part of a potentially shared component library, we should start documenting what we need. This is also helpful for us in the future in the case that we want to use a different library or approach for implementing these.
Create or Join a Project
buttonSettings
button as designedCreate or Join Project
buttonCreate a new project or join existing one
under Create or Join Project
buttonProject Settings
buttonCategories, Config, Icons
under Project Settings
buttonApp Settings
buttonLanguage, Security, Coordinates
under App Settings
buttonExperimental Feature
buttonAbout CoMapeo
buttonLVersion and build number
under About CoMapeo
buttonDevice Name
buttonConfiguration
buttonYour Team
buttonLanguage
buttonCoordinate System
buttonMap Management
buttonSecurity
buttonExperiments
buttonDirectional arrow
buttonBackground maps
buttonData layers
buttonContinue editing
buttonDiscard changes
buttonA declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.