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.
This commit reverts the logic introduced in
e7dd27c744:
> Pinning the main window would bring "NSWindowCollectionBehaviorCanJoinAllSpaces"
> back to make it really stay pinned across all the spaces.
Commit 6bc78b41ef (diff-b55e9c1de63ea370ce736826e4dea5685bfa3992d8dee58427337e68b71a1fc1)
did a tiny refactor to the frontend code merged in the above commit,
these changes are reverted as well.
We revert these changes because we observed an issue with window
focus, and we don't know the root cause and how to fix the issue either.
The following change is kept because we don't want to hit this NS panel
bug[1]. But if the issue still exists after this commit, it will
be removed as well.
In "src-tauri/src/setup/mac.rs":
```diff
panel.set_collection_behaviour(
- NSWindowCollectionBehavior::NSWindowCollectionBehaviorCanJoinAllSpaces
+ NSWindowCollectionBehavior::NSWindowCollectionBehaviorMoveToActiveSpace
```
[1]: https://github.com/ahkohd/tauri-nspanel/issues/76
Before this commit, sub extensions were not allowed to set their
"platforms" field, this restriction is lifted in this commit.
By allowing this, a group extension can have sub extensions for
different platforms, here is an example (irrelavent fields are omitted
for the sake of simplicity):
```json
{
"name": "Suspend my machine",
"type": "Group",
"platforms": ["macos", "windows"],
"commands": [
{
"name": "Suspend macOS":
"platforms": ["macos"],
"action": {...}
},
{
"name": "Suspend Windows":
"platforms": ["windows"],
"action": {...}
}
]
}
```
While loading or installing extensions, incompatible sub extensions will
be filtered out by Coco, e.g., you won't see that "Suspend Windows"
command if you are on macOS.
An extra check is added in this commit to ensure a sub extensions won't
support the platforms that are incompatible with its main extension.
Even though main extensions and sub extensions can both have "platforms"
specified, the semantics of this field, when not set, differs between them.
For main extensions, it means this extension is compatible with all the
platforms supported by Coco (null == all). For sub extensions, having it
not set implicitly says that this field has the same value as the main
extension's "platforms" field.
The primary reason behind this design is that if we choose the semantics used
by the main extension, treating null as all, all the extensions we currently
have will become invalid, because they are all macOS-only, the main extensions's
"platforms" field is "macos" and sub extensions' "platforms" is not set (null),
they will be equivalent to:
```json
{
"name": "this is macOS-only",
"type": "Group",
"platforms": ["macos"],
"commands": [
{
"name": "How the fxxk can this support all the platforms!"
"platforms": ["macos", "windows", "linux"],
"type": "Command",
"action": {...}
}
]
}
```
This hits exactly the check we mentioned earlier and will be rejected by
Coco. If we have users installed them, the installed extensions will be
treated invalid and rejected by future Coco release, boom, we break backward
compatibility.
Also, the current design actually makes sense. Nobody wants to repeatedly
tell Coco that all the sub extensions support macOS if this can be said only
once:
```json
{
"name": "this is macOS-only",
"platforms": ["macos"],
"commands": [
{
"name": "This supports macOS"
"platforms": ["macos"],
},
{
"name": "This supports macOS too"
"platforms": ["macos"],
},
{
"name": "Guess what! this also supports macOS"
"platforms": ["macos"],
},
{
"name": "Come on dude, do I really to say this platform=macos so many times"
"platforms": ["macos"],
}
]
}
```
Coco App has 4 sources of Extension/plugin.json that should be checked:
1. From the "<data directory>/third_party_extensions" directory
2. Imported via "Import Local Extension"
3. Downloaded from the "store/extension/<extension ID>/_download" API
4. From coco-extensions repository
Granted, Coco APP won't check these files directly, but we will
re-use the code and run them in that repository's CI.
Previously, only the Extensions from the first source were checked/validated.
This commit extracts the validation logic to a function and applies it to all
4 sources.
Also, the return value of the Tauri command "list_extensions()" has changed.
We no longer return a boolean indicating if any invalid extensions
are found during loading, which only makes sense when installing
extensions requires users to manually edit data files. Since we now
support extension store and local extension imports, it could be omitted.
This commit removes the generic argument R from all the AppHandle imports, which
is feasible as it has a default type. This change is made not only for simplicity,
but also **consistency**. Trait SearchSource uses this type:
```rust
pub trait SearchSource {
async fn search(
&self,
tauri_app_handle: AppHandle,
query: SearchQuery,
) -> Result<QueryResponse, SearchError>;
}
```
In order to make trait SearchSource object-safe, the AppHandle used in it cannot
contain generic arguments. So some parts of Coco already omit this generic
argument. This commit cleans up the remaining instances and unifies the usage
project-wide.
This commit adds support for installing extensions from a local folder path:
```text
extension-directory/
├── assets/
│ ├── icon.png
│ └── other-assets...
└── plugin.json
```
Useful for testing and development of extensions before publishing.
Co-authored-by: ayang <473033518@qq.com>
This commit splits query_coco_fusion() into 2 functions:
1. query_coco_fusion_single_query_source()
2. query_coco_fusion_multi_query_sources()
query_coco_fusion_single_query_source(), as the name suggests, will only search
1 query source. Due to this simplicity, it does not need the complex re-ranking
procedure used by query_coco_fusion_multi_query_sources(), which is the primary
reason why this commit was made.
Another reason behind the change is that the re-ranking logic makes the
search results of querying single query source incorrect, it removes documents
from the results. I didn't investigate the issue because dropping the complex
logic in single query source search would be the best solution here.
On Ubuntu (the GNOME version), Coco would panic when users open an app due
to the reason that Coco thinks it is running in an unsupported desktop
environment (DE).
We rely on the environment variable XDG_CURRENT_DESKTOP to detect the DE,
Ubuntu sets this variable to "ubuntu:GNOME" instead of just "GNOME",
which was not handled by the previous implementation.
This commit supports this case. Also, when Coco runs in an unsupported DE,
opening apps should not panic the app. After this commit, we would return
an error.
This commit fixes the following panic:
```
Time: [2025-07-23-17-03-23]
Location: [/Users/steve/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tauri-2.5.1/src/lib.rs:742:7]
Message: [state() called before manage() for tauri_plugin_global_shortcut::GlobalShortcut<tauri_runtime_wry::Wry<tauri::EventLoopMessage>>]
```
The root cause is that, in a Tauri application, before you can access a piece of
managed state with the .state() method, you must first register it with Tauri
using .manage(). When a user reigsters hotkey for an extension,
initializing extensions will invoke the .state() method, at that point,
.manage() hasn't been called.
The fix is simple, we simply call .manage() earlies (invoked by our
`shortcut::enable_shortcut(app)` function).
Having backtrace in the panic log will help debugging a lot. Under
release builds, we strip our binary so the symbols information is
unavailable, but this information is still useful in debug builds.
Panic log in release builds:
```
Time: [YYYY-MM-DD-HH-MM-SS]
Location: [/Users/foo/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/tauri-2.5.1/src/lib.rs:742:7]
Message: [state() called before manage() for tauri_plugin_global_shortcut::GlobalShortcut<tauri_runtime_wry::Wry<tauri::EventLoopMessage>>]
Backtrace:
0: __mh_execute_header
1: __mh_execute_header
2: __mh_execute_header
3: __mh_execute_header
4: __mh_execute_header
5: __mh_execute_header
6: __mh_execute_header
7: __mh_execute_header
8: __mh_execute_header
9: __mh_execute_header
10: __mh_execute_header
11: __mh_execute_header
12: __mh_execute_header
13: __mh_execute_header
14: __mh_execute_header
15: __mh_execute_header
16: __mh_execute_header
17: <unknown>
18: <unknown>
```
We found that Windows Search would error out if it encounters a single
quote character, the natural solution would be to escape it. But I couldn't
find out how. The approach mentioned by most posts:
```
~="<Unsupported Char>"
```
won't work in my test. So I decided to replace it with a whitespace.
Single quote is not the first unsupported character I know, the newline
character is not supported as well, so it will be handled in the same
way.
This commit fixes the search issue introduced by [commit](5c0a865822). We have no idea why the tauri command `get_app_search_source` won't be invoked after that commit on Windows.
This commit resolves the issue by moving the extension init logic to the Rust side.
Also, update the querysource logs in `quey_coco_fusion()`, the old one won't say anything if the querysource list is empty, the new one will tell us that.
