This commit introduces a new extension type View, which enables developers
to implement extensions with GUI. It is implemented using iframe, developers
can specify the path to the HTML file in the `Extension.page` field, then
Coco will load and render that page when the extension gets opened.
coco-api
We provide a TypeScript library [1] that will contain the APIs developers
need to make the experience better.
We start from file system APIs. Since the embedded HTML page will be loaded
by WebView, which has no access to the local file system, we provide APIs
to bridge that gap. Currently, `fs:read_dir()` is the only API we implemented, more
will come soon.
Permission
As View extensions run user-provided code, we introduce a permision
mechanism to sandbox the code. Developers must manually specify the
permission their extension needs in the "plugin.json" file, e,g.:
"permissions": {
"fs": [
{ "path": "/Users/foo/Downloads", "access": ["read", "write"] },
{ "path": "/Users/foo/Documents", "access": ["read"] }
],
"http": [
{ "host": "api.github.com" }
],
"api": ["fs:read_dir"]
}
Currently, both fs and api permissions are implemented. Permission checks
apply only to View extensions for now; Command extensions will support
them in the future.
[1]: https://github.com/infinilabs/coco-api
The file search extension relies on the OS's desktop search to work, and it
is possible that the desktop search indexer may not index the search paths
we specify.
This commit adds a hook that signals to the indexer and lets it index
the paths we need. This hook will be invoked when:
* initialing the extension
* enabling the extension
* upon every configuration change
to make our best effort to fix the issue.
* feat: extension Window Management for macOS
* release note
* revert frontend code changes
* new line char
* remove todo
* it is macos-only
* format code
* macos-only
* more conditional compilation
* correct field Document.icon
This commit fixes(I guess?) the issue that the Settings window may not be
rendered or loaded, you will see that the whole window is gray in that case.
Background, aka, why this issue exists
=============================================================
In commit [1], we wrapped all the backend setup routines in a tauri command, so
that frontend code can call it before invoking any other backend interfaces to
guarantee that these interfaces won't be called until the data/state they rely
on is ready.
The implementation in [1] had an issue that it didn't work with window reloading.
To fix this issue, we made another commit [2]. Commit [2] fixed the refresh
issue, but it also caused the settings window issue that this commit tries to fix.
The backend setup tauri command needs a state to track whether the setup has
completed. In the previous implementation, this was done in the frontend. In
this commit, it is moved to the backend.
Why didn't you guys move that state to backend in previous commits, e.g., commit [2]?
=============================================================
We tried, but failed. In the previous tries, the backend would send an event
to the frontend, but the frontend couldn't receive it, for reasons we still
don’t understand. And this weird issue still exists, we just happen to find
a way to work around it.
[1]: f93c527561
[2]: 993da9a8ad
Co-authored-by: ayang <473033518@qq.com>
In the previous macOS file search implementation, we spawned an mdfind child
process and killed it when we got the results we needed to avoid zombie
processes. However, this kill step would be skipped if an error happened
during query results processing as we propagate errors.
This commit replaces the manual kill operation with the `ChildProcHandle.kill_on_drop()`
API to let RAII do the job to fix the issue.
This commit implements the file search extension for Linux with the
GNOME desktop environment by employing the engine that powers GNOME's
desktop search - Tracker.
It also fixes an edge case bug that the search and exclude path
configuration entries will not work. For example, say I set the search path
to ["~/Dcouments"], and I have a file named "Documents_foobarbuzz" under
my home directory, this file is not in the specified search path but
Coco would return it because we verified this by checking string prefix.
Claude Code found this when I asked it to write unit tests. Thank both
tests and Claude Code.
* refactor: relax the file search conditions on macOS
This commit makes the file search conditions more permissive on macOS:
* Searching by filename
Now this is case-insensitive
* Searching by filename and content
We previously only searched for 2 attributes:
1. kMDItemFSName
2. kMDItemTextContent
as the semantics should be exactly right (Search fileanme and content). But
kMDItemTextContent does not work as expected. For example, if a PDF document
contains both "Waterloo" and "waterloo", it is only matched by "Waterloo".
To workaround this (I consider this a bug of Spotlight), now we search all
the attributes.
* format code
* document
Coco panicked on Windows when I was testing the applications-rs crate on
Windows, the error message seemingly indicates that we should run hotkey setup
on the main thread, and doing that indeed fixes the issue, so let's do
it.
I wasn't aware that both '-' (specified by the standard) and '_' (not in the
standard, but is commonly used) can be used as the tag delimiter in locale
strings[1] when I originally wrote this commit[2].
Both "zh-CN" and "zh_CN" are valid locale strings!
Since '_' is more commonly used, I thought it was the only correct form and
thus our code only accepts it.
This commit refactors the implementation to accept both.
[1]: https://stackoverflow.com/a/36752015/14092446
[2]: f5b33af7f1
After this commit, we index both English and Chinese application names
so that searches in either language will work. And the names of the
applications in search results and application list will be in the app language.
Pizza index structure has been updated, but backward compatibility is preserved
by keeping the support code for the old index field.
The changes in this commit are not macOS-specific, it applies to all supported
platforms. Though this feature won't work on Linux and Windows until we implement
the localized app name support in the underlying applications-rs crate.
Bumps the 'applications' crate to include this commit[1]. With this,
Coco now indexes iOS apps and macOS apps that store icon in Assets.car.
[1]: 814b16ea84
refactor: coordinate third-party extension operations using lock
During debugging 783cb73b29,
I realized that some extension operations were not synchronized and thus would
behave incorrectly under concurrency. Though GUI apps like Coco typically
won't have concurrency. This commit synchronizes them by putting them behind
the lock.
This commit implementes a new extension setting entry
"hide_before_open":
> Extension plugin.json
```json
{
"name": "Screenshot",
"settings": {
"hide_before_open": true
}
}
```
that, if set to true, Coco will hide the main window before opening the
extension.
Only entensions that can be opened can set their "settings" field, a
check rule is added to guarantee this.
Deep linking is handled on the frontend, so this commit removes the related and
unused backend code.
"src-tauri/tauri.conf.json" is also modified, field "plugins.deep-link.schema"
does not exist so I removed it as well.
