Welcome to cursive Discussions!

[gyscos]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[1pinus]

I had the version 0.14 and used a horizontal linear layout (3x text views) with align left, center and right to format a line like:
left<----->center<----->right
That doesn't seem to work with 0.15. How to do that?

[gyscos]

Hi! What doesn't work? Does something not compile?

[1pinus]

Works with 14 but not with 15

let mut app = Cursive::default(); 

    let button_line1_layout = LinearLayout::horizontal()
        .child(f1.align_top_left())
        .child(Button::new("F2 asdf", |s| s.quit()).fixed_size(footer_button_size).align_top_center())
        .child(Button::new("F3 asdf", |s| s.quit()).fixed_size(footer_button_size).align_top_right())
        .align_top_right()
        ;

[gyscos]

• In cursive 0.15 (and cursive 0.16) you need to either:
  • cursive::default() instead of Cursive::default()
  • use cursive::CursiveExt to bring the "default()" method back to Cursive.
• You use the cursive-aligned-view crate, which has not quite been updated to cursive 0.16 yet (but cursive 0.15 should work fine).
• In addition, there is currently a bug in enumset (one of the dependencies of cursive 0.15) which means you need a workaround, for example pinning the version of a nested dependency. Note that this is only required for cursive 0.15, not cursive 0.16.

[dependencies]
syn = "=1.0.57"

EDIT: I pushed 0.15.1 which backports the fix, so running cargo update should fix this enumset/syn issue.

[1pinus]

Thanks for the fix. What about the align* functions? How should I create a layout with where the arrows stretch depending on the screen size?

left<----->center<----->right

How can I do that?

[gyscos]

These functions were never part of Cursive itself, but of another crate: cursive-aligned-view. This crate should still work well with cursive 0.15 (it hasn't been updated to cursive 0.16 quite yet).

[lennart-finke]

Hi folks,

I built a painting application with cursive and wanted to share somewhere. It would be cool if you could give it a look, maybe even give a little feedback. It's been very fun to put together and I'm happy with the result so far, so maybe it might even deserve a spot on showcases thing. Thanks for the pretty library!

[masklinn]

I've just started playing with Cursive for some personal stuff, and I had a bunch of issues / concerns / questions, not quite sure whether I should open issues for any / some / all of them (some I can probably work a PR for as well), so I guess this is as good a place as any to ask? Probably better than issues for minor clearly-bug issues:

• What is the proper way to update lists and layout lists? ListView is fairly restrictive in its structure (what with mandating a label) so I've been using LinearLayout a lot, but it's really not convenient to update the internal bits on the fly, and also seems way slower than ListView (I've had to switch some things from ListView to LinearLayout, and the program became basically unusable in debug whereas it'd been fine using ListView).

• HideableView::hide/HideableView::unhide not being chaineable seems like a waste in terms of convenience: I'd expect get;show;update to be a fairly common use of it, but it can't be done in that order (though I guess with allows it the other way around), anyway lots of Cursive APIs are chainable (though I guess mostly on the declarative side) so it seems a bit weird that HideableView's "procedural" API has very little support for that.

• Is it possible to have a nicer bordering on cursive? on macOS, using both ncurses and termion backends I get this:
  
  which is way worse than the official screenshots. tui has "correct" borders using the termion backend.

• Is there any way to run a callback at application start? Or have SelectView run on_select at initialisation, since it does select the first item? Currently my hack is to set_autorefresh(True), and in the callback forcefully set_selection() of the relevant view, run the callback, then clear the autorefresh callback and set_autorefresh(False).

• ListView::add_delimiter doesn't seem to work correctly when interspersing delimiters between list item, I'm not sure how to debug this but on my system:

  • There's a ton of space between the first and second items.
  • The last item is straight up broken (unless it's also the first), it has no content and the label is sometimes corrupted (or possibly anything from the third item overlap with no content).
    My current workaround is to add an item with an empty label and DummyView instead but...

• SelectView().resized(Full, _) doesn't seem to take the entire width of the screen / terminal, it's a bit weird. The scroll bar is all the way to the right, but the selection background basically stops at the width of the largest label.

• Click will focus + click, that's a bit annoying when using a SelectView as re-focusing the SelectView using the mouse will also change the selection, is there a clean way to suppress this?

• Is there any way or plan to have focusable / activable items inside TextView / SpannedString? e.g. links and friends.

• The Big List Of Views is rather unclear as it doesn't really separate content / functional views from structural views from wrappers, and specific subviews (e.g. RadioButton) are part of that list despite not really being useful in and of themselves.

  Would you be OK with a PR trying to move the modules around in order to provide a better classification, or replacing the default listing by a big docstring doing that?

• And then I found a bunch of concerns or things not working right in markdown support, the original markdown issue indicates that it's mostly built-in (rather than a separate crate) for convenience, is that still the intention? Issues I have with the markdown compiler (aside from a few things I'm almost certain are bugs and thus I need to create repro cases to report them properly):

  • Links are rendered as-is, but because text is not selectable (possibly a platform issue? or it intercepts clicks for focus?) showing the URL doesn't seem that useful (especially without inline activable items), maybe just the label should be showed at least as an option?
  • An option to render soft line-breaks (single \n) as spaces (aka not the GFM style) would be nice, some content is not in GFM style and doesn't look good when "unjoined". Joining the source by hand is problematic as it breaks a lot of markup.
  • Inline code items (`foo`) are completely unstyled which is confusing.
  • I don't remember where but I saw concern about rendering to a different markup than the source as pulldown-cmark doesn't keep style information (e.g. ATX versus Setext header). Not only do I think it's a good thing, I think it should be done more, namely code blocks should be rendered as indented not as fenced despite FCBs probably being more common in source material: FCBs are really convenient when writing, but when reading they're verbose and harder to parse out of plain text.
  • Any chance the markdown support could be expanded to full views in order to support tables?

[masklinn]

What API from ListView are you missing in LinearLayout? You can get , insert, remove, or swap views given their indices. Would you need to access the children as a slice/iterator?

Going back through my code, it looks like it's mainly clear I missed, though because of the performance issues I've since reverted to the listview.

Something like that?

let inner = my_hidden_view.with(HiddenView::hide).get_inner();

Oh yeah good point, I was thinking my_view.with(|v| v.get_inner_mut().//modify here).unhide(). According to my notes the context / thinking is mostly that when unhiding a view you'd usually update its contents somehow, so it'd make sense for those to be easily chainable.

It might also depend on the font used? I think launchk was has a screenshot from what I believe is a macOS device, with slightly better borders (though still not quite as seemless as on my terminal with the DejaVu Sans Mono Book font).

Could be Monoid. But ignore this, I mentioned it because I'd thought I'd not seen that issue with tui (so assumed it was cursive-specific), but I just re-ran a pair of tui examples to make sure (and to provide a comparison screenshot) and turn out it's the exact same behaviour, i don't know what occurred to me that I noticed it in cursive and not in tui (possibly the default color scheme, or lack thereof, of tui). Or possibly that i was thinking about something else which used the box-drawing characters? Regardless, sorry about that.

At application start = when you run Cursive::run, so you can run any callback right before that (but still after adding all the views). You can also get the cb_sink from cursive and send callbacks there before starting the event loop, they will be processed when you call Cursive::run.

Is that an option? I wasn't quite sure about the implications there, and whether views would "work" before the application was started.

Sounds like it's a bug? If you have some example code I could have a look.

I'll try to build a repro case and open an issue then.

You can right-click to focus but not submit.

Might be good enough.

You'd like a way to only be able to submit already-focused items (effectively requiring a double click to change focus + click)? I can look at something like that.

Mostly I was wondering if the events-dispatching could be canceled partway DOM-style (e.g. if it was possible to intercept the event, let the focus through and prevent the click). It's not a big deal though, most interfaces do do the same, I don't know why it surprised me so. Possibly because it doesn't occur when switching between different applications on macos, but here it's the same application so…

It's not currently planned, but only because I didn't think about it yet.

OK, sure.

Especially since opening links in an external program (like xdg-open) is not a trivial thing (like when running the program and the terminal emulators on different machines).

Good point. Well it's easy to do by shelling out do open/xdg-open/start I guess, but that's not so portable (though as often I think there's a crate handling picking which one should be attempted).

Though it should already be possible to implement a third-party "browser" view, which parses the links from the text and lets user navigate between them. For a regular TextView? I'm not sure.

Good point.

Yeah I'm still trying to figure a better namespacing for that, without having too deep a hierarchy. Better guides/documentation is another solution to make the current flat hierarchy more manageable. I guess splitting between "leaf" views, "group" views and "wrapper" views could be a first step? There will always be less clear-cut decisions (like Dialog: is it a group, or a wrapper?), but overall I agree things could be better.

Yeah that's about what I was thinking, though for "group" I was thinking more "structural", and the "wrappers" are mostly behavioural views which are not strictly visible (e.g. naming, sizing, hiding, scrolling, those which are usually invoked through convenience methods rather than explicitly I guess?). In that sense Dialog would be structural / layout, same as the ListView or LinearLayout.

That may be terminal emulator specific. On gnome-terminal, links are hoverable, become underlined and change the mouse cursor, and ctrl+click opens the link in the browser.

Ah, macOS's built-in terminal is probably too dumb for that yeah.

Does text selection inside text views work in gnome-terminal though? Or is that intercepted by the cursor handling?

I'm not aware of a better way to send links to the terminal emulator, but I'm open to improvements.

Yeah I don't think VT200 (or whatever) has that concept, which is why I suggested having an option to just strip out the linky bits entirely. Or maybe move them to a "footer" location, like "external" markdown links?

Overall, the current markown parser was really a minimal effort, meant to test, inform and motivate the development of styled text. I'd be totally up for either splitting it in a separate crate, making it easier for non-cursive-experts to contribute, or just improving it in-place to make it more useful. More options, support for tables, and all the other ideas sound great!

OK

[gyscos]

Going back through my code, it looks like it's mainly clear I missed, though because of the performance issues I've since reverted to the listview.

Arf indeed! I guess right you can remove children one by one until the list is empty, but a clear() method would certainly be nicer. Should come soon.

Or possibly that i was thinking about something else which used the box-drawing characters? Regardless, sorry about that.

These characters are supposed to be box drawing characters. Though note that it does rely on unicode support (the locale, terminal emulator and font must all support unicode).
Some ncurses applications use a different magic to get the same behavior on non-unicode locales, but it's usually overkill when utf-8 locales are the norm nowadays.
If you do find an application that renders better blocks with the same terminal/font, I'd be interested in looking at the differences.

Is that an option? I wasn't quite sure about the implications there, and whether views would "work" before the application was started.

The only thing that will not "work" before actually running are things size-related, so scrolling, or anything that depends on the size is going to be in a possibly not-ready state. But regular callbacks should be fine. Note that you don't even strictly need the view to be attached to the Cursive root to manipulate it, and that includes getting callbacks from it, and feeding them separately to Cursive. Though obviously anything that relies on the view actually being there would fail (like running Cursive::run_on_name and so on).

If you do need the sizes and everything, you can do a bit of manual manipulation:

// Create your cursive runnable as always
let mut siv = cursive::default();

// Prepare the cursive view tree

// Turn our cursive root into a runner.
let mut siv = siv.into_runner();

// Run a single step, where we give views their correct sizes.
// This will not trigger any callback.
siv.refresh();

// HERE your views are as expected. They will have a correct size (at least for the current terminal size) and so on.

// Then just let the runner run itself. This will start processing callbacks.
siv.run();

Mostly I was wondering if the events-dispatching could be canceled partway DOM-style (e.g. if it was possible to intercept the event, let the focus through and prevent the click). It's not a big deal though, most interfaces do do the same, I don't know why it surprised me so. Possibly because it doesn't occur when switching between different applications on macos, but here it's the same application so…

So technically the mouse press causes the focus switch, and the mouse release causes the "submit" action. You can "intercept" (add an event listener) to either of these events, and filter/block the event (so it's not sent to the SelectView at all), or just run something else instead (show a confirmation popup, ...).

Good point. Well it's easy to do by shelling out do open/xdg-open/start I guess, but that's not so portable (though as often I think there's a crate handling picking which one should be attempted).

Right, but a lot of use-cases for terminal application is to run them through SSH from another machine, and xdg-open cannot handle that.
For cases where we're running locally, we could have something, but because of this limitation, I'd rather make it opt-in/in a separate crate than part of the core lib.

Does text selection inside text views work in gnome-terminal though? Or is that intercepted by the cursor handling?

While mouse mode is enabled (which cursive does with most backends), the default mouse text selection is disabled, but pressing "Shift" bypasses the mouse mode and lets the user select code normally. And with Ctrl, "block" selection is enabled, which lets users select the content of a text view in the middle of the page, without the borders and other stuff.
One reason to let the terminal emulator handle that is the copy/paste buffer: again since the application may run on a different machine than the terminal emulator, we can't easily "insert" the selected text into this buffer, we really must let the terminal emulator select (and copy) the text itself. It happens that gnome-terminal has this nice Shift and Ctrl modifiers, not sure about other terminals. :^/

[masklinn]

Or possibly that i was thinking about something else which used the box-drawing characters? Regardless, sorry about that.

These characters are supposed to be box drawing characters. Though note that it does rely on unicode support (the locale, terminal emulator and font must all support unicode).
Some ncurses applications use a different magic to get the same behavior on non-unicode locales, but it's usually overkill when utf-8 locales are the norm nowadays.
If you do find an application that renders better blocks with the same terminal/font, I'd be interested in looking at the differences.

I'll keep an eye out, but I probably got confused. Possibly between my personal mac and the work laptop (whose terminal I don't think I swapped to monoid).

Is that an option? I wasn't quite sure about the implications there, and whether views would "work" before the application was started.

The only thing that will not "work" before actually running are things size-related, so scrolling, or anything that depends on the size is going to be in a possibly not-ready state. But regular callbacks should be fine. Note that you don't even strictly need the view to be attached to the Cursive root to manipulate it, and that includes getting callbacks from it, and feeding them separately to Cursive. Though obviously anything that relies on the view actually being there would fail (like running Cursive::run_on_name and so on).

Sounds pretty much fine, the issue I had was that the select is linked to a "display" view for the corresponding content, and the on_select is used to update the linked view. So on load the first item of the select would be, well, selected, but the callback wouldn't fire so its content would not be displayed (and the "display" view would be empty).

I don't do any size querying, just creating and filling the relevant views, so should be fine.

Mostly I was wondering if the events-dispatching could be canceled partway DOM-style (e.g. if it was possible to intercept the event, let the focus through and prevent the click). It's not a big deal though, most interfaces do do the same, I don't know why it surprised me so. Possibly because it doesn't occur when switching between different applications on macos, but here it's the same application so…

So technically the mouse press causes the focus switch, and the mouse release causes the "submit" action. You can "intercept" (add an event listener) to either of these events, and filter/block the event (so it's not sent to the SelectView at all), or just run something else instead (show a confirmation popup, ...).

Ok, thanks.

Good point. Well it's easy to do by shelling out do open/xdg-open/start I guess, but that's not so portable (though as often I think there's a crate handling picking which one should be attempted).

Right, but a lot of use-cases for terminal application is to run them through SSH from another machine, and xdg-open cannot handle that.
For cases where we're running locally, we could have something, but because of this limitation, I'd rather make it opt-in/in a separate crate than part of the core lib.

Completely fair, and I don't think this should at all be handled by Cursive, I was just wondering about the inline-activable-bits (which would be under Cursive's purview) and links were an obvious example (as I was dealing with markdown content with links).

Does text selection inside text views work in gnome-terminal though? Or is that intercepted by the cursor handling?

While mouse mode is enabled (which cursive does with most backends), the default mouse text selection is disabled, but pressing "Shift" bypasses the mouse mode and lets the user select code normally. And with Ctrl, "block" selection is enabled, which lets users select the content of a text view in the middle of the page, without the borders and other stuff.

Ah yes, it looks like on macOS (or at least the bundled Terminal) that's Fn to bypass mouse mode, I don't think I'd ever wondered about this so I had no idea. More learning!

One reason to let the terminal emulator handle that is the copy/paste buffer: again since the application may run on a different machine than the terminal emulator, we can't easily "insert" the selected text into this buffer, we really must let the terminal emulator select (and copy) the text itself. It happens that gnome-terminal has this nice Shift and Ctrl modifiers, not sure about other terminals. :^/

Yup, makes sense.

[gyscos]

I just tried installing the monoid font, and this is the result:

The issue may be with some other setting (are you changing the inter-line spacing? Or the font width?), or with the terminal emulator itself. Or maybe the system-wide font hinting? There's a lot of moving pieces in font rendering :(

[masklinn]

I just tried installing the monoid font, and this is the result:

The issue may be with some other setting (are you changing the inter-line spacing? Or the font width?), or with the terminal emulator itself. Or maybe the system-wide font hinting? There's a lot of moving pieces in font rendering :(

OK thanks for testing. I just checked, the character and line spacing are at 1 (which I assume is the default though I've no idea). Most monospace fonts don't create seamless borders though a few do do (hasklig, fira). I guess it's a terminal issue.

As I don't have iterm I figured I could try running in cathode, and while that generates results I could call interesting (Cursive does not like working at 9600 bps, and seems to repaint the screen multiple times per event, pressing Esc to quit triggers 3 full repaints before finally exiting, and apparently the terminal is too slow for going down the list to work at all, keeping the "down" key pressed just keeps refreshing the screen in a loop), the borders are not continuous either..