fontique 0.11.1 already supports fontconfig-dlopen, which leaves an empty system collection when Fontconfig is absent. OHOS registers /system/fonts explicitly, so the local fontique copy, patch queue and quality verification are no longer needed; use the crates.io package and keep the lockfile pinned.
Tier-3 community port (maintainer: springmin), rebased onto the merged
document-provider abstraction (#84) and the opener seam (#80).
- platform/ohos: Slint backend (XComponent window adapter, software renderer
with the experimental femtovg/wgpu path, input/IME, clipboard, system
fonts), the NAPI cdylib that builds a PlatformContext (app-private paths,
DocumentProvider over the ArkTS pickers, Asset Store credential store,
loopback OAuth broker, external URL opener, notification publisher) and
calls flectar_mail::run, the demo crate, the ArkTS shell and the build and
packaging scripts (bundle name configurable, defaults to
com.flectar.mail_ohos).
- src/platform/ohos.rs: PDFium directory, renderer name, thread priority,
preview lifecycle, email font directory; OpenHarmony stays under the
mobile capability alias.
- patches/fontique + crates/fontique: the Fontconfig opt-out as a patch queue
applied by the platform/ohos workspace, verified from quality.yml.
- .github/workflows/ohos.yml: manually dispatched tier-3 workflow, unsigned by
default, signing material only from the FLECTAR_OHOS_* secrets.
- src/documents.rs: run_request blocks the calling thread on mobile hosts;
the picker covers the window, and keeping the presentation thread idle is
what OpenHarmony needs (verified on device; desktop keeps the runtime
request for the native dialog).
- The email renderer and the compose editor load platform::email_font_dir()
and the Han fallback, so CJK mail bodies and composed text render with the
platform fonts.
- New-mail notifications: a publisher seam fed by CoreEvent::MailNew; the host
publishes through @kit.NotificationKit.
Compose attachments, account-backup export/import and database-snapshot
export still opened desktop file dialogs directly, so on mobile they
reported "no picker" even though the host provides a DocumentProvider.
- DocumentProvider::import_many() imports several documents for one action
(default: repeat import() until the picker is cancelled; the desktop
provider uses one multi-select dialog). Imported documents stay alive in
the composer until Core has staged the attachments.
- Compose attachments use import_many() instead of rfd::FileDialog.
- Backup export/import stage one app-private file and hand it to the
provider; the existing import logic keeps its synchronous shape on the UI
thread executor.
- Database snapshots keep Core's verified snapshot, archive it as one zip
(hosts export files, not folders) and pass it to the provider. Staging
stays outside the data/cache roots Core requires.
- Desktop behavior is unchanged: same dialogs and file names.
Tomás Romero
springmin