gyscos / cursive Goto Github PK
View Code? Open in Web Editor NEWA Text User Interface library for the Rust programming language
License: MIT License
A Text User Interface library for the Rust programming language
License: MIT License
Printer for example takes sometimes the position first, sometimes the character. What's the most convenient one?
Define at runtime some colors and characters used for special effects (border, highlight, shadow, ...).
Probably provide a default theme that looks like the blue interface used by classic ncurses dialog applications.
Either something like AlsaMixer, or one that looks like the current scrollbars.
Instead of polling.
And select on both the event and the callback channels.
Maybe also on a third refresh channel?
(One goal is to eliminate the need for a refresh rate in most cases, by sending a refresh signal instead.)
Loading from a file is nice during development to experiment with the look without having to recompile, but to deploy an application, it's easier to include the theme in the binary.
Adding a method to load the theme directly from a string (rather than a filename as is currently the case) would allow users to include_str!
their theme during release.
Ideally, switching from parsing the file at runtime and including it at compile time would require as little modifications as possible...
Also, modifying the current theme should also be easier (an in-app "options" menu should be able to change some properties).
The main issue is resolved, the remaining point is word-wrapping for asian languages. More specifically, line break can happen between many characters, not just at whitespaces. This would avoid breaking lines at an early lonely whitespace, wasting space on the line.
Old issue:
Some CJK characters (and maybe others?) use 2 columns in the terminal.
Cursive currently assumes every codepoint is 1 column wide.
First step is to use grapheme instead of codepoint when computing width.
Until then asian languages will not work well.
Goal: make it easy to write a snake-like game with scores and info in a side view.
It may be easier to define some complex layouts in external files rather than build it manually in the source code.
Would need to define a layout representation (xml? json? yaml? qml?)...
We have a toml parser already to read themes, but toml doesn't seem like a good fit for this.
Using a language with an existing layout connotation (like qml or html) may look weird if we have to limit/change the actually usable elements.
Currently a view can only be selected from the root with a ViewPath.
Adding selectors (like css-selectors) and ViewWrappers with an ID would make it easier to find a view from the code.
Even more important if the layout is loaded from a file, when we don't have easy access to the ViewPaths.
Hi, I'm attempting to build and run the hello
example. Apparently, OSX 10.11 seems to have run into some conflicts with the installed ncurses lib. I've installed the ncurses dependency via homebrew tap, resulting in the following error:
~/tmp/rust/ncurse(master โ) cargo build -v
Fresh libc v0.2.13
Fresh rustc-serialize v0.3.19
Fresh ncurses v5.80.0
Fresh toml v0.1.30
Fresh cursive v0.0.2
Compiling ncurse v0.1.0 (file:///Users/ag/tmp/rust/ncurse)
Running `rustc src/main.rs --crate-name main --crate-type bin -g --out-dir /Users/ag/tmp/rust/ncurse/target/debug --emit=dep-info,link -L dependency=/Users/ag/tmp/rust/ncurse/target/debug -L dependency=/Users/ag/tmp/rust/ncurse/target/debug/deps --extern cursive=/Users/ag/tmp/rust/ncurse/target/debug/deps/libcursive-19b294b0688ff15d.rlib`
error: linking with `cc` failed: exit code: 1
note: "cc" "-m64" "-L" "/Users/ag/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/ag/tmp/rust/ncurse/target/debug/main.0.o" "-o" "/Users/ag/tmp/rust/ncurse/target/debug/main" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/ag/tmp/rust/ncurse/target/debug" "-L" "/Users/ag/tmp/rust/ncurse/target/debug/deps" "-L" "/Users/ag/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/ag/tmp/rust/ncurse/target/debug/deps/libcursive-19b294b0688ff15d.rlib" "/Users/ag/tmp/rust/ncurse/target/debug/deps/libtoml-cd71fbce840828ea.rlib" "/Users/ag/tmp/rust/ncurse/target/debug/deps/libncurses-28f717993e75ef1e.rlib" "/Users/ag/tmp/rust/ncurse/target/debug/deps/liblibc-a70a3ae81492eede.rlib" "/Users/ag/tmp/rust/ncurse/target/debug/deps/librustc_serialize-3bc953984ed46e7f.rlib" "/Users/ag/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-d16b8f0e.rlib" "/Users/ag/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcollections-d16b8f0e.rlib" "/Users/ag/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_unicode-d16b8f0e.rlib" "/Users/ag/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librand-d16b8f0e.rlib" "/Users/ag/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc-d16b8f0e.rlib" "/Users/ag/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-d16b8f0e.rlib" "/Users/ag/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liblibc-d16b8f0e.rlib" "/Users/ag/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcore-d16b8f0e.rlib" "-l" "ncursesw" "-l" "System" "-l" "pthread" "-l" "c" "-l" "m" "-l" "compiler-rt"
note: ld: library not found for -lncursesw
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: aborting due to previous error
error: Could not compile `ncurse`.
Caused by:
Process didn't exit successfully: `rustc src/main.rs --crate-name main --crate-type bin -g --out-dir /Users/ag/tmp/rust/ncurse/target/debug --emit=dep-info,link -L dependency=/Users/ag/tmp/rust/ncurse/target/debug -L dependency=/Users/ag/tmp/rust/ncurse/target/debug/deps --extern cursive=/Users/ag/tmp/rust/ncurse/target/debug/deps/libcursive-19b294b0688ff15d.rlib` (exit code: 101)
UPDATE: I uninstalled brew ncurse recipe, re-installed ncurses via macports and upgraded readline package. I get the same build failure output, displayed above. Oddly, macports lists ncurses dev branch v6.0, yet the build output seems to point v.5.8. Any suggestions on how to resolve?
Just like ncurses dialogs.
EditView currently ignores any non-ascii input.
Investigate how ncurses handle non-ascii input, and make EditView work with that.
Examples currently live nicely hidden in the examples
directory, but it's now their time to shine.
Let's have examples in sub-modules or in the specific View
s themselves.
Especially useful in ListView
, a one-line SelectView
that shows a MenuPopup
would be a nice addition.
And use the child's actual min_size.
Maybe by giving 0 when creating the view.
I watch development of this crate rather interested for some weeks now and I think this could be the crate I want to use to implement a ncurses-UI for my imag project.
The point is: imag is a program (or rather collection of programs) that gets composed from components, and I want to continue it this way also when implementing a ncurses UI for it.
So for example if I implement a CUI for imag-diary
I still want to be able to re-use the code I've written for this UI to integrate the UI into a more general UI.
Think of this:
imag-diary
, imag-notes
, imag-wiki
, etc.) has its own ncurses UI, implemented in the respective libimag*
cratelibimag*
crates to write a all-in-one curses UIIs this possible with Cursive? If yes, what has to be done, API wise on my side, to approach this?
My guesses:
cursive::View
(which are basically the UI for the respective crate. So one has one type and an implementation of cursive::View
for it for libimagentryview
, one for libimagdiary
, one for libimagfoobar
and so on)Am I right with this?
If the upper things are not possible or complicated to approach with the current API design of Cursive, you are welcome to use this as feature-request'ish issue! ๐
Instead of importing lots of submodules, maybe offer a prelude to easily import most important stuff.
Probably use a rope or something.
It will need to integrate some of TextView
's row-computing features, so some re-organization is in order.
If multiple events are buffered, maybe handle them all before the next redraw/relayout?
Kinda like BoxView.
Currently cursive uses utf8 to print dialog borders. This means when running with non-unicode locale, it prints garbage.
Ncurses should be able to print the correct characters no matter the locale (nmtui for instance works with any locale). Not sure how to do it though...
Cursive currently clears the screen on every event.
However, it really only needs to be cleared:
Somehow printing a % confuses something.
Used by menubar, or simple select widgets. See #27.
layouts the child with unknown height (or width) and only draw a subset of it.
May not make it to 0.1.0
, use a PopupSelect in the meantime.
Without having to wrap it in a KeyEventView
.
Would be nice to have something like a progress bar which can be updated from a thread or something...
Printer currently does not use its size to crop calls to print methods.
If we don't trust the view to color inside the lines, we may want to enforce it (and ignore commands outside of bounds).
This might make scroll view easier too.
I wanted to keep the base View
trait as simple as possible, but it looks like we'll need a second layout function.
The big issue is being able to properly layout "fluid" views like TextView
s. They have an ideal size (longest line * number of lines), but can squeeze into smaller sizes if required (they will then scroll).
Buttons, on the other hand, have quite definitive limits.
A linear layout made of buttons and text views, therefore, will have a mixed state, with an absolute minimum size it can fit into, and an ideal size to take when conditions are favorable.
Currently, the get_min_size
confusingly applies the recommended size.
The proposed solution is to have 2 methods:
get_min_size
, which returns the absolute minimum size required not to panic.
get_recommended_size
, which depends on the constraints (with a small fixed width, a TextView will prefer to be taller).During layout, view groups will try to give their children their ideal size. If that's impossible, they will look for the minimum sizes, and split the rest. The idea is to know where we can cut corners - in the current situation, it doesn't seem possible.
Use case: the linear
example must provide scrolling with low-height windows.
When adding a new layer to a stackView, it sometimes needs to be precisely placed (select popups for instance, see #36).
An solution would to be edit the StackView and give each layer a position parameter. It could be centered (the current default), or an absolute location, or a position relative to the previous layer.
It needs to be careful when the view would not fit at the asked location. elinks pushes the window if possible, then simply resize it when it already takes all the space available.
Where the view content actually change.
Maybe also the layout.
Not necessarily a View
in itself, but at least something that can be added to the root Cursive
.
Notes:
View
...The current one is wrong in some places. Also, alt+key input has started (and will eventually be complete), so the array definitely needs some improvement.
Maybe doesn't need to be on the Readme though; an interactive standalone page (or one page per category) could be a better choice.
And then there'll be the task of filling this table. Not sure how to automate this... :S
Currently, views just "take" the focus, without any direction information.
This means a linear view will always start with the first element in focus, even if the selection comes from an element to the left/bottom (like a dialog button).
Adding a direction parameter to take_focus
would allow views to change their behavior appropriately.
Often, a redraw is enough.
Goal: improve performance, reduce flickering when only a small window is changed.
If one can insert text in the text view (is this the right name?), it would be cool to have a possibility to get the mutable string from that object. Or even better: pass a function to the object which gets called with a context object (user defined) and the mutable string, so one can implement a editor backend to call for example vim with the text.
Might worth a try to submit a PR for me... I will have a look at this later, maybe I can come up with something.
Currently dialogs have their buttons on the bottom as a row.
Having buttons on the right as a column would be more convenient in some situations, for instance when selecting an item from a vertical list.
The view
module is currently used for two different purposes:
View
View
s ready to useThese two use-cases are fairly separate, and would be better served with two different modules. Finding good names is the trickiest part...
Box-drawing characters are part of UTF-8, so that's easy to do on modern terminals, but linux TTY still rely mostly on ASCII, and needs a different treatment.
ncurses has a nice system (with ACS_* characters) to print box characters whatever the backend, but it's a bit buggy, so moving to a home-made solution would be easier (especially if we later move to termion).
After some experiments, it seems the unicode values (for instance E2 94 8C for โ) work on a linux TTY, even when using LANG=C
... so let's go for it!
Currently completely broken.
The base idea of skipping single-child nodes is also absurd, it prevents pointing to those intermediate nodes.
Some languages like Japanese and Chinese can write right-to-left (and/or top to bottom), but are fine with the usual left-to-right orientation.
Other languages like Arabic simply must be written right-to-left (I think?), so we may need some support for those.
Low priority for now, as I know next to nothing about how RTL languages are usually used on terminals.
Menuconfig has a "outset" on the borders, using two colors to make a 3D impression.
Having this option in the theme would be nice.
Or LinearView or whatever: a list of views aligned in one direction.
TODO: how to compute the size for each child? Especially when they are fluid (like TextViews).
Some views need some minimal space to display properly. It's usually just a few cells, but as views include other views, it adds up. And while it's rarely an issue in regular use, when resizing a view, it can happen, if only temporarily.
Currently, it often results in a panic from usize overflows.
Rather than crashing, displaying an empty view would be a minimal thing to do. Showing an error message (like "Screen size too small" or something) would be even better.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.