Dnia czwartek, 5 października 2006 01:16, Hari Krishna Dara napisał:
> I have 6.3 version of cygwin and arrows work fine in rxvt. I stil think
> your term settings are not right. But this is not really concern forms
> plugin, though it means we might have to support some other maps that
> will reliably work in all the terms.
<C-N>, <C-P>? It should work everywhere and is quite natural for Vim
users (IMO).
> > Another thing. Until now I was only playing with demo. Now I tried to
> > do my own form and have one thing to say:
> >
> > Listener stuff is complicated. Can it be done simpler?
>
> Do you mean simplify the listener interface, or completely do away with
> them?
Former.
> - If you mean the former, then the alternative is to accept a function
> name (this is what my previous version worked). But a big problem with
> this is that the function has to be global and I hate defining global
> functions without intending them to be part of API, and I know several
> others feel the same. The current scheme of expecting a dict object
> should be more familiar to many, who worked with the newer GUI
> frameworks (such as Swing and Flex). While not having to define a
> global dict variable, it also provides a way to create more
> "contextual" listeners (you can e.g., put the form that the listener
> is attached to, without having to modify the listener interface to
> also expect the form object).
I would expect some simplifying in use. For example why explicitly
declare them? Create listeners automatically.
Check example I send earlier. Core stuff is quite simple, big part of it
is overhead dealing with listeners.
> What do you think are the next priority TODO items before making the
> first release (or a beta release)? I am thinking if I fix the known
> issues and implement the items that improve the overall feel of a static
> form, it will be good enough. Right now, there are too many ways the
> user can end up in 'modifiable' mode and just remove/change anything,
> giving the impression that the plugin is not robust).
> - Pressing <Esc> in textfield doesn't let you <BS> into the existing
value
> (need to set backspace=start, but this is global).
> - Support for radio buttons.
> - Optional user completion for textfields and comboboxes (no preset
data).
> - Support for disabling fields (greyed out and no editing or focusing).
> - Validators.
Local validation (onBlur event) can be already done. Problem is when
doing after pressing OK. Hmm, in fact it can be also done but is boring
;) to do. Some API for that would be good.
> - For non-editable comboboxes, don't accept a value that is not in the
data.
> - <C-N/P> in select mode should cancel selection and bring up popup (or
do
> nothing by setting 'keymodel' to empty value, but this is global).
> - When the focus is moved in, explicitly set the value again, to make
> sure any fouled up entries are fixed.
Don't understand that. Maybe you were thinking about "moving out" of
field (onBlur JavaScript event)? It is already possible.
> - Detect cusor movements beyond the fields and disable modifiable. This
will
> reduce the chance of accidentally mucking up the form.
> - Avoid first empty line (in an empty buffer).
> - Recognize no/empty title.
Title may be declared. Make it support for non showing it, like::
let demoform = g:forms#form.new('Address Entry Form', 1)
To show it and 0 for non showing it.
> - Encode the field boundaries (like [], <>) in the field itself. This
will
> make some of the logic more generic and will make it more flexible to
> change them.
One change which would be good to introduce before official beta:
obligatory fields. As I wrote earlier - full validation if possible but
laborious. And declaring it in API should allow for some emphasis
(highlighting?).
m.
