- Dillo-dev - lists.mailman3.com

PATCH: uicmd.cc prefs.save_dir cleanup

by onepoint＠starurchin.org

corvid wrote: > 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... OK, committed. Regards, Jeremy Henty

Dec. 30, 2012

ui colors again

by corvid＠lavabit.com

I wrote: > Today I dug up the old ui colors patch from last September, ripped out the > part that used system colors as defaults that was a problem*, and played > around with it a little. I really like configurable colors, so, since I > haven't heard anyone say anything like feature freeze yet, I'll make another > push for this thing. Committed. - I changed the inactive icon appearance some more. - By default it's using the fltk default colors. - It might be nice to be able to specify the selection color, too.

Dec. 30, 2012

wizard, switching between UIs

by corvid＠lavabit.com

Yesterday I was playing with ctrl-tab, of course, and I noticed how the state of the focused tab would sometimes change. I went through a few rounds of fixing this in different ways before finding something that didn't seem icky. Detailed comment in patch.

Dec. 29, 2012

Dpi_connect_socket retry

by p37sitdu＠lavabit.com

On Thu, Dec 27, 2012 at 04:37:36PM -0300, Jorge Arellano Cid wrote: > 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*. I made conclusions from reading Dpi_connect_socket() only, because in the case of error in Dpi_blocking_write file descriptor is left open and not passed anywhere else. If it was passed somewhere else, I would read the code there and check if file descriptor was closed there. > 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. Patch that I did for checking is attached. It replaces Dpi_blocking_write call with -1 to simulate fault in Dpi_blocking_write for Dpi_connect_socket(). Introducing the error in Dpi_blocking_write for all functions doesn't work, in this case Dpi_connect_socket is not called at all (because Dpi_start_dpid fails). With this patch applied, I recompiled dillo and pressed "bookmarks" button several times to trigger dpi code. Each time I pressed "bookmarks" button, new descriptor was leaked: % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 6 % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 6 % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 6 7 % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 6 7 8 Then I applied the patch I sent before (with hg qpush) on top of the fault patch and rebuilt dillo: "make clean && make". I ran dillo again with ./src/dillo and did the same test with bookmarks button: % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5 % ls /proc/$(pidof dillo)/fd 0 1 2 3 4 5

Dec. 29, 2012

findbar behaviour

by corvid＠lavabit.com

Jorge wrote: > 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. Let's see, I wanted to be able to focus the input, the next and previous buttons, and the case-sensitive checkbox. I wanted to be able to activate the buttons and toggle the checkbox with either Space or Enter. I wanted to be able to Tab to each of them, shift-Tab to go back, and to have the tabbing wrap around. I thought a little about bringing the close button into the loop, but then I imagined it being easy to tab to by accident and inadvertently close the bar, especially given that it already has a key combination. I'm not quite sure, though.

Dec. 28, 2012

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