[Improvement] py-xiaozhi should be only a library

[joeda1]

I did expect this project is only a library to communicate with xiaozhi server. But it seems its much more because of the pyside6 dependency.

I suggest the following change:
Split the project in 2 projects, a library without pyside dependency and a demo client using the library. With that change its possible to use py-xiaozhi with Gtk+ or Tk.

Switch to english only will also help a lot. It's some kind of standard for open source projects and every developers knows english.

[huangjunsen0406]

Thanks for the feedback — the core ask is clear and useful.

On “library vs full client”

py-xiaozhi is intentionally more than a thin protocol client: it’s a cross-platform reference application / interaction framework (audio pipeline, wake word, MCP tools, activation, CLI/TUI/GPIO, optional GUI). That “batteries-included” surface is what many users and downstream projects (e.g. embedded / RDK setups) actually run.

At the same time, you’re right that UI toolkit choice should not block embedding. People should be able to drive the xiaozhi server stack from their own Gtk / Tk / other host without pulling Qt.

So long-term we aim for:

embeddable core + official reference clients in one project
— not “this repo becomes only a library and demos.”

Turning the whole repo into a bare library would drop the runnable reference path that validates the stack end-to-end. We don’t plan to do that.

On PySide6

PySide6 is already optional, not a hard runtime dependency:

# core / headless-friendly install (no PySide6)
uv sync
# or: pip install .

# GUI only when needed
uv sync --extra gui
# or: pip install '.[gui]'

You can run without GUI via CLI (and TUI/GPIO where applicable):

python main.py --mode cli

If the README / default entry still feel GUI-first, that’s a packaging & docs problem we’ll tighten — thanks for calling it out.

On splitting into two repositories

Splitting into library + demo client as separate git repos is a possible later packaging step, not the first one.

Near/mid term we’re more likely to:

1. Keep this monorepo as the source of truth (protocol + audio + app still move together while the stack is evolving).
2. Carve a stable, documented public API for non-UI use (connect / session / events / send-receive), with minimal examples that don’t import any UI toolkit.
3. Keep GUI behind extras (as today); make headless / embed usage obvious in docs.
4. Revisit separate packages or repos only once that API is stable and real external consumers need a thinner dependency boundary.

That gets you Gtk/Tk (or any host) integration without paying the dual-repo sync tax too early.

On English-only

Agreed that public API, examples, and primary technical docs should be English — that’s the default for reusable OSS surfaces.

We’ll keep bilingual user-facing docs (EN + 中文) rather than drop Chinese entirely: a large part of this project’s community and downstream use is CN-facing, and bilingual is a better fit than English-only.

Practical next steps (no big-bang rewrite)

• Clarify project positioning in the README: reference app and embeddable core.
• Improve headless / library-style onboarding (examples without PySide6).
• Reduce “GUI by default” friction where it still confuses install expectations.
• Grow a small public client surface people can import without UI deps.

I don’t want to over-promise dates here, but the direction is: decouple UI from core, document embed use, keep the full client — not abandon the app for a pure library split on day one.

If you have a concrete host in mind (Gtk app, custom daemon, etc.), feel free to share what API shape you’d want first (connect, audio callbacks, text events, …). That helps prioritize the public surface.

Thanks again for writing this up.