[Urwid] Notational Velocity port

Andrew Wagner drewm1980 at gmail.com
Thu Mar 11 14:10:23 EST 2010

Thanks for the thorough reply Dominic!

On Thu, Mar 11, 2010 at 1:03 AM, Dominic LoBue <dom.lobue at gmail.com> wrote:
> Drew,
> Not to rain on your parade or anything, but there really isn't much of
> a need for an application like that in *nix. In a GUI-based OS like
> windows, sure, it'd be really handy. But in linux, an application like
> that is rendered superfluous by grep. If you know the note's
> title/filename you want has a specific word in it, but don't remember
> the whole title: ls | grep -i word. If you want to find a note that
> contains a word that isn't in its title: grep -i word *.

Notational Velocity is actually the main tool I use to catalog the
common usage idioms for commands like grep :)   Also, there are no
secrets between me and my notational velocity database.  It has
passwords, website bookmarks, many of my contacts, my romantic
history...  The database needs to be encrypted and blazingly fast, as
measured in keystrokes.

nv(Enter)wor (not specific enough... I'll narrow it down)
d word2 (oh, there it is... Let's add some new info...)
(down, down, down)   (to select the note from the narrowed list)
(tab)    (to switch keyboard focus to the note editing pane)

cd ~/notes
ls | grep -i word (Enter) (nothing... maybe it's in the note body, not
the filename...)
grep -i word * (Enter) (too much maybe I need to narrow it down more...)
(up) (for command history)
(backspace, backspace) word2 * (Enter) (oh, there it is...  but I want
to see the actual note.... not just the lines grep filtered out)
less (cut and paste the note filename from somewhere in the above
history, if it showed up...)
and so on...

I'm sure there are better UNIX flavored workflows than the above, so
this is admittedly a strawman, but you get the idea.  When most of the
UNIX tools were designed, computers were barely fast enough to display
the text as you typed, let alone fast enough to search a database and
re-render the screen with the results in the time it takes you to hit
the next letter of the word you're typing.

> That said, It is hard to suggest what widgets you should use when we
> have no idea what the application looks like. From the description of
> how the app works on notational.net though, the way I see the widgets
> being structured is with the top-most widget being a Frame. Frames
> have a body and can either have a header or a footer widget (or both).
> The header would be an Edit widget, and it would have focus to begin
> with. You'd use some key combination to change focus, like tab or
> ctrl+t.
> You'd need two different widgets for the body: one for auto-complete
> suggestions, and one for editing. The editing widget would obviously
> be an Edit you initialize with multiline=True. The autocomplete would
> be a ListBox around a ListWalker of some sort. In the ListWalker would
> be a list with Text widgets representing the autocomplete choices.
> --
> Dominic LoBue

Notational Velocity has three panes.  As far as keyboard focus is
concerned, the first two are logically grouped together.  (The two
modes are selecting/searching/creating notes and editing them).  As
visual layout is concerned, the last two panes are logically grouped
together.  (You want the divider between the two panes to stay in a
reasonable place as you resize the window)

That said, this mismatch between the keyboard logic and the widget
hierarchy is probably not that big a deal; in truth most of the logic
in the program is already inside the ListBox and Edit classes

At the moment I'm thinking something like Pile(Edit, ListBox, Edit),
everything subclassed for keyboard handling.  The listbox would not be
selectable and the top Edit would send keyboard events that affect the
list focus (up and down keys) to the ListBox.  Modifications to the
text in the first Edit would trigger (through a signal) updates to the
content of the ListBox and the note window.


More information about the Urwid mailing list