Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Introduce `baseview-core` crate for a common, more stable API for other crates to re-export

Ouverte
  • Quelque chose ne va pas ?
#343 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
rust
Domaine
backend

Piste de recherche

Start by reading the baseview crate’s public API and the GUI integration crates mentioned in the issue, egui-baseview and iced-baseview, to see which types they wrap or re-implement. Then identify which APIs are stable utilities for plugin use and which depend on WindowHandler and GUI adapters. Done means a proposed baseview-core crate boundary and trait-based API that reduces this duplication while supporting the compatibility goal.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Currently, GUI framework integration crates (such as egui-baseview and iced-baseview) have to either wrap or re-implement a lot of baseview's types if they want to expose them in their public APIs, just to shield themselves from semver-incompatible baseview releases (even though the aforementioned APIs actually rarely change, compared to e.g. WindowHandler APIs).

This results in a lot of tedious and ultimately unnecessary code that those crates have to implement and maintain.

This is because the baseview crate currently acts as a bridge for two different sides: the GUI implementation/framework adapter side, and the plugin/plugin framework/host side.

We could create a new baseview-core (name TBD) crate that would expose the more stable utilities and APIs as traits for plugins to use directly, while leaving out the WindowHandler & co. APIs only for GUI implementations (and/or framework adapters) to use.

Ideally, plugin frameworks such as Nice-Plug could potentially even support spawning and managing any type of Window that implements baseview-core traits, making any-to-any compatibility between plugin frameworks and GUI frameworks possible.

Langage dominant
Rust
Étoiles
387
Forks
128
Merge moyen
3 j 2 h
PR mergées (30 j)
15

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de RustAudio/baseview

Toutes les issues de RustAudio/baseview

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.