Previously, the last update time of the Coco server in the
"Connect" settings page was displayed using the raw string
directly from the `updated` field, which lacked consistent
formatting.
This commit refactors the `ServiceMetadata` component to use
the `formatDateToLocal` utility function. This ensures
the update time is displayed in a standardized
`YYYY/MM/DD HH:mm:ss` format and provides a fallback value if
the date is invalid or missing.
* fix: apply local results weight to scores generated by rerank()
We have two kinds of scores:
1. Scores calculated by query sources
2. In the post-search phase, we re-score the documents in
`boosted_levenshtein_rerank()`
When applying the setting "local search results weight", previous
implementation modified the first score. Its effect was not noticeable,
since we collect documents evenly from the hits returned by query sources.
This commit refactors the implementation so that the setting adjusts the
second score, making the effect obvious.
* refactor: keep O(1) lookup && update var names
* chore: one more var name to update
* feat: support app search even if Spotlight is disabled
Previously, we relied on Spotlight (mdfind) to fetch the app list,
which means it won't work if users disable their Spotlight index.
This commit bumps the applications-rs library, which can now list
apps using `lsregister`, macOS's launch service tool. (See commit [1]
for details). With this, our app search works even tough Spotlight
is disabled.
[1]: ec174b7761
* release notes
* refactor: display doc.{updated,created} in local time
Previously, document created/updated times were displayed as raw
strings, and can be in UTC, which was not user-friendly.
This commit adds a helper function `formatDateToLocal()` that formats
date to a local time string, then uses it to unify the date formatting
in application and document details.
* chore: address review comments
I was digging into an issue that the "File Search" extension does
not appear in the extension list under some cases, then I realized
that, in list_extensions(), "File Search" is another extension that
needs to be processed separately, just like the "Applications"
extension.
Both extensions are of type group/extension, which semantically should
behave like a folder, i.e., they contain sub-extensions, but they
do not. In our implementation, they are more like command extensions.
So we treat them as normal extensions in list_extensioins().
Coco's version string does not adhere to semver's spec, so we had to
write a custom deserialization impl to do the conversion:
```
0.9.1-SNPASHOT-2560 => 0.9.1-SNAPSHOT.2560
```
But we forget to serialize versions to Coco's format when writing
extensions to disk. When Coco reads extension from disk, it sees
valid semantic versions, which are not expected:
```
[WAR] [third_party:167] invalid extension: [base64-converter]:
field [minimum_coco_version] has invalid version:
failed to parse build number 'SNAPSHOT.2560'', caused by: ['invalid digit found in string']
```
This commit provides a custom serialization impl to fix the issue.
* chore: show error msg (not err code) when installing exts via deeplink fails
When installing extensions via deeplink fails, previous implementation
showed the raw error code returned from the backend interfaces, which
is not user-friendly. We now call installExtensionError() to interrupt
the error code to get a human-readable error message, then show it to
the users.
* fix: correct install extension error when installing via store
* feat: add selection window page
* fix: chat input
* feat: add selection page
* chore: add
* chore: test
* feat: add
* feat: add store
* feat: add selection settings
* chore: remove unused code
* docs: add release note
* docs: add release note
* chore: format code
* chore: format code
* fix: copy error
* disable hashbrown default feature
* Enable unstable feature allocator_api
To make coco-app compile in CI:
```
--> /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/hashbrown-0.15.5/src/raw/mod.rs:3856:12
|
3856 | impl<T, A: Allocator> RawIntoIter<T, A> {
| ^^^^^^^^^
|
= note: see issue #32838 <https://github.com/rust-lang/rust/issues/32838> for more information
= help: add `#![feature(allocator_api)]` to the crate attributes to enable
= note: this compiler was built on 2025-06-25; consider upgrading it if it is out of date
```
I don't know why it does not compile, feature `allocator-api2` is
enabled for `hashbrown 0.15.5`, so technically [1] it should not use the
allocator APIs from the std. According to [2], enabling the `nightly`
feature of `allocator-api2` may cause this issue as well, but it is not
enabled in our case either.
Anyway, enabling `#![feature(allocator_api)]` should make it work.
[1]: b751eef8e9/src/raw/alloc.rs (L26-L47)
[2]: https://github.com/rust-lang/hashbrown/issues/564
* put it in main.rs
* format main.rs
* Enable default-features for hashbrown 0.15.5
* format main.rs
* enable feature allocator-api2
* feat: add selection set config
* fix: selection setting
* fix: ci error
* fix: ci error
* fix: ci error
* fix: ci error
* merge: merge main
* fix: rust code warn
* fix: rust code error
* fix: rust code error
* fix: selection settings
* style: selection styles
* style: selection styles
* feat: selection settings add & delete
* feat: selection settings add & delete
* feat: selection settings add & delete
* style: selection styles
* chore: add @tauri-store/zustand plugin
* refactor: the selection store using @tauri-store/zustand
* fix: data error
* fix: data error
* chore: remove config
* chore: selection
* chore: selection
* chore: width
* chore: ignore selection in the app itself
* style: selection styles
* style: remove
* docs: add notes
* chore: add permission check
* chore: selection
* chore: style & store
---------
Co-authored-by: Steve Lau <stevelauc@outlook.com>
