- Dillo-dev - lists.mailman3.com

Ctrl-Tab and tabs

by onepoint＠starurchin.org

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. Regards, Jeremy Henty

Dec. 27, 2012

Ctrl-Tab and tabs

by Johannes.Hofmann＠gmx.de

Hi, 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. Cheers, Johannes

Dec. 27, 2012

findbar behaviour

by corvid＠lavabit.com

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.

Dec. 27, 2012

Dpi_connect_socket retry

by jcid＠dillo.org

Hi, On Thu, Dec 20, 2012 at 06:49:49PM +0400, p37sitdu at lavabit.com wrote: > On Sun, Dec 16, 2012 at 07:43:19PM -0300, Jorge Arellano Cid wrote: > > On Sun, Dec 09, 2012 at 02:58:43PM +0400, p37sitdu at lavabit.com wrote: > > > Also, comment says "the server closes sock_fd on error". However, > > > sock_fd should still be closed by client to free allocated file > > > descriptor. OS don't know if Dillo is going to read from it (in which > > > case error such as ECONNRESET should happen) so file descriptor can't > > > be reused. > > > > > > File descriptor should be closed in case of error in a_Dpip_build_cmd > > > too. > > > > The file descriptor is properly closed by its CCC afterwards > > (Visible by defining VERBOSE in chain.c). > > > > The CCC manages the error propagation/handling, in both the > > requesting and answer branches. > > File descriptor is properly closed if there were no errors. But if > there is an error in a_Dpip_build_cmd or Dpi_blocking_write, sock_fd > should be closed before returning from Dpi_connect_socket. > > Dpi_connect_socket calls a_Dpip_build_cmd to build command and > Dpi_blocking_write to write this command to sock_fd. a_Dpip_build_cmd > does not accept sock_fd as its argument so it can't close it. > Dpi_blocking_write only writes to fd, but does not close it on error. > > So if one of these two function fails, Dpi_connect_socket should close > sock_fd before returning -1. In the current state it just returns -1 > and leave sock_fd open. > > By the time Dpi_connect_socket returns, sock_fd is lost and will not > be closed by any code outside Dpi_connect_socket. > > Attached patch adds code to close sock_fd in case of error. As from the patch you sent (same as before), and the explanation you give (ignoring my explanation), I guess you're making conclusions out of reading the code in Dpi_connect_socket() *only*. Have you checked what you state as fact? (i.e. that the FD is leaked and not closed by the CCC). FWIW, I did check before writing my previous answer. Of course I'm human and do make mistakes, so if this is the case: can you please verify and show how to reproduce the bug? -- Cheers Jorge.-

Dec. 27, 2012

findbar behaviour

by jcid＠dillo.org

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); -- Cheers Jorge.-

Dec. 27, 2012

penalty_em_dash_*

by jcid＠dillo.org

Hi Sebastian, While checking the penalty_em_dash_* patch, I noticed it would be good to add and comment the hyphenation preferences in dillorc. -- Cheers Jorge.-

Dec. 27, 2012

textarea key bindings

by corvid＠lavabit.com

In bug 1112, Alexander asked for ctrl-backspace to work a word at a time. I put together the attached and he reports that it's working well.

Dec. 27, 2012

findbar behaviour

by corvid＠lavabit.com

Here's what resulted, but it seems relatively inelegant:

Dec. 27, 2012

findbar behaviour

by jcid＠dillo.org

On Wed, Dec 26, 2012 at 05:24:27PM +0000, corvid wrote: > Jorge wrote: > > IIRC, a relatively clean way to hook this shortcuts is to let the > > event get to the parent group, which in this case should focus its > > next child. > > I'm not quite sure what you're saying here... FLTK tries to deliver events in similar but different ways. AFAIR, for keystrokes, when a leaf widget is focused, it tries to deliver there first, and if not handled, then it goes upwards to its parent. If not handled all the way up, fltk tries "harder" to deliver it. Depending on the particular widget tree of the application and the internal algorithm used by fltk, is hard to predict exactly how this sequence goes. So a simple way to resolve the problem, is to code the handler in the common parent that encloses a closely related widget set (e.g. Findbar may do it in this case). e.g. let the event travel upwards to Findbar::handle(), do what's necessary there and return non zero (i.e. "handled"). (CustInput::handle() is a good example of this technique). -- Cheers Jorge.-

Dec. 26, 2012

findbar behaviour

by corvid＠lavabit.com

Jorge wrote: > IIRC, a relatively clean way to hook this shortcuts is to let the > event get to the parent group, which in this case should focus its > next child. I'm not quite sure what you're saying here...

Dec. 26, 2012