about summary refs log tree commit diff stats
path: root/src/lcurses
Commit message (Collapse)AuthorAgeFilesLines
* flesh out very preliminary UIKartik K. Agaram2021-12-251-0/+2
| | | | | | | Our sandboxing model is a blunt caricature, just two booleans. But let's see how far this gets us. Still doesn't persist, and definitely has no effect.
* delete a couple more hacky function prototypesKartik K. Agaram2021-12-251-3/+1
|
* gemini: echo urls while typing inKartik K. Agaram2021-12-211-0/+3
| | | | Let's see how much we need to tweak this solution.
* nail down trusted Teliva channels a little moreKartik K. Agaram2021-12-211-5/+5
| | | | | | | | | | | | | | | | | | | | | | In each session, Teliva has to bootstrap a trusted channel with the computer owner while running arbitrarily untrusted code. So let's get really, really precise about what the trusted channel consists of: - the bottom-most row of screen containing the menu - the keystrokes the owner types in - ncurses COLOR_PAIR slots 254 (menu) and 255 (error) One reason the menu colors are important: we don't want people to get used to apps that hide the menu colors by setting default foreground/background to invisible and then drawing their own menu one row up. The error COLOR_PAIR I don't see any reason to carve out right now, but it seems like a good idea for Teliva the framework to not get into the habit of apps doing some things for it. I'm not sure how realistic all this is (I feel quite ill-equipped to think about security), but it seems worthwhile to err on the side of paranoia. Teliva will be paranoid so people don't have to be.
* keep Teliva apps from pretending to be TelivaKartik K. Agaram2021-12-211-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Kind of a subtle idea. Teliva the framework is intended to be trustworthy software that people install on their computers. The apps people run using Teliva may be less trustworthy. The whole point of Teliva is to provide a sandbox for running code before you trust it. One way (of many) apps can be malicious is by subtly getting between what people see and reality. Imagine, for example, an app that draws a fake menu bar and offers a different hotkey to edit source code. When someone presses that hotkey they think they're using the standard Teliva editor but they're really using an editor within the app, which the app uses to hide its most malicious bits from view. Down the road Teliva will have more bits of UI, such as for asking for permission to read sensitive data. It's important that people understand what they're granting permission to, that apps can't tamper with the communications channel between them and Teliva. This is likely just one of many ways for an app to break out of its sandbox. Teliva isn't sandboxed yet. I'm just taking my first steps on this journey. In particular, there are other mechanisms for asking for user input besides `getch()`. I don't yet have a big-picture view of the Teliva sandbox. It seems clear that I need to educate people on the difference between different parts of screen. Depending on the app you install, most of the screen may be a dark forest. It'll be important to know where the safe path is, where you can speak to trusted advisors while in the forest.
* more configurable colorsKartik K. Agaram2021-12-061-0/+17
| | | | | Also start using 256 colors, under the assumption most people will have them.
* a couple more global curses bindingsKartik K. Agaram2021-11-291-0/+3
|
* .Kartik K. Agaram2021-11-291-2/+0
|
* let people fix bad images from within TelivaKartik K. Agaram2021-11-291-2/+2
| | | | | | | | | Short of syntax errors that keep us from parsing the teliva_program table, we should now be able to recover gracefully from everything. Yesterday I started to try to add this to load_definitions before realizing most errors are only noticed while running `main`. But I didn't think of recovering from the docall of `main` until this morning.
* start streamlining architectureKartik K. Agaram2021-11-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All the spaghetti is hiding another issue: when we load editor state, that code path currently never leads to importing the edited buffer back into the image. Yet another attempt at drawing the state diagram: Wgetch -> switch_to_editor -> select_view select_view -> load_editor_state | big_picture_view load_editor_state -> edit_from -> editorProcessKeypress big_picture_view -> edit_image -> edit_buffer -> resumeEdit* -> load_editor_buffer -> editorProcessKeypress big_picture_view -> recent_changes recent_changes -> big_picture_view | edit_buffer The problem is that load_editor_state doesn't eventually call load_editor_buffer the way its sibling big_picture_view does. For starters, it's confusing that switch_to_editor calls big_picture_view which calls other editor functions. What is 'editor' here, anyway? Let's rename switch_to_editor to developer_mode. So the app starts out in user mode, and might eventually transition to developer mode. Developer mode is a black hole; to leave it and return to user mode we restart the entire app. The architecture in my mind is now: - Teliva consists of user mode and developer mode - Developer mode consists of multiple views - Each view, when it needs to edit something: - initializes kilo - loads a buffer into it - resumes editing the buffer as necessary
* clear editor state across user-visible restartsKartik K. Agaram2021-11-281-1/+3
| | | | | | | | | | | | | | | | Teliva's constantly restarting without the user being aware of it. So far I figured saving history across the user actually exiting and restarting Teliva was just a happy "feature". However, it looks like that's actually more complex to implement. Keeping editor state across user-visible restarts results in these problems: - opening the editor after restart has the cursor position messed up, no matter what definition you open. - more seriously, opening the editor after restart can't seem to get to the big-picture view anymore. Rather than try to debug what's going on, I'm going to just cordon off that part of the state space for now.
* use header everywhereKartik K. Agaram2021-11-281-3/+3
|
* now building on OpenBSDKartik K. Agaram2021-11-271-0/+1
| | | | Still emitting a bunch of warnings on OpenBSD, though.
* fix build on MacKartik K. Agaram2021-11-271-0/+3
|
* one more curses bindingKartik K. Agaram2021-11-251-0/+1
|
* standardize warning flags everywhereKartik K. Agaram2021-11-222-3/+3
| | | | | | | | | | I'd like to enable -Wextra as well, but that creates some false positives. I've at least made my changes clean w.r.t. -Wextra. Now we have 4 remaining warnings with gcc 9.3 that seem genuine. Need to fix those.
* get rid of a distracting nameKartik K. Agaram2021-11-201-1/+1
| | | | | No distinction now between the C and Lua versions of the curses library. We build them all together in one place.
* port changes from minimal to maximal versionKartik K. Agaram2021-11-203-81/+28
| | | | From lcurseslib.c to lcurses/ directory.
* inline lcurses maximally rather than minimallyKartik K. Agaram2021-11-198-0/+4982
Until now we had just the bare minimum bindings needed for the demos built so far. Now we have all of lcurses building in place with minimal changes. The changes in this commit can run hanoi.lua when inlined into Lua 5.1, but don't work with Teliva.