jeanne-paulette-sartresse commented 2025年12月19日 23:57:04 +01:00

Please tell me what do you think

For testing users

To allow for easier testing, i'd like to add features such as :

• Generic keyboard layouts, easily selectable
• A documentation for user, how to integrate libreDJ in a complete setup (how to connect pipewire, equis, libredj)
• Pre-compiled release package (flatpak, dnf, apt...)
• Ability to handle config without using CLI (In GUI or Files)

For Devs

To allow for easier collaboration betwen devs, i'd like :

• Minimal CI-CD to make dev collaboration more fluid & reliable
• Coding guidelines
• Fix warnings
• Better code & architecture documentation (doxygen ? wiki ?)

Please tell me what do you think ## For testing users To allow for easier testing, i'd like to add features such as : - [ ] Generic keyboard layouts, easily selectable - [ ] A documentation for user, how to integrate libreDJ in a complete setup (how to connect pipewire, equis, libredj) - [ ] Pre-compiled release package (flatpak, dnf, apt...) - [ ] Ability to handle config without using CLI (In GUI or Files) ## For Devs To allow for easier collaboration betwen devs, i'd like : - [ ] Minimal CI-CD to make dev collaboration more fluid & reliable - [x] Coding guidelines - [x] Fix warnings - [x] Better code & architecture documentation (doxygen ? wiki ?)

obsoleszenz commented 2025年12月25日 21:43:26 +01:00

For testing users

Generic keyboard layouts, easily selectable

a) I think adding keyboard bindings for other layouts is good, but can also happen as soon as people drop by
b) Easily selectable could be a good QoL improvement on first start. Maybe something like a setup wizard. But also would put ressources more onto improving jogwheel/waveforms/cadja integration. The user base i'm targetting right now is advanced users that are fine with editing config files until the core features are stableish.

Why targetting advanced users for now?

1. I want to focus our limited resources on the core features for now. Once they are stable we can start looking into other parts too but for this we need more developers. To get more developers on board i want to appeal to them. So creating good code base that is fun to hack on. Advanced users are fine with using env variables or config files for setting things up or using cadja/other tools to work around parts that libredj doesn't cover yet
2. LibreDJ has no internal mixing and is linux/jack only, so we anyways focus a bit on advanced djs. Routing through Jack/pipewire is a must for our software. For beginner/less techy people there's also mixxx.
3. Also i'm still not super settled on egui, it feels like a fine choice for now but probably it makes sense to switch to slint or gpui at some point. Therefore i also want to focus on the corecore features until the dust settles a bit more in rust gui land.
4. The current backend architecture might need some rethinking if we want to have good mouse support as the whole state of what's focused etc is held in the backend

A documentation for user, how to integrate libreDJ in a complete setup (how to connect pipewire, equis, libredj)

I like this. Would be good.

Pre-compiled release package (flatpak, dnf, apt...)

I think having a flatpak is enough for now. Should be portable enough. I myself don't want to maintain packages for various distros, flatpak will probably be a good amount of work already.

Ability to handle config without using CLI (In GUI or Files)

Low priority for now imo. See user base target.

For Devs

Minimal CI-CD to make dev collaboration more fluid & reliable

Would warmly welcome contributions on this. I think using nix would be good to reuse the flake.nix file for dev environments.

Coding guidelines

We have them already, basically what clippy says. Currently there are still some violations, but mainly in test code.

Fix warnings

I think most of them are fixed now

Better code & architecture documentation (doxygen ? wiki ?)

I would like to keep all documentation in the cargo docs. This way they are easily gittable. We can look into having typst/mermaid integration for graphs/math notation and stuff.

# For testing users > Generic keyboard layouts, easily selectable a) I think adding keyboard bindings for other layouts is good, but can also happen as soon as people drop by b) Easily selectable could be a good QoL improvement on first start. Maybe something like a setup wizard. But also would put ressources more onto improving jogwheel/waveforms/cadja integration. The user base i'm targetting right now is advanced users that are fine with editing config files until the core features are stableish. Why targetting advanced users for now? 1) I want to focus our limited resources on the core features for now. Once they are stable we can start looking into other parts too but for this we need more developers. To get more developers on board i want to appeal to them. So creating good code base that is fun to hack on. Advanced users are fine with using env variables or config files for setting things up or using cadja/other tools to work around parts that libredj doesn't cover yet 2) LibreDJ has no internal mixing and is linux/jack only, so we anyways focus a bit on advanced djs. Routing through Jack/pipewire is a must for our software. For beginner/less techy people there's also mixxx. 3) Also i'm still not super settled on egui, it feels like a fine choice for now but probably it makes sense to switch to slint or gpui at some point. Therefore i also want to focus on the corecore features until the dust settles a bit more in rust gui land. 4) The current backend architecture might need some rethinking if we want to have good mouse support as the whole state of what's focused etc is held in the backend > A documentation for user, how to integrate libreDJ in a complete setup (how to connect pipewire, equis, libredj) I like this. Would be good. > Pre-compiled release package (flatpak, dnf, apt...) I think having a flatpak is enough for now. Should be portable enough. I myself don't want to maintain packages for various distros, flatpak will probably be a good amount of work already. > Ability to handle config without using CLI (In GUI or Files) Low priority for now imo. See user base target. # For Devs > Minimal CI-CD to make dev collaboration more fluid & reliable Would warmly welcome contributions on this. I think using nix would be good to reuse the flake.nix file for dev environments. > Coding guidelines We have them already, basically what clippy says. Currently there are still some violations, but mainly in test code. > Fix warnings I think most of them are fixed now > Better code & architecture documentation (doxygen ? wiki ?) I would like to keep all documentation in the cargo docs. This way they are easily gittable. We can look into having typst/mermaid integration for graphs/math notation and stuff.