The desktop app in its current state does not function. More PRs will
come, but I wanted to keep this branch in sync with main instead of
continually rebasing it. Now that the photos app has been deployed, it
is a good idea to merge these changes.
Have paid extra attention to ensure that the diff for the web changes is
correct and does not introduce bugs.
We now bundle the renderer code within the app. So a load-fail indicates
something really wrong, not something we can deal with upfront (the code wasn't
probably even working - e.g. it was assigning to a function parameter
mainWindow, not the actual global var behind it).
From discussions, it seems that it was pre-emptively added but not specifically
requested by a customer. We can bring this back later if needed, or at least
offer better options to clean it, but for now I'm pruning the IPC surface to
reduce the amount of work needed for handling contextIsolation and sandboxing.
Electron also comes with its own type definitions, and from a (possibly dated)
blog post announcing this I got that we should not be overriding it with
@types/node: https://www.electronjs.org/pt/blog/typescript
Things will break, but let's try to fix them. In the current state, this is
preventing us from running `yarn dev` without reverting back to Electron 21.
When we merge main into a deploy/* branch (e.g.
https://github.com/ente-io/ente/pull/1147), all changes get pulled in
not just the one related to that deployment, and this causes almost all
of the path based workflows to run again unnecessarily. Exclude the
various "deploy/**" branches to stop these unnecessary workflows from
being triggered.
When we merge main into a deploy/* branch
(e.g. https://github.com/ente-io/ente/pull/1147), all changes get pulled in not
just the one related to that deployment, and this causes almost all of the path
based workflows to run again unnecessarily. Exclude the various "deploy/**"
branches to stop these unnecessary workflows from being triggered.
## Description
- Also started storing the embedding size and version in the table. This
will come handy while comparing overall size when different compression
and serialization formats are used..
- Also, it can be used to smartly auto-download the embeddings or inform
the user about approximate size when they decide to enable indexing or
search on a particular client.
## Tests
✅ Verified that embedding fetch and store is working fine.
✅ Verified that embeddings/diff API is working fine.
