Re: patch: middle-click submits in new window/tab
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.-
On Mon, Nov 10, 2008 at 02:36:48PM -0300, Jorge Arellano Cid wrote:
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.
I won't start on any new stuff (other than CSS) in the near future. Currently I'm trying to convert the table code to the new style handling which is a bit hairy but there are no major obstacles yet. And I really like the middle-click to submit thing. So I don't have a lot of motivation to implement real form data remembering anyway. Cheers, Johannes
On Mon, Nov 10, 2008 at 07:01:21PM +0100, Johannes Hofmann wrote:
On Mon, Nov 10, 2008 at 02:36:48PM -0300, Jorge Arellano Cid wrote:
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.
I won't start on any new stuff (other than CSS) in the near future. Currently I'm trying to convert the table code to the new style handling which is a bit hairy but there are no major obstacles yet.
And I really like the middle-click to submit thing. So I don't have a lot of motivation to implement real form data remembering anyway.
Great! Corvid: please explain me a bit about: * 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. + fix gcc error and re-submit a patch. -- Cheers Jorge.-
Jorge wrote:
Corvid: please explain me a bit about:
* The patch changes from "Activate" to "Clicked" signal.
Partly because it was a click that's passing button stuff, and partly because I may want to experiment with sending right-click through someday for a form menu.
* It also seems to change the logic in DilloHtmlInput::activate() - it makes me wonder whether pressing enter on other form widgets may submit.
text/password/isindex can, but textarea won't (no connectActivate).
+ fix gcc error and re-submit a patch.
I guess I'll go back and make a little thing for the button state to live in as well.
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de