December 2012 - Dillo-dev - lists.mailman3.com

ctrl-PageUp/Down

by corvid＠lavabit.com

Jorge wrote: > On Fri, Dec 28, 2012 at 07:18:08PM +0000, corvid wrote: > > > > I notice that ctrl-PageUp/Down for cycling through tabs doesn't work > > when a Fl_Input has focus. I can fix that if anyone cares... > > Yes, please. I fixed it for the ones for forms and Location. I wasn't sure whether the findbar one should, since it doesn't have too much and I'm in the habit of closing it so that I can use keys. (Although maybe that should be remedied after all...) In related news, I fixed ^I, ^J, ^L, ^M for form Inputs the other day, and I've been wondering whether I should for Location for any users who have non-default keys. At the moment, I'm leaning toward "yes".

Dec. 28, 2012

Ctrl-Tab and tabs

by jcid＠dillo.org

On Thu, Dec 27, 2012 at 10:46:22PM +0000, Jeremy Henty wrote: > > Johannes Hofmann wrote: > > > it seems that Ctrl-Tab no longer cycles tabs if an input field is > > focused. I did like the previous behaviour better, where Ctrl-Tab > > cycled tabs independent of where the focus was. > > +1. It is annoying that I now often have to click into the URL bar > before doing a Ctrl-(Shift)-Tab . > > It feels as though the browser window is handling the Tab key whether > or not it is modified by Ctrl. If it only handled Tab when Ctrl was > not applied and passed it on otherwise, then maybe that would do what > I would like. But I am guessing here - recent discussions in other > threads suggest that this may be more complicated than I realise. Yes, it's a bit complicated because FLTK doesn't use a signal/slot mechanism to deliver these events, it uses an event distribution algorithm (which is faster), but needs extra care. In the other thread I tried to explain the way I used in UI to handle them and avoid trouble. -- Cheers Jorge.-

Dec. 28, 2012

ctrl-PageUp/Down

by jcid＠dillo.org

On Fri, Dec 28, 2012 at 07:18:08PM +0000, corvid wrote: > > I notice that ctrl-PageUp/Down for cycling through tabs doesn't work > when a Fl_Input has focus. I can fix that if anyone cares... Yes, please. -- Cheers Jorge.-

Dec. 28, 2012

findbar behaviour

by jcid＠dillo.org

On Thu, Dec 27, 2012 at 08:38:24PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Dec 26, 2012 at 11:29:50PM +0000, corvid wrote: > > > > > > Here's what resulted, but it seems relatively inelegant: > > > [snipped long patch] > > > > It's much simpler. In this case you can let FLTK do the focus > > change among widgets: > > > > > > diff -r 20a26b8bb366 src/findbar.cc > > --- a/src/findbar.cc Wed Dec 26 23:31:48 2012 +0100 > > +++ b/src/findbar.cc Thu Dec 27 15:32:02 2012 -0300 > > @@ -158,7 +158,6 @@ Findbar::Findbar(int width, int height) > > check_btn = new Fl_Check_Button(x, border, 2*button_width, > > height, > > "Case-sensitive"); > > x += 2 * button_width + gap; > > - check_btn->clear_visible_focus(); > > add(check_btn); > > > > } > > > > and that's it, forward with Tab, back with Shift+Tab. > > > > > > Now, if there's a need for something more special, like letting > > Tab alone cycle around, adding this will do: > > > > > > @@ -179,6 +178,10 @@ int Findbar::handle(int event) > > if (event == FL_KEYBOARD && modifier == 0 && k == FL_Escape) { > > /* let the UI handle it */ > > return 0; > > + } else if (event == FL_KEYBOARD && modifier == 0 && k == FL_Tab) { > > + MSG("Findbar::handle FL_KEYBOARD Tab\n"); > > + (Fl::focus() == i) ? check_btn->take_focus() : i->take_focus(); > > + return 1; > > } > > > > return Fl_Group::handle(event); > > I wanted to make the findbar as functional as one would customarily > expect, though. Please elaborate. -- Cheers Jorge.-

Dec. 28, 2012

ctrl-PageUp/Down

by corvid＠lavabit.com

I notice that ctrl-PageUp/Down for cycling through tabs doesn't work when a Fl_Input has focus. I can fix that if anyone cares...

Dec. 28, 2012

penalty_em_dash_*

by sgeerken＠dillo.org

On Thu, Dec 27, Jorge Arellano Cid wrote: > While checking the penalty_em_dash_* patch, I noticed it would > be good to add and comment the hyphenation preferences in dillorc. Done. I added a new section, although it may be (together with colors) merged to the rendering section. Sebastian

Dec. 28, 2012

Ctrl-Tab and tabs

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > It feels as though the browser window is handling the Tab key > > whether or not it is modified by Ctrl. If it only handled Tab > > when Ctrl was not applied and passed it on otherwise, then maybe > > that would do what I would like. [...] > > It should be exhibiting the previous behaviour again now... That is *exactly* what I wanted. Thanks! Regards, Jeremy Henty

Dec. 28, 2012

PATCH: uicmd.cc prefs.save_dir cleanup

by corvid＠lavabit.com

Jeremy wrote: > > uicmd.cc exports a get()/set() interface to the default save directory > that is never used elsewhere, and used only trivially internally. It > also rereads prefs.save_dir at every save, which is redundant. It > would be simpler to have an init() interface that is called once. > There would be no change to the user. > > Patch attached. Thoughts? Seems like a good change to make...

Dec. 28, 2012

Ctrl-Tab and tabs

by corvid＠lavabit.com

Jeremy wrote: > Johannes Hofmann wrote: > > > it seems that Ctrl-Tab no longer cycles tabs if an input field is > > focused. I did like the previous behaviour better, where Ctrl-Tab > > cycled tabs independent of where the focus was. > > +1. It is annoying that I now often have to click into the URL bar > before doing a Ctrl-(Shift)-Tab . > > It feels as though the browser window is handling the Tab key whether > or not it is modified by Ctrl. If it only handled Tab when Ctrl was > not applied and passed it on otherwise, then maybe that would do what > I would like. But I am guessing here - recent discussions in other > threads suggest that this may be more complicated than I realise. It should be exhibiting the previous behaviour again now...

Dec. 28, 2012

PATCH: uicmd.cc prefs.save_dir cleanup

by onepoint＠starurchin.org

uicmd.cc exports a get()/set() interface to the default save directory that is never used elsewhere, and used only trivially internally. It also rereads prefs.save_dir at every save, which is redundant. It would be simpler to have an init() interface that is called once. There would be no change to the user. Patch attached. Thoughts? Regards, Jeremy Henty

Dec. 28, 2012