Closed stoicism2323 closed 8 years ago
First, cool to see there is new activity around here! Secondly, you're right. Right now there is no scrolling functionality.
Take a look at the function commentScreenDisplay(main.c) and linkScreenRenderLinkText. You'll find that it just adds the whole string to the screen and let ncurses handle it. There is no scrolling functionality.
I would suggest that we initiate a variable that keeps track of the scrolling when ever a comment or link is opened. Then just loop through the string until you've had the proper amount of newlines, and display from there.
Keep me updated if you run into troubles,
Cotix
Cool. I've added an untested but seems to be working at first glance implementation in my forked branch (https://github.com/stoicism2323/creddit). New to github so I'm not sure if there's a better way to get someone else to look at this chaange, but there it is. :) Thanks for your help cotix!!
Oh one more thing! I need to update this so that it works for the Link text as well. Will do tomorrow!
Is there a special reason you are using a stack? Wouldn't it be just simpler to loop back to the previous newline when you scroll up?
Also keep in mind that ncurses can break up lines earlier if it is too long for your terminal window. You should look for the next new line, OR the amount of characters that equal the terminal width. This also makes the problem slightly more difficult because resizing the window might screw things up. This is actually a reason why a stack wont work, if I scroll down a few times, and than resize, the values in the stack do not correspond with one line up, since the width of a line has changed.
Besides that, if you do end up needing the stack, I dont think it fits nicely in libreddit. Libreddit should be a standalone library. Since the stack is not used in libreddit, but in cReddit, I would prefer if you refactored the stack to be in cReddit instead.
Thanks for the feedback cotix! However I think I'll need either a stack or a system that marks the text for 'scroll points'. Otherwise, I run into an issue where I don't know how far back to scroll depending on the screen width. If the text that I want to scroll up to previously ended in a newline in the middle of the screen, I will need to know how far into the screen the text went. I tried out doing it without the stack (just searching for newlines) and this is the issue I've run into. I think without a stack or parallel array with booleans it'll be impossible to know how far into the screen the text trailed into.
You're right that resize is an issue with this as well. I would need to either rebuild the stack, or redo the parallel bool array to reflect the resize.
Thanks again for the help!
When scrolling up, can't you just go back to the previous new line, or the width of the screen (whichever is earlier)? So for example, if the screen is 80 chars wide, but the previous newline is 90 characters ago, you should only go 80 characters back.
Gotcha, while taking a walk and smoking a j I thought of this too and ran back to the library. Thanks for the help man!!!
Ok, I've updated the main.h in my fork. It doesn't malloc any memory, searches backwards in the original current->wbodyEsc string using the function that DSMan provided. Reflected the change in the link screen self posts as well.
Looks good so far. Tell me when it's finished
When viewing a comment item (shows up in the bottom pane) or the text of a link (also text that shows up in the bottom pane) it seems like if the comment or text is too large, and spills off the screen, that text is not viewable. Is this the case? I don't see an option to scroll down the comment text.
Please let me know if this makes sense or if this feature (scrolling down on a comment item in the bottom pane) is already present. If not I will try to implement :)
Thanks, stoicism