- Dillo-dev - lists.mailman3.com

Render bug

by Hole.destructor＠gmx.de

Dear Dillo developers, sorry for not creating a proper bug report, but the "How to reproduce" message field is too small for the example file. :) The issue ========= After closing the "Save As" dialog, the background color of the HTML page is not redrawn correctly (leaving white rectangles instead of the background color). How to reproduce ================ 1. open the appended html file (note the grey background) 2. click on "file" link 3. move the "Save As" window over the grey background 4. close the "Save As" window --> parts of the background are drawn white, instead of grey Best, Alex

Dec. 31, 2012

hyphenator valgrind error

by sgeerken＠dillo.org

On Mon, Dec 31, corvid wrote: > ==30983== Invalid read of size 1 > ==30983== at 0x81151B6: fl_utf8back (fl_utf.c:259) > ==30983== by 0x80A2320: dw::fltk::FltkPlatform::prevGlyph(char const*, int) (fltkplatform.cc:599) > ==30983== by 0x809EDA3: dw::Hyphenator::hyphenateSingleWord(dw::core::Platform*, char*, int, lout::misc::SimpleVector<int>*) (hyphenator.cc:327) > ==30983== by 0x809E9F2: dw::Hyphenator::hyphenateWord(dw::core::Platform*, char const*, int*) (hyphenator.cc:256) Good opportunity to get rid of fl_utf8back. I'm working on it, expect a fix next year. Sebastian

Dec. 31, 2012

CAPI ignores download requests when not in cache or handled by the downloads DPI.

by p37sitdu＠lavabit.com

On Sun, Dec 30, 2012 at 05:23:18PM +0000, Jeremy Henty wrote: > > I wondered why "Save link as" silently failed on some of my local web > pages if I had not already visited the link. It turns out they were > "file:///" links and "Save link as" sends a download request which the > CAPI silently ignores if the URL is not cached and is not handled by > the downloads DPI. > > I added a MSG_WARN to log this but haven't changed any behaviour. I > still found it surprising and was wondering if it could be improved? I think the right way to fix it is to redesign downloads DPI so that it doesn't duplicate downloading code. I already said that in Gopher DPI therad. Instead, Dillo could download files and pass them to downloads DPI. Downloads DPI then shows progress and saves files. As I understand, the idea is to have one window for all downloads across many copies of Dillo where progress can be shown and requests to cancel them can be passed to the right copy of Dillo. In the current state only http, https and ftp links are passed to DPI, you can see it in a_Cache_download_enabled.

Dec. 31, 2012

hyphenator valgrind error

by corvid＠lavabit.com

==30983== Invalid read of size 1 ==30983== at 0x81151B6: fl_utf8back (fl_utf.c:259) ==30983== by 0x80A2320: dw::fltk::FltkPlatform::prevGlyph(char const*, int) (fltkplatform.cc:599) ==30983== by 0x809EDA3: dw::Hyphenator::hyphenateSingleWord(dw::core::Platform*, char*, int, lout::misc::SimpleVector<int>*) (hyphenator.cc:327) ==30983== by 0x809E9F2: dw::Hyphenator::hyphenateWord(dw::core::Platform*, char const*, int*) (hyphenator.cc:256) ==30983== by 0x809C087: dw::Textblock::hyphenateWord(int) (textblock_linebreaking.cc:762) ==30983== by 0x809BB6E: dw::Textblock::wordWrap(int, bool) (textblock_linebreaking.cc:609) ==30983== by 0x809B6A9: dw::Textblock::processWord(int) (textblock_linebreaking.cc:441) ==30983== by 0x8098753: dw::Textblock::addText0(char const*, unsigned int, short, dw::core::style::Style*, dw::core::Requisition*) (textblock.cc:1694) ==30983== by 0x8097B02: dw::Textblock::addText(char const*, unsigned int, dw::core::style::Style*) (textblock.cc:1478) ==30983== by 0x8073F5C: Html_process_word(DilloHtml*, char const*, int) (html.cc:1216) ==30983== by 0x807A348: Html_write_raw(DilloHtml*, char*, int, int) (html.cc:3923) ==30983== by 0x80727A9: DilloHtml::write(char*, int, int) (html.cc:531) ==30983== Address 0x661e6bf is 1 bytes before a block of size 16 alloc'd ==30983== at 0x402AC41: malloc (vg_replace_malloc.c:270) ==30983== by 0x80A223F: dw::fltk::FltkPlatform::textToLower(char const*, int) (fltkplatform.cc:584) ==30983== by 0x809E86A: dw::Hyphenator::hyphenateWord(dw::core::Platform*, char const*, int*) (hyphenator.cc:223) ==30983== by 0x809C087: dw::Textblock::hyphenateWord(int) (textblock_linebreaking.cc:762) ==30983== by 0x809BB6E: dw::Textblock::wordWrap(int, bool) (textblock_linebreaking.cc:609) ==30983== by 0x809B6A9: dw::Textblock::processWord(int) (textblock_linebreaking.cc:441) ==30983== by 0x8098753: dw::Textblock::addText0(char const*, unsigned int, short, dw::core::style::Style*, dw::core::Requisition*) (textblock.cc:1694) ==30983== by 0x8097B02: dw::Textblock::addText(char const*, unsigned int, dw::core::style::Style*) (textblock.cc:1478) ==30983== by 0x8073F5C: Html_process_word(DilloHtml*, char const*, int) (html.cc:1216) ==30983== by 0x807A348: Html_write_raw(DilloHtml*, char*, int, int) (html.cc:3923) ==30983== by 0x80727A9: DilloHtml::write(char*, int, int) (html.cc:531) ==30983== by 0x8079D85: Html_callback(int, _CacheClient*) (html.cc:3799)

Dec. 31, 2012

Dpi_connect_socket retry

by jcid＠dillo.org

Hi, On Sat, Dec 29, 2012 at 05:44:22AM +0400, p37sitdu at lavabit.com wrote: > 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 > diff -r 8e10859b2aab src/IO/dpi.c > --- a/src/IO/dpi.c > +++ b/src/IO/dpi.c > @@ -641,7 +641,7 @@ > /* send authentication Key (the server closes sock_fd on error) */ > } else if (!(cmd = a_Dpip_build_cmd("cmd=%s msg=%s", "auth", SharedKey))) { > MSG_ERR("[Dpi_connect_socket] Can't make auth message.\n"); > - } else if (Dpi_blocking_write(sock_fd, cmd, strlen(cmd)) == -1) { > + } else if (-1 == -1) { > MSG_ERR("[Dpi_connect_socket] Can't send auth message.\n"); > } else { > ret = sock_fd; Ah, OK, now I see what you mean. There's a semantic ambiguity, the comment: /* send authentication Key (the server closes sock_fd on error) */ means: "if there's an error with the authentication" (I know because I wrote the comment). (and as the patch removed this comment) I made the same test but with: - } else if (!(cmd = a_Dpip_build_cmd("cmd=%s msg=%s", "auth", SharedKey))) { + } else if (!(cmd = a_Dpip_build_cmd("cmd=%s msg=%s","auth",SharedKey+1))) { and the CCC closes the file descriptor as expected. The error case you noticed exists, and although highly unlikely to happen, requires some thought. As from the test above, the socket is connected, then nothing is written to simulate an error, but the OS never sees an error, as it doesn't exist, and doesn't notify either end (IOW, it leaves the socket passively expecting for data to come). Now, the canonical way to handle the whole process should have been to build the CCC upon connect(), then try to authenticate, and let the CCC handle any errors that may come, but this is probably too much code for little gain, so it was all coded in Dpi_connect_socket(). The problem with closing FDs outside the CCC is that it can introduce race conditions, but in this case the CCC is partially built, so your patch suggestion may be OK. I'll have to give it some more thought and tests... -- Cheers Jorge.-

Dec. 30, 2012

ui colors again

by corvid＠lavabit.com

I wrote: > Perhaps it would be good to be able to change colors at runtime, especially > since we already allow the panel size to change. I'll have a look at that > color chooser that fltk has. Here's a quick little toy:

Dec. 30, 2012

show_url pref

by jcid＠dillo.org

On Sun, Dec 30, 2012 at 07:25:59PM +0000, corvid wrote: > > Since it's been broken throughout the dillo3 era, the other day I made it > so that you can't disable it -- and now I'm wondering what the value is in > even having the pref. Removing Location doesn't give us room for anything > more important. It's kind of like having a show_viewport preference. Yes, most probably nobody cares. ;) (nobody has missed it in all these time) Hide_panels is a different thing (much more useful). Probably it'd be good to remove the pref. -- Cheers Jorge.-

Dec. 30, 2012

show_url pref

by corvid＠lavabit.com

Since it's been broken throughout the dillo3 era, the other day I made it so that you can't disable it -- and now I'm wondering what the value is in even having the pref. Removing Location doesn't give us room for anything more important. It's kind of like having a show_viewport preference.

Dec. 30, 2012

ui colors again

by corvid＠lavabit.com

Jorge wrote: > * We may suggest some combinations in the web site or dillorc. > > This way, the traditional look can easily be set, new ones can > be created (suggested) and a default scheme voted. It would be nice if we had a sort of...minimal covering set of the different sorts of color schemes that a person could "sensibly" (whatever that can mean) want for the sake of testing. I imagine the world of graphic design must have such a thing (if only I knew the right words to find it)... Perhaps it would be good to be able to change colors at runtime, especially since we already allow the panel size to change. I'll have a look at that color chooser that fltk has. > Finally, @all, please recieve my best wishes for the new year > that's about to start! ;-) :)

Dec. 30, 2012

ui colors again

by corvid＠lavabit.com

Jorge wrote: > The default theme in dillo is kind of a consensus over the > years. This is, when changes were proposed, the most voted one > (or less objected) got to be the default (same for the website). I think we have a strong tendency to defer to you in general and end up with what Jorge likes, even if that's not your intention particularly. And of course the community is so tiny these days that we often get one vote or zero votes on something, dispiritingly enough. Last year, the opinions presented on the list on ripping out the hardcoded colors were: Benjamin brought it up, iirc, having done so with his fork. I liked the idea. Johannes liked the idea. > * The default colors should not be changed without consensus. It should be quite similar except that there's some white where we customarily have a greenish color. I'm not too crazy about the white, but I didn't want to make it the same greenish merely because it's what we had because then we'd all not notice it and/or accept it as the way it's always been. (The white of course being fltk's default.) I'm thinking that we come up with defaults for foreground and the two backgrounds and maybe selection color, and then put in contrast() and lighter() and darker() as necessary for visibility and pleasant appearance, but base everything on that set of colors instead of hardcoding anything to green or blue or whatever. > * The patch should provide a way to keep the previous default > (i.e. How do I get my colors/pixmaps back?) > > PS: WRT the second point, I find the inactive pixmaps too > "live" for my taste (and thus prefer the pixmaps). I initially wanted to make the inactive pixmaps look better with greyish or darkish backgrounds, and I used Fl_Image's inactive(), which just dims the pixmap down with some background color. But they didn't look inactive enough, so I went the desaturate() route after all, which is rather like using the pixmaps... So I haven't come up with anything that I'm happy enough with to really want to _advocate_ for. > PS2: Is good to have the input/dialog backgrounds configurable > but the defaults should be voted.

Dec. 30, 2012

ui colors again

by jcid＠dillo.org

On Sun, Dec 30, 2012 at 10:52:37AM -0300, Jorge Arellano Cid wrote: > On Sun, Dec 30, 2012 at 03:55:34AM +0000, corvid wrote: > > 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. > > -1 > > The default colors or theme are not easy to define, everybody has > his personal preferences, and there's no single scheme that pleases > everyone. > > The default theme in dillo is kind of a consensus over the > years. This is, when changes were proposed, the most voted one > (or less objected) got to be the default (same for the website). > > This policy works ok for us and is widely used. > > Personally I don't like the change, but I do understand that > other users, may find it fits better. > > So my points are: > > * The default colors should not be changed without consensus. > * The patch should provide a way to keep the previous default > (i.e. How do I get my colors/pixmaps back?) > > PS: WRT the second point, I find the inactive pixmaps too > "live" for my taste (and thus prefer the pixmaps). > PS2: Is good to have the input/dialog backgrounds configurable > but the defaults should be voted. Just trying to make my points a bit clearer, and after playing a bit more with the patch: * +1 to making it configurable (as now) * +1 to add a dillorc option for the second parameter in color_average() call (e.g. setting it to 0.1f makes for the same look as with the handmade pixmaps, so they could be removed). Adding a parameter for the first one may also help (although it's not a priority). * We may suggest some combinations in the web site or dillorc. This way, the traditional look can easily be set, new ones can be created (suggested) and a default scheme voted. Finally, @all, please recieve my best wishes for the new year that's about to start! ;-) -- Cheers Jorge.-

Dec. 30, 2012

CAPI ignores download requests when not in cache or handled by the downloads DPI.

by onepoint＠starurchin.org

I wondered why "Save link as" silently failed on some of my local web pages if I had not already visited the link. It turns out they were "file:///" links and "Save link as" sends a download request which the CAPI silently ignores if the URL is not cached and is not handled by the downloads DPI. I added a MSG_WARN to log this but haven't changed any behaviour. I still found it surprising and was wondering if it could be improved? Regards, Jeremy Henty

Dec. 30, 2012

ui colors again

by jcid＠dillo.org

On Sun, Dec 30, 2012 at 03:55:34AM +0000, corvid wrote: > 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. -1 The default colors or theme are not easy to define, everybody has his personal preferences, and there's no single scheme that pleases everyone. The default theme in dillo is kind of a consensus over the years. This is, when changes were proposed, the most voted one (or less objected) got to be the default (same for the website). This policy works ok for us and is widely used. Personally I don't like the change, but I do understand that other users, may find it fits better. So my points are: * The default colors should not be changed without consensus. * The patch should provide a way to keep the previous default (i.e. How do I get my colors/pixmaps back?) PS: WRT the second point, I find the inactive pixmaps too "live" for my taste (and thus prefer the pixmaps). PS2: Is good to have the input/dialog backgrounds configurable but the defaults should be voted. -- Cheers Jorge.-

Dec. 30, 2012

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

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

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. 26, 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

show_tooltip=NO

by jcid＠dillo.org

On Tue, Dec 25, 2012 at 12:42:52AM +0000, corvid wrote: > > tipwin still shows tooltips when show_tooltip=NO. Patch committed. -- Cheers Jorge.-

Dec. 26, 2012

vsource/dpip endless loop

by jcid＠dillo.org

On Wed, Dec 26, 2012 at 03:06:36AM +0000, corvid wrote: > > I have a recentish version of the html5 working draft as one page, and > it's over 6 megs. If I view source on it, this is rather slow and gives > me time to hit Escape and Ctrl-W. Then top shows vsource using all of > the processor until I kill it. > > (gdb) bt > #0 0x0804a843 in a_Dpip_dsh_read_token (dsh=0x9e7ae18, blocking=1) > at dpip.c:455 > #1 0x080491f9 in send_html_text (sh=0x9e7ae18, > url=0x9e7ced6 "file:/home/corvid/html5.html.gz", data_size=6402268) > at vsource.c:121 > #2 0x08049460 in main () at vsource.c:219 Patch committed. -- Cheers Jorge.-

Dec. 26, 2012

vsource/dpip endless loop

by jcid＠dillo.org

On Wed, Dec 26, 2012 at 03:06:36AM +0000, corvid wrote: > > I have a recentish version of the html5 working draft as one page, and > it's over 6 megs. If I view source on it, this is rather slow and gives > me time to hit Escape and Ctrl-W. Then top shows vsource using all of > the processor until I kill it. > > (gdb) bt > #0 0x0804a843 in a_Dpip_dsh_read_token (dsh=0x9e7ae18, blocking=1) > at dpip.c:455 > #1 0x080491f9 in send_html_text (sh=0x9e7ae18, > url=0x9e7ced6 "file:/home/corvid/html5.html.gz", data_size=6402268) > at vsource.c:121 > #2 0x08049460 in main () at vsource.c:219 Ah, yes. I'm testing a little patch for this now... -- Cheers Jorge.-

Dec. 26, 2012

vsource/dpip endless loop

by corvid＠lavabit.com

I have a recentish version of the html5 working draft as one page, and it's over 6 megs. If I view source on it, this is rather slow and gives me time to hit Escape and Ctrl-W. Then top shows vsource using all of the processor until I kill it. (gdb) bt #0 0x0804a843 in a_Dpip_dsh_read_token (dsh=0x9e7ae18, blocking=1) at dpip.c:455 #1 0x080491f9 in send_html_text (sh=0x9e7ae18, url=0x9e7ced6 "file:/home/corvid/html5.html.gz", data_size=6402268) at vsource.c:121 #2 0x08049460 in main () at vsource.c:219

Dec. 26, 2012

findbar behaviour

by jcid＠dillo.org

On Tue, Dec 25, 2012 at 07:08:26PM +0000, corvid wrote: > > When I want to change the case-sensitivity of a search, I don't like > having to switch to the mouse and aim it toward the little checkbox. > > So I looked up why we disable tabbing to the other widgets (and found > nothing). Then a little experimentation showed that triggering shortcuts > causes widgets to get focus, which we don't want. > > With that answered, I tried letting the input do its own callbacks upon > Enter or Shift-Enter, and letting everything accept focus. > > This isn't heavily tested, but I wanted to see how the idea goes over > first... Beware, this is tricky. I remember having worked on this simplifying a lot the UI, by trying to avoid custom code/classes for each widget. 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. -- Cheers Jorge.-

Dec. 25, 2012

findbar behaviour

by corvid＠lavabit.com

When I want to change the case-sensitivity of a search, I don't like having to switch to the mouse and aim it toward the little checkbox. So I looked up why we disable tabbing to the other widgets (and found nothing). Then a little experimentation showed that triggering shortcuts causes widgets to get focus, which we don't want. With that answered, I tried letting the input do its own callbacks upon Enter or Shift-Enter, and letting everything accept focus. This isn't heavily tested, but I wanted to see how the idea goes over first...

Dec. 25, 2012

show_tooltip=NO

by corvid＠lavabit.com

tipwin still shows tooltips when show_tooltip=NO.

Dec. 25, 2012

#1113 (was: How to link to a specific bug report?)

by abe＠deuxchevaux.org

Hi Corvid, On Mon, Dec 24, 2012 at 12:28:01AM +0000, corvid wrote: > As for the bug itself, at least, does the attached fix everything? Applied it against 3.0.2 with a little fuzz and it seems to work for me. Thanks! Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Dec. 24, 2012

How to link to a specific bug report?

by corvid＠lavabit.com

As for the bug itself, at least, does the attached fix everything?

Dec. 24, 2012

How to link to a specific bug report?

by abe＠deuxchevaux.org

Hi, I just submitted a (forwarded) bug report (#1113) and would like to link to it directly. Is there any query string parameter where I can enter the bug number? Neither "bug_number" like for the volunteer and remove CGI scripts does work nor does what=1113. In case there isn't such a featre yet, I'd be happy if you could at least e.g. <a name="1113">...</a> jump mark. Thta should be quite easy with regards to the CGI script's current output. TIA. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Dec. 23, 2012

Extensions for hyphenation

by sgeerken＠dillo.org

On Thu, Dec 20, corvid wrote: > The text spills over into the following cell in > > <table border=1> > <tr> > <td>W d<whatever>aaaaaaaaaaaa*<br> > <td>WW d<whatever>aaaaaaaaaaaa*<br> > <td>WWW d<whatever>aaaaaaaaaaaa*<br> > <td>WWWW d<whatever>aaaaaaaaaaaa*<br> > <td>WWWWW d<whatever>aaaaaaaaaaaa*<br> > <td>WWWWWW d<whatever>aaaaaaaaaaaa*<br> > > </table> > > if I make the browser window narrowish. Fixed. Sebastian

Dec. 23, 2012

ui colors again

by corvid＠lavabit.com

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. One difference from the previous code is that I'm using inactive() on the images for inactive toolbar buttons because our gray pixmaps tend not to look so good with different UI colors. It might be good to pull it somewhat closer to the background color, but I'm not sure yet. * Under X, FLTK tries to "Read colors that KDE writes to the xrdb database", which may or may not work fine for those people running KDE, but...

Dec. 21, 2012