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.
* chore: not request the interface if not logged in
* chore: res
* chore: res
* chore: common interface
* chore: no login
* chore: login
* chore: login
* chore: add
* dbg print servers
* chore: id
* docs: update notes
---------
Co-authored-by: Steve Lau <stevelauc@outlook.com>
* refactor: do status code check before deserializing response
This commit adds a status code check to the following requests, only when
this check passes, we deserialize the response JSON body:
- get_connectors_by_server
- mcp_server_search
- datasource_search
A helper function `status_code_check(response, allowed_status_codes)`
is added to make refactoring easier.
* chore: release notes
This commit implements the file search extension for Windows platforms using the [Windows Search](https://learn.microsoft.com/en-us/windows/win32/search/-search-3x-wds-qryidx-overview) functionality.
Something to note:
1. Searching by file content is not natively supported. Coco would search for all the columns (attributes/fields within the index) with this option:
```rust
SearchBy::NameAndContents => {
// Windows File Search does not support searching by file content.
//
// `CONTAINS('query_string')` would search all columns for `query_string`,
// this is the closest solution we have.
format!("((System.FileName LIKE '%{query_string}%') OR CONTAINS('{query_string}'))")
}
```
2. Tests have been added, but they failed in our CI for unknown reasons so I disabled them:
```rust
// Skip these tests in our CI, they fail with the following error
// "SQL is invalid: "0x80041820""
//
// I have no idea about the underlying root cause
#[cfg(all(test, not(ci)))]
mod test {
```
3. The Windows Search index is not real-time and can return obsolete results. Opening the returned documents could fail if the chosen file has been deleted or moved.
* chore: rename QuickLink/quick_link to Quicklink/quicklink
Standardize varaible naming to match the correct term: "Quicklink" and "quicklink".
This updates all incorrect variants such as "QuickLink" and "quick_link".
* chore: release notes
* chore: bump dep applications-rs
Currently Coco depends on atty v0.2.14, a crate that has
[vulnerability](https://github.com/infinilabs/coco-app/security/dependabot/25),
here is the dependency chain:
```
coco -> applications-rs -> freedesktop-file-parser 0.1.0 -> atty 0.2.14
```
I bumped the [`freedesktop-file-parser`](7bdb070e45)
crate in our applications-rs crate, which would eliminate the `atty` crate
from the chain to fix the vulnerability.
This commit bumps the applications-rs crate to include the above change.
* chore: release notes
* refactor: adjust extension code hierarchy
In this commit, I refactored the extension code structure.
* We can only install third-party extensions so the `store.rs` file should
belong to the `third_party` directory.
* Move tauri command `uninstall_extension()` to `extension/mod.rs` from
`third_party.rs` since one can uninstall an extension regardless of
how you installed it.
* Refactor the `install_extension_from_store()` function, add more
descriptive code comments.
Also, a trivial change, bump Rust toolchain and edition to use the
[let-chains](https://blog.rust-lang.org/2025/06/26/Rust-1.88.0/#let-chains) syntax.
* chore: release notes
* chore: replace meval-rs with our fork to clear dep warning
This commit replaces the meval-rs dependency with our
[fork](https://github.com/infinilabs/meval-rs). The original meval-rs
crate has not been maintained for a long time and uses nom 1.0, a crate
that was released 9 years ago, which would be rejected by future Rust
compiler because it contains outdated Rust syntaxes. This is the reason
why we are seeing the following warning:
```
warning: the following packages contain code that will be rejected by a future version of Rust: nom v1.2.4
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1
```
Switching to our fork would solve this warning.
* chore: release notes
