| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
Add react-i18n to make us able to use i18next translations in the
renderer process just like we do in the main process.
Translations are hot-reloaded automatically.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
| |
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add i18next with a custom backend to the main process to load
localization from file.
Missing localizations are written to a missing localizations file in
debug mode, but silently fall back in production mode.
We will also need to add a custom backend for the renderer process that
communicates with the main process.
(i18next-fs-electron-backend is not applicable here, because we need
localizations both in the main and renderer processes.)
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>
|
|
|
|
| |
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a "failed" state for services where the BrowserView and WebContents
should be left around to keep history and allow people to navigate back.
Access to the browser history otherwise doesn't seem possible
(see https://github.com/electron/electron/issues/26727
and https://github.com/electron/electron/issues/7186),
so destroying BrowserView and managing our own history is not possible.
Also keep https://github.com/electron/electron/issues/24113 in mind.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to `BrowserView.setBackgroundColor` not working under linux, we have
to inject styles to make sure our `BrowserView` is opaque.
We try to cover more edge cases to avoid the interference of the
injected style and the web site's own styles according to the CSS
specification:
https://www.w3.org/TR/css-backgrounds-3/#body-background
In particular, we avoid overwriting the styles for the `html` element
if `body` already has an opaque background so that the background of
`body` can extend to the whole canvas.
This might still interfere with the web site if it updates the
background color on the fly (dark mode), but a reload should solve
most of such issues.
Hopefully, after
https://github.com/electron/electron/issues/32898
is resolved, we can get rid of the hack entirely.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
|
|
|
|
| |
The buttons and the text field in the location bar shall now affect the
BrowserView of the loaded service.
Some error handling is still needed, e.g., when loading a web page fails
due to a DNS error.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
|
|
| |
Still needs adding event handlers to actually navigate the browser.
Signed-off-by: Kristóf Marussy <kristof@marussy.com>
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
| |
Lets the main process see which service is currently selected.
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>
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
* stores: reactive data structures to hold application state
* controllers: subscribe to store changes and call store actions in
response to external events from services
* services: integrate with the nodejs and electron environment (should
be mocked for unit testing)
|
|
The architecture in the main process is split into 3 main parts:
* services: interfaces for services are injected into the stores through
the MainEnv interface (for testability)
* services/impl: electron-specific implementations of services
* stores: the actions of the stores can invoke (asynchronous) services
|