Scrolling lists.

[TBurchfield]

Too long a list currently crashes cursello. Let's make the lists have the ability to scroll, and thus have information off screen.

[TBurchfield]

Perhaps lists ought not necessarily need to scroll. This could create confusing UI.

However, cursello should not crash. The user also loses data when this happens. We need to make sure cursello always cleans up when it would normally crash. Perhaps surround sensitive parts (adding lists/items) with a try block, and a catch that saves the board. Alternatively, perhaps don't draw list items that are off screen.

I'd like some feedback about what seems like the most elegant and intuitive way to handle this.

[dsmith47]

There are three ways to address loss of user data:

1. Save list to file on every update
2. Make user save list themselves, a crash will lose all unsaved data vim style
3. Add an atexit hook to the code so there is a save when program closes.

Of these items, I prefer 3, though it carries the risk of some runtime issues somehow bypassing atexit or any hook implementation.

[dsmith47]

There are a series of ways to handle list item overflow.

1. Reject it - use curses native tracking of lines in screen to set a limit and don't let items be added when exceeding it.
2. Accept it - implement scrolling to handle longer items

I prefer 2 here, 1 breaks when terminals change heights, though 2 does force the issue of scrolling.

[TBurchfield]

Though this might not be great from a UI perspective, we could also have lists and items that are out of bounds just not be drawn at all, but let them be added. Thoughts?

[dsmith47]

Terrible from a UI perspective. I fear it will let users create a bunch of items and then forget about them, only to be rudely reminded when they start removing items (IF it's a list they remove items from at all). Also feel that hidden items are imbalanced in the context of reodering lists (items can be created in any order and rearranged later, until they start wrapping offscreen).

It's evident we need to be aware of overflow to prevent curses from breaking, so why not do something with that info while we're at it?

[TBurchfield]

Good point. I suppose there would could be visual ways we could indicate overflow, which would improve it from a UI perspective, but perhaps still not great.

Perhaps something like

┌──────┐┌──────────────────────────────────────┐
│Done  ││Doing                                 │
│item1 ││Get a bigger screen                   │
└──────┘│This is unreasonably small            │
        │You should really upgrade that screen │
        │Oh no you're gonna hit the boundary   │
        │           vvvvvvvvvv                 │

At this point, I think the question is whether scrolling or some sort of visual indication of overflow is more straightforward UI. Thoughts?

[dsmith47]

For reasons above, I continue to vote for scrolling. The partial list is not as helpful for interaction as the whole list.

[dsmith47]

Any thoughts on the persistent storage option?

[dhdavvie]

To add onto this, cursello crashes if the prompt for 'BarInput' is longer that the width of the current terminal. Considering that different users may have different terminal sizes, and you wouldn't really want to limit a user's board size to their terminal size, maybe UI overflow is something that should be addressed universally in cursello. Having a quick look, it seems to need something along the lines of using the window.scroll to handle the vertical overflow. Still need to look into it more, thoughts?

[dsmith47]

I would implement using scroll and resize, yes.

[dhdavvie]

So it looks like curses.newpad is the way to go about doing this. I've currently got the ability to scroll/move around the window and have a board that is larger than the terminal on my fork. I just need to round a few things off (such as wrapping the prompt for user input) and then I'll set up a PR tomorrow probably