> Preferably it would be easy to extend with an ncurses interface as > such have a much friendlier ion-like keyboard-oriented feel to them.
I would prefer an ncurses interface as well. The main reason I am starting with GTK is that it handles a lot more of the interface stuff for me. With ncurses, there is more work to be done just to get the GUI interface setup. But yes, I would like to allow ncurses support, so I will try to make that easy to drop in. Since I got my quick prototype working, I started work on the real version. I am still doing the behind the scenes stuff. So I may still decide to just skip over the GTK gui and go right to the ncurses GUI. We'll see how I feel about it when the time comes. > (The proper way would of course be to first write Vis :) What is Vis? I tried googling for it, but three letter words are not fun to do a search on. > As for the current mockup, I prefer vertical splits. However, a tree > view would perhaps be better for submaps. Don't know if that's possible > with tables.. Maybe they could just be flattened. > > Oh, minimise number of popups, please. They're evil. One possibility would > be to have two views like now (orientation configurable), but the first view > would display current bindings (submaps as tree or flattened), and the > second available functions and their explanations. When a binding is > selected from the list of current bindings, the explanation view scrolls and > highlights the explanation matching this binding if any. Pressing a key (or > a button) in the explanation view creates a new binding (with no key yet > set) and switches focus to that entry in the first view. That sounds pretty good to me. I'll probably use riot as a model then. The binding contexts and submaps can be different levels of the tree. As far as the explanation view, what is the best way to maintain the information about what the function does? In theory, the input file should have a bdoc() call before each function. But what I don't like about that is there is no direct link between a bdoc and the corresponding binding. It seems messy to go through the table, seeing if a bdoc comes right before a kpress/mpress/whatever. Another option is to maintain a separate, direct mapping between bindings and their descriptions. But I think I dislike that option even worse. If anyone has a better idea for how to handle this, please let me know. -- Zachary P. Landau <[EMAIL PROTECTED]>
