-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Long port names on Linux #106
Comments
It is usually the case that the client name will be contained in the port name, and I agree that this redundancy is bad, but I don't think this will always be the case. E.g. if you open a virtual port, you can give it any name, it doesn't need to contain the client name again. |
I've seen that virtual ports are handled differently. My current strategy is to remove the client part in case that it's identical to the start of the port name. I'm using this somewhat hacky function: fn cleanup_port_name(port_name: String) -> String {
#[cfg(target_os = "linux")]
{
if let Some((client_name, remainder)) = port_name.split_once(':') {
if remainder.starts_with(client_name) {
return remainder.to_owned();
}
}
port_name
}
#[cfg(not(target_os = "linux"))]
port_name
} If the port name is intended to be shown to end users, it can maybe formatted a bit nicer like putting the client name in brackets (if shown) instead of using colons as delimiters. I guess most end users have no idea what the client name is. I also thought about an addtional function e.g. |
When using Linux, the returned port name is much longer than with Windows/macOS. These long names force me to reserve more space in the GUI than needed just because of Linux users, which are a minority.
Example:
It is obvious that the second part "Arturia KeyStep 32 MIDI 1" including the port info needs to be returned, but the first part seems to be redundant.
When using
amidi --list-devices
the result is also "Arturia KeyStep 32 MIDI 1", the so called "client name" is omitted there.I already thought about manually splitting the parts using the colon as delimiter, but I think the colon is a valid character inside the port name, so this method is not 100% safe, even if I'm not aware of any device that's named in such manner.
The text was updated successfully, but these errors were encountered: