Daniel Barlow
a5a65006ca
1. When adding a button to flowbox, the flowbox widget interposes a flowboxchild between the two, which can receive events and so becomes part of the tab order. this is why our buttons weren't getting activated - they weren't focused even though they looked focused. So, use labels instead of buttons for completions 2. For some reason I don't understand, flowboxchild widgets receive :activate *only* on keyboard activation. So instead of using it, we connect to :child-activated on the flowbox. 3. Setting widget:on_foo *adds* a handler to the widget instead of replacing what was previously there. There is no nice way to remove handlers from a widget either. Because we need a new on_child_activated handler every time the completions change, the only way I can see to achieve this is to create the flowbox afresh on each keystroke instead of creating it once when the frame is created
86 lines
2.5 KiB
Markdown
86 lines
2.5 KiB
Markdown
# Braindump
|
|
|
|
This is a combination of a thinking-out-loud document and a TODO list.
|
|
It is not a document of record. You should not expect to derive value
|
|
from reading it
|
|
|
|
tl;dr what if ... a web browser, but tabs were more like emacs buffers?
|
|
|
|
## objects/data types
|
|
|
|
buffer
|
|
Buffer.find ;; by name, title, url
|
|
Buffer.by_name (maybe?)
|
|
|
|
buffer has-a webview but it is not shown by default. Later we may
|
|
add some kind of webview reuse so that invisible and old buffers
|
|
don't need to have a webview until needed.
|
|
|
|
I seem to be using "buffer" and "tab" mostly synonymously
|
|
|
|
frame
|
|
Frame.the-frame
|
|
frame.set-buffer (buffer)
|
|
frame.get-buffer => buffer
|
|
frame.commander - text entry widget
|
|
frame.actions - container of toolbar buttons
|
|
|
|
in future we may be able to split a frame into multiple windows
|
|
which show different buffers
|
|
|
|
location (url)
|
|
document
|
|
document element(?)
|
|
webview
|
|
lua's standard types
|
|
|
|
-----
|
|
|
|
a consideration we haven't touched on yet: in emacs, not all buffers
|
|
are files - e.g. the buffer list, or the process list, or the magit
|
|
status buffer - there is a well-used affordance for elisp to put
|
|
semi-persistent interactable content onscreen - do we need such a
|
|
thing here or is it ok to say "just call gtk" to command authors?
|
|
|
|
----
|
|
|
|
|
|
is there a role for TAB?
|
|
|
|
- in the shell it activates completion or shows options: we don't need that if we're updating them automatically
|
|
|
|
- we could use it to cycle through the available completions: switch
|
|
focus from entry to step through the completions then RET activates
|
|
|
|
|
|
-----
|
|
|
|
# TODO
|
|
|
|
* [done] show loading progress
|
|
* [done] show url when the commander is inactive
|
|
* [done] visit-location url defaults to current
|
|
* [done] ESC to cancel interactive command
|
|
* [done] C-g to cancel key sequence
|
|
* [done] display unbound key error
|
|
* [done] back binding
|
|
* [done] save url history, use it in completions
|
|
* [done] autocomplete command name
|
|
* [done] keyboard navigation of completions
|
|
|
|
* custom rendering for completions (e.g. buffer thumbnails)
|
|
* less ugly default completions rendering
|
|
* buffer name is often going to be useless. find buffers by url/title
|
|
still need some 1:1 mapping between the buffer object and
|
|
a text-representable form of same
|
|
* bind event to echo-area click, ideally dependent on what's being shown in there
|
|
* in general, can we bind commands to widget events?
|
|
* command to create new buffer
|
|
|
|
* suppress "Return is undefined" message after a command executes
|
|
|
|
----
|
|
|
|
can we increase the testability? e.g. for command processing,
|
|
define a command, feed in some keystrokes,
|