This commit refactors the code that evenly collects documents from query
sources to let it collect at least 2 documents in every source, which
could correct the case when `max_hits_per_source` is 0. This was possible
with the previous impl, no longer allowed after this commit
* refactor: custom_version_comparator() now compares semantic versions
Previously, when comparing 2 versions, custom_version_comparator() only
compared their build numbers, which was incorrect. See this case:
```text
0.8.0-2500 -> 0.9.0-SNAPSHOT-2501 -> 0.8.1-2502
```
Coco adopts SemVer[1], and according to the specification, "0.8.1-2502"
is older than "0.9.0-SNAPSHOT-2501" even though it has a larger build
number.
This commit refactors it to compare the semantic versions.
[1]: Even though Coco uses SemVer, our version string does not follow the
spec. In this implementation, we use `to_semver()` to do the conversion, see
the code comments for more details.
* correct comments
Extract a procedure that calls convert_pages() to process HTML files
into a function. It is used in both install/store.rs and
install/local_extension.rs, doing this avoids code duplication.
This commit:
1. Bump dep tauri_nspenel to v2.1
2. On macOS, our main window is not a window but panel. Previously, we
were using window.show() and window.hide() in show_coco() and
hide_coco(). In this commit, we switch from window.show/hide to
panel.show/hide
Co-authored-by: ayang <473033518@qq.com>
* chore: use a custom log directory
This commit changes our log dirctory from the one set by Tauri to
a custom one. It is mostly the same as Tauri’s one, except that
the "{bundleIdentifier}" will be "Coco AI" rather than the real
identifier.
We are doing this because our bundle ID ("rs.coco.app") ends with ".app", log
directory "/Users/xxx/Library/Logs/rs.coco.app" is mistakenly thought as an
application by Finder on macOS, making it inconvenient to open. We do not want
to change the bundle identifier. The data directory, which stores all the data, still
references it. So doing that will be a breaking change. Using a custom log
directory make more sense.
* fmt
Take the 'Spotify Control' extension as an example:
- Spotify Control
- Toggle Play/Pause
- Next Track
- Previous Track
Previously, these sub-extensions were only returned when the query string
matched them, and thus counterintuitively, searching for 'Spotify Control' would
not hit them.
This commit changes that behavior: when a main extension (of type Extension)
matches the query, all of its sub-extensions are now included in the results.
When the expression to evaluate contains only a number, the result is
guaranteed to be this number. In this case, we no longer evaluate the
expression as telling users that "x = x" is meaningless.
Found another case where the `NextDisplay` command does not work (I said
another because the bug that commit ca71f07f3a3cc[1] fixed was also found
by playing with the `NextDisplay` command). After debugging, the root cause
of the issue is that the macOS API `AXUIElementSetAttributeValue()` does
not work in the expected way.
> When I execute the `NextDisplay` command to move the focused window from
> a big display (2560x1440) to a small display (1440*900), the window size
> could be set to 1460.
I don't know why it does not work so the only thing we can do is to retry.
Luckily, retrying works, at least in my tests.
[1]: ca71f07f3a
This commit fixes the issue that when the current desktop contains more
than 1 windows, moving the focused window via `NextDesktop` and
`PreviousDesktop` won't work.
How? By adding 2 missing `sleep()` functions:
1. b91a18dbb8/Silica/Sources/SIWindow.m (L242)
2. b91a18dbb8/Silica/Sources/SIWindow.m (L249)
Also, this commit improves the implementation by resetting the mouse position.
`NextDesktop` and `PreviousDesktop` are implemented by emulating mouse and
keyboard events, draging the focused window and switching to the corresponding
desktop. To make a window draggable, we have to move the mouse to the window's
traffic light area. It is disturbing to not move the mouse back so this commit
implements it.
This commit fixes a bug that most Window Management extension commands
won't work if you:
1. operate the focused window from another display
2. and they are adjacent
To reproduce this:
say you have 2 displays
1. Put the focused window on a non-main display, maximize the window
2. Move the mourse to the main display, making it the active display
3. Launch Coco, then execute the `TopHalf` command
The focused window will be moved to the main display, while it should
stay in the non-main display.
The root cause of the issue is that the previous implementation of
`intersects()` didn't handle an edge case correctly, adjavent rectangles
should not be considered overlapping. This commit replaces the buggy
implementation with the `CGRectIntersectsRect()` function from macOS
core graphics library.
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.
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"],
}
]
}
```
