pfr Else, I have a GUI Spotify client in the works 
Don't know how much time I'll have for it in the coming two weeks or so. It might take a while.
No need to change the patch as both backends will be affected. You can at least use your Spotify account and listen to music. I'd argue that still is the most important functionality.
pin Else, I have a GUI Spotify client in the works
Don't know how much time I'll have for it in the coming two weeks or so. It might take a while.
No worries, I look forward to testing it once its ready 
pin You can at least use your Spotify account and listen to music. I'd argue that still is the most important functionality.
I agree! So happy about this 
This initial analysis is not entirely accurate. For the correct analysis, follow the discussion in this pull request.
I've looked into this a bit more, and this mojibake is caused by passing UTF-8 line-drawing chars. to ncurses functions which take old-fashioned ASCII text.
For example, take the print_hline and print_vline functions in cursive, which are used to draw horiz. and vert. lines for boxes. These functions pass a UTF-8 char for the bar char. The print_hline and print_vline functions call print_at or print_at_rep which in turn call the backend's mvaddstr(). Which, is wrong.
The curses mvaddstr() or addstr() only accepts ASCII or VT100 line-drawing chars. For writing UTF-8, curses provides different functions: add_wchstr() and mvadd_wchstr(). But, here's the rub: the backends don't implement these functions.
What's to be done, then?
1. The correct solution is to fix both the backend (ncurses, pancurses, ...) and cursive to call the UTF-8 aware functions.
2. As a hack, patch cursive to send ASCII chars. for the glyphs down to the backends instead of UTF-8 ones. This should be trivial to do. I'll do it--if nobody else does it.
rvp I would prefer the first solution and things to be fixed in those crates.
Just out of curiosity,...
Why the hell is this not happening on Linux? Or, on OpenBSD?
The main dev for ncspot is also the port maintainer for OpenBSD, I guess he'd have noticed. And if it was happening on Linux, there would be a lot more issues open.
I understood what you wrote and I'm not questioning it. But obviously there must be differences, else all systems should be affected.
I wonder what happens on FreeBSD or even on MacOS or Windows 
pin Why the hell is this not happening on Linux? Or, on OpenBSD?
This is one yak which I can shave:
See the last line of the BUGS section of the NetBSD's setlocale man-page. Rust binaries are all statically linked, I think(they are not--only the rust-y portions are). The same problem affects C code too--setlocale doesn't switch to a UTF-8 locale for static binaries.
I've submitted your analysis upstream: https://github.com/gyscos/cursive/issues/494#issuecomment-678758723
Personally I hope to see it fixed properly and switched to wchar aware functions.
kamil Personally I hope to see it fixed properly and switched to wchar aware functions.
Looks like I was wrong in my analysis--and wchar-aware functions won't need to be implemented after all.
Not being familiar with Rust, I was unsure about what the string-like constanst I saw were: Unicode or UTF-8.
I was also wrong about Rust producing static binaries. Which means that as long as setlocale() can be called from Rust, UTF-8 bytes can be used with the ncurses addstr() and mvaddstr() functions.
I modified the example code in Tutorial 2, above, to call setlocale(), and... no mojibake!
Here's the diff:
diff -u src/main.rs{.orig,}
--- src/main.rs.orig 2020-08-23 12:38:57.923805228 +0000
+++ src/main.rs 2020-08-23 12:40:00.565448799 +0000
@@ -1,7 +1,11 @@
use cursive::Cursive;
use cursive::views::Dialog;
+use std::ffi::CString;
fn main() {
+ unsafe {
+ libc::setlocale(libc::LC_ALL, CString::new("").unwrap().as_ptr());
+ }
let mut siv = cursive::default();
siv.add_layer(Dialog::text("This is a survey!\nPress <Next> when you're ready.")@pin, can you add a setlocale() call like that to ncspot? Then, you can get somewho knows Rust to do a proper patch.
PS. How to do I edit my old posts? I'd like to put a strikethrough through that text so that people are not misinformed.
rvp just click the 3 dots on the lower right hand corner of your post and pick Edit 
I'm a bit confused... where should this patch apply? I can't seem to find this code trunk on ncspot/src/main.rs?
If you mean patch a crate, I believe this should be done upstream. Unless, I'd package that crate stand alone, i.e. outside of ncspot and I don't really want to do this.
Self-reminder, stay away from rust as much as possible.
pin I've applied the suggestion from @rvp in https://www.unitedbsd.com/d/233-spotify/54 and committed to pkgsrc as ncspot 0.2.1nb1
Borders are printed now in order. @pin please submit upstream our patch from pkgsrc and ask upstream to either merge it or apply in a more proper rusty way.
Wow, nice progress.
I'm back online with a fresh NetBSD install. Haven't installed rust/nscpot yet, I'll wait until the patch is merged I think, unless you need me to fully test it with a real login.
pin Yeah, but I've got some tweaking to do anyway before I start breaking shit again 
pin I just cant help myself. I'm like a kid in a candy shop, when I see something cool and I try to install it without RTFM first!
I'm also terrible at typing so I make a LOT of typos. This is why it took me nearly a whole day to get my system back up and running #npf=YES. Well, that and my 15 month old screaming for attention while daddy sits at his computer all day... 
Keeping this system under 200 pkgs I swear 
In order to get a GUI Spotify client working on NetBSD, we need a package for librespot.
librespot is a dependency crate of ncspot which, we have been discussing on this thread.
librespot compiles fine when building ncspot but, fails to build for me when attempting a stand alone package 
I've commited the initial work to wip, ...in case anyone else can figure out a solution.
wip-commit link.
EDIT: Requesting suggestions at tech-pkg, https://mail-index.netbsd.org/tech-pkg/2020/08/24/msg023709.html
