On Mon, Oct 20, 2008 at 02:49:41PM +0000, corvid wrote:
> I could say that it was for the sake of consistency with link behavior,
> but really it was because it seemed like a dilloishly simple way
> to get the equivalent of pages-remember-form-data.
The consistency part is a strong argument.
Also interesting is the way we can have a workaround to
remember form data, before a more usual way of handling it is
implemented.
>
> (But: who will ever discover that it exists or recognize what it
> makes possible?)
It may be stated in the FAQ.
> 1) fltkui: it might be better to stuff all of the button event stuff
> into a bag like fltkviewbase/layout do with EventButton. It certainly
> looks nicer having something like a shift mask hidden away in a nice
> tidy box, but I wasn't sure that it was actually worth doing.
Hmm, I'd say if it's going to be a definitive patch, it's
worth the effort.
> 2) form: carrying around buttonNo+shifted for a long time
> is not pleasing, but oh well.
Agreed.
Now that Johannes is interested in implementing FORM "memory",
I'd say it can be stored in an URL/form-data array. I haven't
checked how other browsers (e.g. FF) solve the problem of privacy
(aka. when it's desirable to remember data), but most probably a
quick look will shed some light.
BTW, I can't compile the patch here because:
make[2]: Entering directory `/home/jcid/C/Dillo/d2/dillo2-cur/test'
form.cc: In member function 'void form::Form::addButtonResource(const char*,
dw::core::ui::ButtonResource*, const char*)':
form.cc:241: error: cannot allocate an object of abstract type
'form::Form::FormClickedReceiver'
form.hh:124: note: because the following virtual functions are pure within
'form::Form::FormClickedReceiver':
../dw/ui.hh:338: note: virtual void
dw::core::ui::ButtonResource::ClickedReceiver::clicked(dw::core::ui::ButtonReso
urce*, int, int)
make[2]: *** [form.o] Error 1
make[2]: Leaving directory `/home/jcid/C/Dillo/d2/dillo2-cur/test'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jcid/C/Dillo/d2/dillo2-cur'
BTW2:
* The patch changes from "Activate" to "Clicked" signal.
* It also seems to change the logic in DilloHtmlInput::activate()
- it makes me wonder whether pressing enter on other form widgets
may submit.
Anyway, it'd be good if you can coordinate with Johannes and decide what
approach to take, and send a new patch for it. I'd prefer Johannes to keep
working in the CSS front, and you to make the definitive patch, but this
is for you guys to decide.
--
Cheers
Jorge.-
