| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
| |
We can't do this in the renderer package, because we need to import MUI
files that are not exported (MUI v6 is not ESM yet).
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
| |
Run integration tests in an electron environment for the main process.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to https://github.com/i18next/i18next/issues/1564 we still have to
implement our own language resolution, but we can rely on
resolvedLanguage to determine which language to pass through to the
renderer.
We will use the language detected by chromium as the system locale, so
there is no need to use os-locale for detection any more.
We use i18next in the main process do resolve the language, then set the
resolve (not requested!) language in the renderer process to avoid doing
resolution twice. This avoids the need in the renderer process to know
the list of supported languages.
We set the language and the writing direction in HTML in the renderer.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Load localization according to either the environment or the
configuration file from the list of supported locales.
Ideally, we would also set the chromium locale with --lang, but by the
time we have read the config file (to known which locale to set),
electron has already initialized the chromium resource bundle.
So the chromium localization will always be auto-detected by chromium.
Also makes startup hopefully a bit faster by doing more things
concurrently while the localization and the main window is being loaded.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The menu is populated reactive from the store with no caching.
This doesn't seem to cause any performance problems so far.
Currently the menu is electron-specific.
In the future, we'll need a more runtime-independent way to build the
menu.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allows customization of stores both in the renderer and in the main
process. Instead of exposing a basic model type from the shared module
(which was be overwritted with more specific props in the main package),
we expose factory function that can create specific model types in
both the renderer and the main process.
Using these package-specific customization to stores, the renderer
package can attach IPC calls directly to store objects, which the main
package can attach the handlers for IPC calls and other internal
actions.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
| |
Sophie start off from the service that was selected when it was last
open.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
| |
Move the handling of the contents of the config file out of the stores
and into dedicated files to simplify the code of the stores.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
| |
Make sure that files have a default import with the same name as the
file whenever possible to reduce surprise.
Also shuffles around some file names for better legibility.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
| |
Makes sure that the renderer always sees a consistent state.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
| |
Makes the synchronization of references across the main/renderer process
boundary more robust.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Now the runtime state lives inside the model (instead of being
associated to the static settings via a map), which simplifies state
management. Static settings are now located inside the runtime models,
so we must create tests to make sure that the settings are being
persisted correctly. The contents of the config file are now generated
as a view of store (instead of a snapshot), which adds flexibility.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
| |
Stores transient state for services shared between the main and renderer
processes.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
| |
eslint will also enforce prettier rules, so there is no need to call
prettier separately in CI.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
| |
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
| |
Signed-off-by: Vijay A <vraravam@users.noreply.github.com>
|
| |
|
|
|
|
|
|
| |
This reduces boilerplate and helps with config file robustness: if a
field is missing from the config file, it will be replaced with its
default value.
|
|
|