[Urwid] Notational Velocity port

Andrew Wagner drewm1980 at gmail.com
Fri Mar 12 02:04:30 EST 2010


I have attached what I have so far.  What is the right way to pass
keypresses between two arbitrary widgets in my program?  The "size"
parameter seems to throw a wrench in the works.

Cheers,
Drew

On Thu, Mar 11, 2010 at 1:10 PM, Andrew Wagner <drewm1980 at gmail.com> wrote:
> 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
> (Thanks!).
>
> 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.
>
> Cheers,
> Drew
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nv.py
Type: text/x-python
Size: 3395 bytes
Desc: not available
Url : http://lists.excess.org/pipermail/urwid/attachments/20100312/fb2c18ba/attachment.py 


More information about the Urwid mailing list