- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 121
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
make rendered mode easier to use in a shell environment #1823
Comments
maybe plot this out with the work i'm doing on |
i think maybe |
the banners need be integrated into this. sample the cursor after the intro banner is printed. |
so what happens when we, say, create an |
But that brings up a good point--for this to work, scrolling on the standard plane has to be paired with an actual scroll of the visible area. |
Looks like you can already set the standard plane's scrolling mode, good good. |
ok, getting there! we have the option implemented. we need to check it on shutdown, and if it's set, place the cursor at the logical row based on the standard plane. we need bump the cursor down if we print init banners. and i think that's it! |
@joseluis , you'll want to be aware of this, i think |
only problem left is that we always put the cursor at the bottom at the end of rendered mode, which fucks us up when we're not starting at the bottom. need to check for |
oh, we probably ought use the |
got that handled. only remaining issue is accounting for init banner relative to initial cursor placement. |
gotta knock out some unit test breakage, and test te hell out of this, but sweet! |
@dankamongmen is this only going to work with the standard plane? I'm trying to think of the best way to use this with the hi-lvl rust wrappers that don't have the concept of the standard plane... |
hrmmmmmmmmm. so this feature isn't all the way there yet -- i haven't yet developed anything very serious with it (just so right now, i'd think that via whatever mechanism you allow this mode to be entered, it needs to internally mark the standard plane as scrolling, and do the other steps outlined above. those needn't be exposed to the user. and what i think is going to happen is that when you have a plane bound to a scrolling standard plane, and that former plane goes beyond the bottom of the visual area at render time, scrolling will encompass said plane, not just the standard plane. so it all falls out. i just need to make sure that works properly. does that make any sense? |
yes it makes sense. So I guess I could internally get the cursor position from the standard plane, duplicate it, move it to its own pile, enable scrolling, and work over it. right? |
sacre bleu! sounds like i need dig out the laptop. thanks for the heads-up! |
hrmmmm i see a problem here. you presumably would want to be writing arbitrarily much data to this secondary plane, and having the screen scroll with it. so normally you could just set that plane scrolling, and it would do exactly that -- but it wouldn't interact with preexisting text, etc. because we need to truly scroll the screen, and normally we just logically scroll within the plane. so no, that wouldn't work, at least the way i'm seeing this working. hrmm. it would work if you moved the secondary plane down a row each time you wanted a true screen scroll, but that sounds difficult to know -- i'm trying to make this largely no-effort for the user. hrmmmmmmmmmmmm. |
@dankamongmen is there a specific thread I should be monitoring for this topic? |
#1883 is probably where remaining design will be going on, feel encouraged to chime in |
direct mode and rendered mode are at heart differentiated by whether output is generated outside of notcurses.
with that said, we could do a lot to make rendered mode more useful in a traditional scrolling shell environment. i'm basically thinking some combination of:
i don't think this needs to be a
notcurses_core_init()
option, and probably shouldn't, but it ought at least be tested and documented, and some examples written, and rough spots identified and ironed out.The text was updated successfully, but these errors were encountered: