- Dillo-dev - lists.mailman3.com

[patch] dClose

by p37sitdu＠lavabit.com

Merged a_Misc_close_fd, Dpi_close_fd and Http_socket_close into dClose and moved it into dlib. Replaced close calls with calls to dClose.

Jan. 9, 2013

drawing highlighting

by sgeerken＠dillo.org

On Tue, Jan 08, corvid wrote: > > I was looking at draw() calls for the view, and I saw how there was a > call for every time that the mouse moved when highlighting even though > the text highlighted didn't necessarily change. > > Here's quick code to demonstrate that there are plenty of redundant ones. > I don't know the iterator code well enough to know whether that's the > right place to do anything about it, though... Your patch makes sense, and I've committed it (slightly changed). The purpose of Iterator::highlight is to change a state, and so it should be checked, whether the state has changed at all. Sebastian

Jan. 9, 2013

font_factor

by johannes.hofmann＠gmx.de

On Tue, Jan 08, 2013 at 11:55:42PM +0000, corvid wrote: > > I wrote: > > In styleengine, we use font_factor for calculation of larger and x-small > > and so forth, but we don't apply it when given an ordinary font size like > > 11px. > > Just to double-check: That's not intended behaviour, right? > sorry for the delay... This is intentional, but we know that there is a usability issue. In CSS px, mm, pt etc. define absolute sizes [1]. So if we want to adhere to the CSS spec strictly I think we can't just scale them. On the other hand web designers just use px without thinking about the implications. Also other browsers allow scaling of those fonts afaik. I think we have the following options: * ignore CSS and apply font_factor also to absolute font sizes * implement a zoom feature that displays everything larger (also images etc. * check other browsers for more alternatives [1] http://www.w3.org/TR/CSS21/fonts.html#font-size-props

Jan. 9, 2013

[patch] consistent file save UI behaviour for overwriting files

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > These two patches move the UI logic from the downloads DPI into > > Dillo. This puts all the UI logic in the same place and ensures > > consistent behaviour for "Save link as file" whether or not the > > URL is cached. > > Seems good to have the logic in dillo. OK, it's in. > I imagine a later step would be to teach UIcmd_save_file_check() > about file permissions, errno possibilities, etc. I guess so, although in the case of the file not existing you would want to check whether the missing component was the last one in the path or not. Regards, Jeremy Henty

Jan. 8, 2013

dillo3.0.2 Irix

by corvid＠lavabit.com

Jan wrote: > Nothing new with this patch. I found out it is not random, it > depends on the length: > > I can open: > > file:/tmp/12345678901234567890123.jpg > > but > > file:/tmp/123456789012345678901234.jpg > > returns a 404 32-byte limit? The first thing that popped into my mind was that sufficiently ancient systems would have path length limits like 32, but I don't see why that would apply here... dpi/file.c's File_normalize_path() has a "Dstr *ds = dStr_sized_new(32)". You could change the number and see whether anything happens. Although if Dstr should have problems resizing itself on irix, I'd be very surprised that dillo could even run at all.

Jan. 8, 2013

Patch for xembed updated

by Johannes.Hofmann＠gmx.de

Hi, On Sat, Jan 05, 2013 at 10:56:00AM +0100, podarcis wrote: > Hi, > > I have updated my patch (no removal of existing code, added > comments, trimmed the source,..). > > Let me perhaps explain from the beginning: > > My starting point was, that when embedding dillo from an external > program using the --xid parameter, dillo's window didn't show up in > the embedder. Thanks for the updated patches and the background info. Here is some background info on the xembed stuff from my side: dillo2 supported xembed more or less automatically as it was based on gtk2. The claws-mail dillo plugin used this feature to display html. When porting dillo to fltk we had to implement xembed on our own or break support for the claws-mail plugin. That's why we added xembed.cc. > > I have now found, there's a one-line fix for that problem: > > -> dillo_xembed_patch_1.txt I tend to commit this, but I still need to double check that it doesn't cause any problems. The advantage is that it will give some initial encouraging result if someone tries out --xid without a fullblown xembed implementation. > > After that was working again (by the way: it worked in dillo2 > already) I tried to make resizing of the embedder window work too: > > -> dillo_xembed_patch_2.txt > > A test program for all this: > > -> dembed.cxx I would prefer a minimal fltk-based example program in the test directory, that implements the embedder side of xembed. It shouldn't be too hard to do (e.g. by looking at the tabbed sources). It would be cool if you would like to work on that. BTW. we use a pretty restricted set of C++ features in the dillo source tree (e.g. we don't use iostream). Cheers, Johannes

Jan. 8, 2013

dillo3.0.2 Irix

by corvid＠lavabit.com

Jan wrote: > sometimes you get a 404 error when you try to open a html file, > this behavior seems to be random. Hmm... I wonder whether this would show anything interesting (run 'dpidc stop' before reinstalling DPIs) diff -r 7750054f37e5 dpi/file.c --- a/dpi/file.c Mon Jan 07 21:39:19 2013 +0100 +++ b/dpi/file.c Tue Jan 08 18:42:22 2013 +0000 @@ -671,6 +671,8 @@ struct stat sb; if (stat(filename, &sb) != 0) { + MSG("Couldn't stat %s: %s\n", filename, strerror(errno)); + /* stat failed, prepare a file-not-found error. */ res = ENOENT; } else if (S_ISDIR(sb.st_mode)) {

Jan. 8, 2013

dillo3.0.2 Irix

by diegel＠work.de

Thanks for your hints. The browser is able to render html. about:splash looks normal and sometimes you can open html files with the open file menu, sometimes you get a 404 error when you try to open a html file, this behavior seems to be random. I set VERBOSE. This is the output when I start dillo, try to surf home (don't work) and open a JPEG in the /tmp directory (works). src/dillo paths: Cannot open file '/usr/people/diegel/.dillo/dillorc' paths: Using /usr/local/etc/dillo/dillorc paths: Cannot open file '/usr/people/diegel/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (not threaded) Disabling cookies. ** WARNING **: preferred sans-serif font "DejaVu Sans" not found. ** WARNING **: preferred serif font "DejaVu Serif" not found. ** WARNING **: preferred monospace font "DejaVu Sans Mono" not found. sorcerer:/mnt/build/dillo-3.0.2> src/dillo paths: Cannot open file '/usr/people/diegel/.dillo/dillorc' paths: Using /usr/local/etc/dillo/dillorc paths: Cannot open file '/usr/people/diegel/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (not threaded) Disabling cookies. ** WARNING **: preferred sans-serif font "DejaVu Sans" not found. ** WARNING **: preferred serif font "DejaVu Serif" not found. ** WARNING **: preferred monospace font "DejaVu Sans Mono" not found. ** WARNING **: preferred cursive font "URW Chancery L" not found. ** WARNING **: preferred fantasy font "DejaVu Sans" not found. Nav_open_url: new url='about:splash' Nav_open_url: new url='http://www.dillo.org/' a_Capi_ccc : OpStart [2B] Info=10250a38 Flags=0 a_Dpi_ccc : OpStart [2B] Info=10250a60 Flags=0 a_IO_ccc : OpStart [2B] Info=10250a88 Flags=0 a_Capi_ccc : OpStart [1B] Info=10250ad8 Flags=0 a_Http_ccc : OpStart [1B] Info=10250b00 Flags=0 a_IO_ccc : OpStart [1B] Info=10250b50 Flags=0 Dns_server [0]: www.dillo.org is 134.102.206.165 Connecting to 134.102.206.165 a_IO_ccc : OpSend [1B] Info=10250b50 Flags=0 a_Capi_ccc : OpSend [1F] Info=10250ad8 Flags=0 a_Capi_ccc : OpSend [2B] Info=10250a38 Flags=0 a_Dpi_ccc : OpSend [2B] Info=10250a60 Flags=0 a_IO_ccc : OpSend [2B] Info=10250a88 Flags=0 a_IO_ccc : OpSend [1B] Info=10250b50 Flags=0 Nav_open_url: new url='file:/tmp/orfanelle.jpg' a_Capi_ccc : OpAbort [1B] Info=10250ad8 Flags=0 a_Http_ccc : OpAbort [1B] Info=10250b00 Flags=0 a_IO_ccc : OpAbort [1B] Info=10250b50 Flags=0 a_Capi_ccc : OpAbort [2B] Info=10250a38 Flags=0 a_Dpi_ccc : OpAbort [2B] Info=10250a60 Flags=0 a_IO_ccc : OpAbort [2B] Info=10250a88 Flags=0 a_Capi_ccc : OpStart [2B] Info=10250bf0 Flags=0 a_Dpi_ccc : OpStart [2B] Info=10250a38 Flags=0 a_IO_ccc : OpStart [2B] Info=10250a60 Flags=0 a_Capi_ccc : OpStart [1B] Info=10250ab0 Flags=0 a_Dpi_ccc : OpStart [1B] Info=10250ad8 Flags=0 ** ERROR **: [Dpi_read_comm_keys] No such file or directory Dpi_blocking_start_dpid: try 1 [dpid]: a_Misc_mksecret: f3f0000d dpid started a_IO_ccc : OpStart [1B] Info=10250b00 Flags=0 a_IO_ccc : OpSend [1B] Info=10250b00 Flags=0 a_Capi_ccc : OpSend [1F] Info=10250ab0 Flags=0 a_Capi_ccc : OpSend [2B] Info=10250bf0 Flags=0 a_Dpi_ccc : OpSend [2B] Info=10250a38 Flags=0 a_IO_ccc : OpSend [2B] Info=10250a60 Flags=0 a_Capi_ccc : OpSend [1F] Info=10250ab0 Flags=0 a_Capi_ccc : OpSend [1B] Info=10250ab0 Flags=0 a_Dpi_ccc : OpSend [1B] Info=10250ad8 Flags=0 a_IO_ccc : OpSend [1B] Info=10250b00 Flags=0 [file dpi]: (v.2) accepting connections... a_IO_ccc : OpSend [2F] Info=10250a60 Flags=0 a_Dpi_ccc : OpSend [2F] Info=10250a38 Flags=0 a_Capi_ccc : OpSend [2F] Info=10250bf0 Flags=0 a_Capi_ccc : OpSend [2F] Info=10250bf0 Flags=0 a_IO_ccc : OpSend [2F] Info=10250a60 Flags=0 a_Dpi_ccc : OpSend [2F] Info=10250a38 Flags=0 a_Capi_ccc : OpSend [2F] Info=10250bf0 Flags=0 a_IO_ccc : OpSend [2F] Info=10250a60 Flags=0 a_Dpi_ccc : OpSend [2F] Info=10250a38 Flags=0 a_Capi_ccc : OpSend [2F] Info=10250bf0 Flags=0 a_IO_ccc : OpEnd [2F] Info=10250a60 Flags=0 a_Dpi_ccc : OpEnd [2F] Info=10250a38 Flags=0 a_Capi_ccc : OpEnd [2F] Info=10250bf0 Flags=0 a_Capi_ccc : OpEnd [1B] Info=10250ab0 Flags=0 a_Dpi_ccc : OpEnd [1B] Info=10250ad8 Flags=0 a_IO_ccc : OpEnd [1B] Info=10250b00 Flags=0 The tests provide some output. The cookies test for esample outputs endless: [cookies dpi]: Disabling cookies. [cookies dpi]: (v.1) accepting connections... [cookies dpi]: cleanup corvid wrote: > Do the dw* programs in dillo's test directory do anything? > > Given that you aren't getting any repush messages, I'm guessing that > they'll be reasonably okay and that it's something to do with IO. > > I'm not the expert on that code, but in the interest of giving something > to try in the meantime, I might start by setting breakpoints on > IO_fd_write_cb() and IO_fd_read_cb(), or setting VERBOSE in src/chain.c. > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > > -- Jan Diegelmann

Jan. 8, 2013

dillo3.0.2 Irix

by corvid＠lavabit.com

Jan wrote: > I try to port dillo 3.0.2 to Irix: > > fltk 1.3 compiles fine with gcc 4.7. test/demo runs without errors. > > dillo compiles also with gcc 4.7, there is only a problem with setenv in > dpi/downloads.cc, that can be resolved using putenv. > > dillo starts correctly, but is not able to display any website or file: > > > dillo > paths: Cannot open file '/usr/people/diegel/.dillo/dillorc' > paths: Using /usr/local/etc/dillo/dillorc > paths: Cannot open file '/usr/people/diegel/.dillo/keysrc' > paths: Using /usr/local/etc/dillo/keysrc > dillo_dns_init: Here we go! (threaded) > Disabling cookies. > ** WARNING **: preferred sans-serif font "DejaVu Sans" not found. > ** WARNING **: preferred serif font "DejaVu Serif" not found. > ** WARNING **: preferred monospace font "DejaVu Sans Mono" not found. > ** WARNING **: preferred cursive font "URW Chancery L" not found. > ** WARNING **: preferred fantasy font "DejaVu Sans" not found. > Nav_open_url: new url='about:splash' > Nav_open_url: new url='http://www.dillo.org/' > Dns_server [0]: www.dillo.org is 134.102.206.165 > Connecting to 134.102.206.165 > Nav_open_url: new > url='file:/usr/people/diegel/dillo/www.dillo.org/index.html' > > I also tried with --disable-threaded-dns but same result. > > Any idea how to debug this problem? Do the dw* programs in dillo's test directory do anything? Given that you aren't getting any repush messages, I'm guessing that they'll be reasonably okay and that it's something to do with IO. I'm not the expert on that code, but in the interest of giving something to try in the meantime, I might start by setting breakpoints on IO_fd_write_cb() and IO_fd_read_cb(), or setting VERBOSE in src/chain.c.

Jan. 8, 2013

Gopher DPI

by p37sitdu＠lavabit.com

Added telnet:// URI support (type '8').

Jan. 8, 2013

dillo3.0.2 Irix

by diegel＠work.de

Hello, I try to port dillo 3.0.2 to Irix: fltk 1.3 compiles fine with gcc 4.7. test/demo runs without errors. dillo compiles also with gcc 4.7, there is only a problem with setenv in dpi/downloads.cc, that can be resolved using putenv. dillo starts correctly, but is not able to display any website or file: > dillo paths: Cannot open file '/usr/people/diegel/.dillo/dillorc' paths: Using /usr/local/etc/dillo/dillorc paths: Cannot open file '/usr/people/diegel/.dillo/keysrc' paths: Using /usr/local/etc/dillo/keysrc dillo_dns_init: Here we go! (threaded) Disabling cookies. ** WARNING **: preferred sans-serif font "DejaVu Sans" not found. ** WARNING **: preferred serif font "DejaVu Serif" not found. ** WARNING **: preferred monospace font "DejaVu Sans Mono" not found. ** WARNING **: preferred cursive font "URW Chancery L" not found. ** WARNING **: preferred fantasy font "DejaVu Sans" not found. Nav_open_url: new url='about:splash' Nav_open_url: new url='http://www.dillo.org/' Dns_server [0]: www.dillo.org is 134.102.206.165 Connecting to 134.102.206.165 Nav_open_url: new url='file:/usr/people/diegel/dillo/www.dillo.org/index.html' I also tried with --disable-threaded-dns but same result. Any idea how to debug this problem? Thank you, Jan

Jan. 8, 2013

drawing highlighting

by corvid＠lavabit.com

I was looking at draw() calls for the view, and I saw how there was a call for every time that the mouse moved when highlighting even though the text highlighted didn't necessarily change. Here's quick code to demonstrate that there are plenty of redundant ones. I don't know the iterator code well enough to know whether that's the right place to do anything about it, though...

Jan. 8, 2013

Scripts in dillo

by sgeerken＠dillo.org

Hi! This is something which has been laying around for several years: At <http://www.dillo.org/~sgeerken/objman-test-0.0.1.tar.bz2>, you'll find some code which may be useful for dealing with scripts in dillo. Currently not very much: - After configure && make, run test/guile-test and look what happens. Look at the code. - Run doxygen and read some documentation. Of course, until a full script implementation, there is still much work to be done (and I'll work on different things in the next time), but perhaps you'll have some fun with it. This uses Guile, so suggesting Scheme as a script language. The only reason for this is that I happen to be a bit familiar with libguile. It is simple to integrate other interpreters. Sebastian

Jan. 7, 2013

ui colors again

by corvid＠lavabit.com

Jorge wrote: > Of course it should also be able to manage saving the custom > defined theme. Do you mean saving things to dillorc?

Jan. 6, 2013

[patch] consistent file save UI behaviour for overwriting files

by corvid＠lavabit.com

Jeremy wrote: > These two patches move the UI logic from the downloads DPI into Dillo. > This puts all the UI logic in the same place and ensures consistent > behaviour for "Save link as file" whether or not the URL is cached. Seems good to have the logic in dillo. I imagine a later step would be to teach UIcmd_save_file_check() about file permissions, errno possibilities, etc.

Jan. 6, 2013

[patch] modified a_Dialog_choice5 to accept any number alternatives

by corvid＠lavabit.com

p37sitdu wrote: > -5 LOC, nothing is changed visually I haven't looked at it carefully or anything, but I like the idea of not being hardcoded to five anymore... PS I made a choice5 once to fit the long error msgs from https, but it was vetoed (can't remember exactly why).

Jan. 6, 2013

[patch] consistent file save UI behaviour for overwriting files

by onepoint＠starurchin.org

The UI for downloading files is split between Dillo (which prompts for a file to save to) and the downloads DPI (which prompts for another file if the first file already exists). This leads to inconsistent behaviour for "Save link as file" depending on whether the URL is cached or not - if it is cached then any existing file is silently overwritten but if it is not cached we go to the downloads DPI which prompts before overwriting anything. These two patches move the UI logic from the downloads DPI into Dillo. This puts all the UI logic in the same place and ensures consistent behaviour for "Save link as file" whether or not the URL is cached. http://starurchin.org/dillo/patch/downloads-dpi_file_test_remove.html http://starurchin.org/dillo/patch/uicmd-cc_file_test_add.html Comments? Shall I push this? Regards, Jeremy Henty

Jan. 6, 2013

[patch] modified a_Dialog_choice5 to accept any number alternatives

by p37sitdu＠lavabit.com

-5 LOC, nothing is changed visually

Jan. 5, 2013

autotools

by p37sitdu＠lavabit.com

There is autogen.sh in source tree. It can be replaced with "autoreconf -i" or simply removed. According to ChangeLog of autoconf, autoreconf has been there for at least 10 years. I also looked at configure.ac. In attached patch I added dillo URL, used AS_HELP_STRING to format help lines, replaced AC_ERROR with AC_MSG_ERROR (it was renamed) and replaced -D flags with AC_DEFINE. If no config.h is used, flags should be added to DEFS variable, but with config.h they should be defined in config.h using AC_DEFINE. The problem is that not all files include config.h. I added #includes where necessary, but to avoid problems when some files see defines and some files don't, config.h should be included by every .c and .cc file before all other includes.

Jan. 5, 2013

[patch] remove redundant check in cache.c

by jcid＠dillo.org

On Sat, Jan 05, 2013 at 05:55:03PM +0400, p37sitdu at lavabit.com wrote: > > # HG changeset patch > # Parent 9195a2df5ca310cc907f3d5df3593acaed988820 > > diff -r 9195a2df5ca3 src/cache.c > --- a/src/cache.c > +++ b/src/cache.c > @@ -233,7 +233,7 @@ > break; > } > /* Test for a working redirection */ > - if (entry && entry->Flags & CA_Redirect && entry->Location) { > + if (entry->Flags & CA_Redirect && entry->Location) { > Url = entry->Location; > } else > break; Committed. -- Cheers Jorge.-

Jan. 5, 2013

[patch] remove redundant check in cache.c

by p37sitdu＠lavabit.com

Jan. 5, 2013

Patch for xembed updated

by podarcis＠lavabit.com

Hi, I have updated my patch (no removal of existing code, added comments, trimmed the source,..). Let me perhaps explain from the beginning: My starting point was, that when embedding dillo from an external program using the --xid parameter, dillo's window didn't show up in the embedder. I have now found, there's a one-line fix for that problem: -> dillo_xembed_patch_1.txt After that was working again (by the way: it worked in dillo2 already) I tried to make resizing of the embedder window work too: -> dillo_xembed_patch_2.txt A test program for all this: -> dembed.cxx Looking forward for your comments. Cheers, Podarcis P.S.: I am aware now, that *real* embedding (to make tab-switching and focus-handling work together with the embedder) will require the usage of the xembed-protocol from the embedder side. I didn't touch the existing part of this implementation. But I guess embedding dillo without caring for this issues may be useful too, for example to just display help pages (no focus handling or tabbing required).

Jan. 5, 2013

ui colors again

by jcid＠dillo.org

On Thu, Jan 03, 2013 at 06:42:19AM +0000, corvid wrote: > > I added some more to the color choosing stuff: > > http://www.dillo.org/test/choose_colors2.diff Good. Just this minor fix to compile. diff -r cc706f9310db src/menu.cc --- a/src/menu.cc Fri Jan 04 12:13:39 2013 -0300 +++ b/src/menu.cc Fri Jan 04 16:53:20 2013 -0300 @@ -675,7 +675,7 @@ static Fl_Color get_label_color(int32_t static void Menu_base_color_change_cb(Fl_Widget*, void *user_data) { - Fl_Color colornum = (Fl_Color)user_data; + Fl_Color colornum = VOIDP2INT(user_data); int old_rgb = Fl::get_color(colornum); uchar r = old_rgb >> 24, g = (old_rgb >> 16) & 0xff, > > It's not terribly nice, careful code at this point. > It knows about the more recent prefs, and I spent some time making > the menu fancy for some reason. It helps a lot with making themes. BTW, a greenish one: ui_fg_color=#100404 ui_main_bg_color=#c8d394 ui_text_bg_color=#bdd8b6 ui_selection_color=#7c5f42 ui_button_highlight_color=#bdbd80 ui_tab_active_bg_color=#b5b679 ui_tab_active_fg_color=#b60907 ui_tab_bg_color=#cac682 -- Cheers Jorge.-

Jan. 4, 2013

ui colors again

by jcid＠dillo.org

On Wed, Jan 02, 2013 at 09:23:49PM +0000, corvid wrote: > > BTW, although our John Grantham icons hold up well when the background is > dark, the others don't do as well. It's a pity that I don't have the artistic > background to mimic his... I can try to enhance mine a bit, but as the problem shows, I'm by no means in the same league as John Grantham. ;-) -- Cheers Jorge.-

Jan. 4, 2013

ui colors again

by jcid＠dillo.org

On Fri, Jan 04, 2013 at 11:54:20AM +0400, p37sitdu at lavabit.com wrote: > On Thu, Jan 03, 2013 at 11:01:10PM -0300, Jorge Arellano Cid wrote: > > My fault, should have been: > > ... > > ui_tab_active_fg_color=#white > > ... > > Should be > ui_tab_active_fg_color=white Right (an overworked me). -- Cheers Jorge.-

Jan. 4, 2013

hanging in textblock

by sgeerken＠dillo.org

On Thu, Jan 03, corvid wrote: > Sebastian wrote: > > On Thu, Jan 03, corvid wrote: > > > http://graphicssoft.about.com/od/aboutgraphics/a/bitmapvector.htm > > > > > > #0 0x080929ad in dw::Textblock::findParagraphOfWord (this=0x82268b0, > > > wordIndex=81) at textblock.cc:1228 > > > > Does it really hang here? If you apply the first patch, what is the > > result (last couple of printed lines)? > > It looks like I often have to hit reload a couple of times. Still no "luck" ... > > OTOH, I've found a similar problem in the floats tree, which may occur > > (with other symptoms) here. Does applying the second patch solve the > > problem? > > Yup. So I've committed it. Does not harm (still more efficient than before), and examining it is on my todo list. Sebastian

Jan. 4, 2013

ui colors again

by p37sitdu＠lavabit.com

On Thu, Jan 03, 2013 at 11:01:10PM -0300, Jorge Arellano Cid wrote: > My fault, should have been: > ... > ui_tab_active_fg_color=#white > ... Should be ui_tab_active_fg_color=white

Jan. 4, 2013

ui colors again

by jcid＠dillo.org

On Thu, Jan 03, 2013 at 08:13:03PM +0000, corvid wrote: > Jorge wrote: > > FWIW, an earthly theme sample with the new prefs: > > > > ui_fg_color= 100404 > > ui_main_bg_color=c2a47b > > ui_text_bg_color=cdc9a5 > > ui_selection_color=763024 > > ui_tab_active_bg_color=af4b3f > > ui_tab_active_fg_color=white > > ui_tab_bg_color=d2b48c > > It's nice. > > Should we regard bare hex as proper and legal? a_Color_parse() currently > calls it an error but parses it anyway. My fault, should have been: ui_fg_color=#100404 ui_main_bg_color=#c2a47b ui_text_bg_color=#cdc9a5 ui_selection_color=#763024 ui_tab_active_bg_color=#af4b3f ui_tab_active_fg_color=#white ui_tab_bg_color=#d2b48c -- Cheers Jorge.-

Jan. 4, 2013

hanging in textblock

by corvid＠lavabit.com

Sebastian wrote: > On Thu, Jan 03, corvid wrote: > > http://graphicssoft.about.com/od/aboutgraphics/a/bitmapvector.htm > > > > #0 0x080929ad in dw::Textblock::findParagraphOfWord (this=0x82268b0, > > wordIndex=81) at textblock.cc:1228 > > Does it really hang here? If you apply the first patch, what is the > result (last couple of printed lines)? It looks like I often have to hit reload a couple of times. findParagraphOfWord (0), in 0 paragraphs ... .. --> not found findParagraphOfWord (0), in 0 paragraphs ... .. --> not found findParagraphOfWord (0), in 0 paragraphs ... .. --> not found findParagraphOfWord (0), in 0 paragraphs ... .. --> not found findParagraphOfWord (0), in 0 paragraphs ... .. --> not found findParagraphOfWord (0), in 0 paragraphs ... .. --> not found findParagraphOfWord (81), in 14 paragraphs ... > OTOH, I've found a similar problem in the floats tree, which may occur > (with other symptoms) here. Does applying the second patch solve the > problem? Yup.

Jan. 3, 2013

hanging in textblock

by sgeerken＠dillo.org

I was not able to reproduce this bug, but ... On Thu, Jan 03, corvid wrote: > http://graphicssoft.about.com/od/aboutgraphics/a/bitmapvector.htm > > #0 0x080929ad in dw::Textblock::findParagraphOfWord (this=0x82268b0, > wordIndex=81) at textblock.cc:1228 Does it really hang here? If you apply the first patch, what is the result (last couple of printed lines)? OTOH, I've found a similar problem in the floats tree, which may occur (with other symptoms) here. Does applying the second patch solve the problem? Sebastian

Jan. 3, 2013

ui colors again

by corvid＠lavabit.com

Jorge wrote: > FWIW, an earthly theme sample with the new prefs: > > ui_fg_color= 100404 > ui_main_bg_color=c2a47b > ui_text_bg_color=cdc9a5 > ui_selection_color=763024 > ui_tab_active_bg_color=af4b3f > ui_tab_active_fg_color=white > ui_tab_bg_color=d2b48c It's nice. Should we regard bare hex as proper and legal? a_Color_parse() currently calls it an error but parses it anyway.

Jan. 3, 2013

ui colors again

by jcid＠dillo.org

On Wed, Jan 02, 2013 at 09:05:16PM +0000, corvid wrote: > Jorge wrote: > > For instance, adding these vars to the current set: > > > > tab_bg_color, tab_fg_color, > > tab_text_active_color, tab_text_inactive_color > > ui_button_highlight_color > > menu_active_item_color, > > > > would allow for huge themability options. > > > > I know it looks like an overkill, but yesterday, playing with > > the "toy" color chooser, with colors/themes I never use, found > > that some of our "good defaults" are poor choices for completely > > different color schemes. > > > > The good part is that with a detailed color vars set, a theme > > becomes a small set of integers. Quite easy to handle. > > Okay, I'll add a bunch of prefs for us to experiment with. FWIW, an earthly theme sample with the new prefs: ui_fg_color= 100404 ui_main_bg_color=c2a47b ui_text_bg_color=cdc9a5 ui_selection_color=763024 ui_tab_active_bg_color=af4b3f ui_tab_active_fg_color=white ui_tab_bg_color=d2b48c -- Cheers Jorge.-

Jan. 3, 2013

hanging in textblock

by corvid＠lavabit.com

http://graphicssoft.about.com/od/aboutgraphics/a/bitmapvector.htm #0 0x080929ad in dw::Textblock::findParagraphOfWord (this=0x82268b0, wordIndex=81) at textblock.cc:1228 #1 0x0809a3c7 in dw::Textblock::fillParagraphs (this=0x82268b0) at textblock_linebreaking.cc:1115 #2 0x0809169c in dw::Textblock::getExtremesImpl (this=0x82268b0, extremes=0xbfffe828) at textblock.cc:299 #3 0x080b48cc in dw::core::Widget::getExtremes (this=0x82268b0, extremes=0xbfffe828) at widget.cc:194 #4 0x08098276 in dw::Textblock::accumulateWordExtremes ( this=this at entry=0x822b460, firstWord=firstWord at entry=10, lastWord=lastWord at entry=11, maxOfMinWidth=maxOfMinWidth at entry=0xbfffe898, sumOfMaxWidth=sumOfMaxWidth at entry=0xbfffe89c) at textblock_linebreaking.cc:412 #5 0x08099eab in dw::Textblock::addLine (this=this at entry=0x822b460, firstWord=firstWord at entry=10, lastWord=lastWord at entry=11, temporary=temporary at entry=false) at textblock_linebreaking.cc:328 #6 0x0809aca0 in dw::Textblock::wordWrap (this=0x822b460, wordIndex=11, wrapAll=false) at textblock_linebreaking.cc:596 #7 0x0809a278 in dw::Textblock::rewrap (this=0x822b460) at textblock_linebreaking.cc:1071 #8 0x080914fc in dw::Textblock::sizeRequestImpl (this=0x822b460, requisition=0x8244898) at textblock.cc:217 #9 0x080b483f in dw::core::Widget::sizeRequest (this=0x822b460, requisition=0x8244898) at widget.cc:177 #10 0x08091b92 in dw::Textblock::calcWidgetSize (this=0x82dae38, widget=0x822b460, size=0x8244898) at textblock.cc:768 #11 0x0809a2ba in dw::Textblock::rewrap (this=0x82dae38) at textblock_linebreaking.cc:1069 #12 0x080914fc in dw::Textblock::sizeRequestImpl (this=0x82dae38, requisition=0x8258078) at textblock.cc:217 #13 0x080b483f in dw::core::Widget::sizeRequest (this=0x82dae38, requisition=0x8258078) at widget.cc:177 #14 0x08091b92 in dw::Textblock::calcWidgetSize (this=0x82e1300, widget=0x82dae38, size=0x8258078) at textblock.cc:768 #15 0x0809a2ba in dw::Textblock::rewrap (this=0x82e1300) at textblock_linebreaking.cc:1069 #16 0x080914fc in dw::Textblock::sizeRequestImpl (this=0x82e1300, requisition=0x824bd80) at textblock.cc:217 #17 0x080b483f in dw::core::Widget::sizeRequest (this=0x82e1300, requisition=0x824bd80) at widget.cc:177 #18 0x08091b92 in dw::Textblock::calcWidgetSize (this=0x822d870, widget=0x82e1300, size=0x824bd80) at textblock.cc:768 #19 0x0809a2ba in dw::Textblock::rewrap (this=0x822d870) at textblock_linebreaking.cc:1069 #20 0x080914fc in dw::Textblock::sizeRequestImpl (this=0x822d870, requisition=0x81e64b8) at textblock.cc:217 #21 0x080b483f in dw::core::Widget::sizeRequest (this=0x822d870, requisition=0x81e64b8) at widget.cc:177 #22 0x08091b92 in dw::Textblock::calcWidgetSize (this=0x8278530, widget=0x822d870, size=0x81e64b8) at textblock.cc:768 #23 0x0809a2ba in dw::Textblock::rewrap (this=0x8278530) at textblock_linebreaking.cc:1069 #24 0x080914fc in dw::Textblock::sizeRequestImpl (this=0x8278530, requisition=0xbfffee40) at textblock.cc:217 #25 0x080b483f in dw::core::Widget::sizeRequest (this=0x8278530, requisition=0xbfffee40) at widget.cc:177 #26 0x080ade2c in dw::core::Layout::resizeIdle (this=0x820f448) at layout.cc:667 #27 0x0809faa8 in dw::fltk::FltkPlatform::generalIdle (this=0x820f410) at fltkplatform.cc:630 #28 0x080ef3b1 in call_idle () at Fl_add_idle.cxx:40 #29 0x080b88e4 in Fl::wait (time_to_wait=1e+20) at Fl.cxx:496 #30 0x080b89c0 in Fl::run () at Fl.cxx:529 #31 0x0804f7f9 in main (argc=1, argv=0xbffff044) at dillo.cc:498

Jan. 3, 2013

ui colors again

by corvid＠lavabit.com

I added some more to the color choosing stuff: http://www.dillo.org/test/choose_colors2.diff It's not terribly nice, careful code at this point. It knows about the more recent prefs, and I spent some time making the menu fancy for some reason. If we can't get the inactive icons at least nearly for free, I'm tempted to go back to the old ones instead of adding special code. (I didn't initially expect us to have much if any of a runtime mechanism to change colors.) I suspect the Tabs doesn't want to send the redraw() down to the tab buttons because of damage bits or something, but I ran out of steam on this for the night...

Jan. 3, 2013

ui colors again

by jcid＠dillo.org

On Wed, Jan 02, 2013 at 09:05:16PM +0000, corvid wrote: > Jorge wrote: > > For instance, adding these vars to the current set: > > > > tab_bg_color, tab_fg_color, > > tab_text_active_color, tab_text_inactive_color > > ui_button_highlight_color > > menu_active_item_color, > > > > would allow for huge themability options. > > > > I know it looks like an overkill, but yesterday, playing with > > the "toy" color chooser, with colors/themes I never use, found > > that some of our "good defaults" are poor choices for completely > > different color schemes. > > > > The good part is that with a detailed color vars set, a theme > > becomes a small set of integers. Quite easy to handle. > > Okay, I'll add a bunch of prefs for us to experiment with. Good. Attached goes some test code I used to test tab colors. HTH. FWIW, I get close to the traditional colors with: ui_fg_color=140040 ui_main_bg_color=c6c6c6 ui_text_bg_color=bfdabf ui_tab_active_color=87aca7 ui_tab_inactive_color=silver > > Ideally yes. Now, it needs some care. For instance, the "toy" > > chooser changes ui background well, but doesn't update the colors > > of inactive buttons with the new backgrounds (which makes a huge > > difference with bluish backgrounds. e.g. ui_main_bg_color=0070c0). > > Yeah, I'll put a little more time into the toy later. Background also > needs to update the gray ramp so that box colors work better, for > instance... OK. -- Cheers Jorge.-

Jan. 2, 2013

ui colors again

by corvid＠lavabit.com

BTW, although our John Grantham icons hold up well when the background is dark, the others don't do as well. It's a pity that I don't have the artistic background to mimic his...

Jan. 2, 2013

ui colors again

by corvid＠lavabit.com

Jorge wrote: > For instance, adding these vars to the current set: > > tab_bg_color, tab_fg_color, > tab_text_active_color, tab_text_inactive_color > ui_button_highlight_color > menu_active_item_color, > > would allow for huge themability options. > > I know it looks like an overkill, but yesterday, playing with > the "toy" color chooser, with colors/themes I never use, found > that some of our "good defaults" are poor choices for completely > different color schemes. > > The good part is that with a detailed color vars set, a theme > becomes a small set of integers. Quite easy to handle. Okay, I'll add a bunch of prefs for us to experiment with. > Ideally yes. Now, it needs some care. For instance, the "toy" > chooser changes ui background well, but doesn't update the colors > of inactive buttons with the new backgrounds (which makes a huge > difference with bluish backgrounds. e.g. ui_main_bg_color=0070c0). Yeah, I'll put a little more time into the toy later. Background also needs to update the gray ramp so that box colors work better, for instance...

Jan. 2, 2013

wizard, switching between UIs

by jcid＠dillo.org

On Wed, Jan 02, 2013 at 05:55:42PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Dec 29, 2012 at 09:21:31PM +0000, corvid wrote: > > > > > > Yesterday I was playing with ctrl-tab, of course, and I noticed how the > > > state of the focused tab would sometimes change. > > > > What's "the state of the focused tab"? > > Suppose you have two tabs open and you ctrl-tab between them. > - If, in the rightmost one, Location had focus, when it gets focus again, > suddenly the whole location text is highlighted (Fl_Input.cxx:616). > - If the rightmost one has Main focused, when you switch back to it, > Location has focus (Fl_Group.cxx:130, 159). Ah, now I see! Please add a comment like this to either the source or the hg patch upon commit. -- Cheers Jorge.-

Jan. 2, 2013

wizard, switching between UIs

by corvid＠lavabit.com

Jorge wrote: > On Sat, Dec 29, 2012 at 09:21:31PM +0000, corvid wrote: > > > > Yesterday I was playing with ctrl-tab, of course, and I noticed how the > > state of the focused tab would sometimes change. > > What's "the state of the focused tab"? Suppose you have two tabs open and you ctrl-tab between them. - If, in the rightmost one, Location had focus, when it gets focus again, suddenly the whole location text is highlighted (Fl_Input.cxx:616). - If the rightmost one has Main focused, when you switch back to it, Location has focus (Fl_Group.cxx:130, 159).

Jan. 2, 2013

ui colors again

by jcid＠dillo.org

On Sun, Dec 30, 2012 at 07:20:54PM +0000, corvid wrote: > 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)... Yes, 3 or four packed themes would be OK (ideally selectable from the UI), but tweakable from dillorc vars (this is a common solution). A set of common "color schemes" is not easy to find though. For instance, I use LXDE/openbox, and it comes with near a hundred packed themes! In openbox's theme set, sometimes a darker color is used to the focused window, other themes use the reverse, and there're plenty which use the same color and a a brighter font to hint focus. With this state of things, I tend to favor specific variables in dillorc over trying to guess what could be right. For instance: tab_bg_color tab_fg_color instead of a fl_lighter()/fl_darker() combination. BTW, the current dillo repo guesses my theme backwards, but it does great for other colors, and not good on others. For instance, adding these vars to the current set: tab_bg_color, tab_fg_color, tab_text_active_color, tab_text_inactive_color ui_button_highlight_color menu_active_item_color, would allow for huge themability options. I know it looks like an overkill, but yesterday, playing with the "toy" color chooser, with colors/themes I never use, found that some of our "good defaults" are poor choices for completely different color schemes. The good part is that with a detailed color vars set, a theme becomes a small set of integers. Quite easy to handle. > 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. Ideally yes. Now, it needs some care. For instance, the "toy" chooser changes ui background well, but doesn't update the colors of inactive buttons with the new backgrounds (which makes a huge difference with bluish backgrounds. e.g. ui_main_bg_color=0070c0). Of course it should also be able to manage saving the custom defined theme. I'd first try with a certain colors var set, then define some themes, make them UI-selectable, and finally decide whether a color chooser for all of them is worth (YMMV, the reverse approach may also fit ;). -- Cheers Jorge.-

Jan. 2, 2013

wizard, switching between UIs

by jcid＠dillo.org

On Sat, Dec 29, 2012 at 09:21:31PM +0000, corvid wrote: > > Yesterday I was playing with ctrl-tab, of course, and I noticed how the > state of the focused tab would sometimes change. What's "the state of the focused tab"? > I went through a few rounds > of fixing this in different ways before finding something that didn't seem > icky. Detailed comment in patch. Yeah, from time to time, something like the patch you describe is necessary with FLTK (silent resize of hidden widgets comes to mind...) -- Cheers Jorge.-

Jan. 2, 2013

Render bug

by jcid＠dillo.org

On Mon, Dec 31, 2012 at 07:52:11PM +0000, corvid wrote: > Alexander wrote: > > 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 > > What if we do something like the attached? We might be able to get away > with a smaller fix, but this seemed sensible conceptually. +1 It looks OK to me after reviewing/reading it a few times. Although I haven't made tests on it, I'd say please feel free to commit when it passes yours. -- Cheers Jorge.-

Jan. 2, 2013

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

by jcid＠dillo.org

On Tue, Jan 01, 2013 at 10:30:04PM +0000, Jeremy Henty wrote: > > p37sitdu at lavabit.com wrote: > > > 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. Capi shows a warning in the command line... Anyway, the request (a local file copy) is ignored, but can be implemented easily in the dpi for orthogonality. > [...] > I wonder what is the real benefit of a separate downloads DPI. Is it > actually useful to have one downloads window for all Dillo processes? You'll find the rationale in doc/Dpid.txt -- Cheers Jorge.-

Jan. 2, 2013

hyphenator valgrind error

by sgeerken＠dillo.org

On Mon, Dec 31, Sebastian Geerken wrote: > 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. Fixed. Platform::prevGlyph is not used anymore. Happy new year! Sebastian

Jan. 2, 2013

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

by p37sitdu＠lavabit.com

On Tue, Jan 01, 2013 at 10:30:04PM +0000, Jeremy Henty wrote: > > p37sitdu at lavabit.com wrote: > > > 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. > > > [...] > > > > [...] > > 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. > > I wonder what is the real benefit of a separate downloads DPI. Is it > actually useful to have one downloads window for all Dillo processes? I think downloading should not be done by downloads DPI: this way it have to support all the protocols Dillo and its plugins support. But tracking of downloads can be left there so we don't see the difference between two dillo processes and two dillo windows. > The downloads DPI is rather different from all the rest: it is the > only one that links to FLTK and it doesn't send HTML back to Dillo. > Do we really benefit from putting downloading in a separate process? Cookies DPI doesn't send HTML too. Downloads and cookies are server DPIs, they are used to share resources between processes.

Jan. 2, 2013

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

by corvid＠lavabit.com

Jeremy wrote: > I wonder what is the real benefit of a separate downloads DPI. Is it > actually useful to have one downloads window for all Dillo processes? > The downloads DPI is rather different from all the rest: it is the > only one that links to FLTK and it doesn't send HTML back to Dillo. > Do we really benefit from putting downloading in a separate process? I think I would prefer to save things using dillo directly rather than having dillo get something, figure out that it can't display it, abort the connection, have this other process start over again in another window... (I tend to use wget by hand in order to avoid all of that.)

Jan. 1, 2013

Dpi_connect_socket retry

by jcid＠dillo.org

On Sun, Dec 30, 2012 at 07:11:28PM -0300, Jorge Arellano Cid wrote: > 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... OK, just committed a slightly modified and bigger patch that also corrects the wrong error error message given (CCC side). Please check how it works, and send feedback. -- Cheers Jorge.-

Jan. 1, 2013

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

by onepoint＠starurchin.org

p37sitdu at lavabit.com wrote: > 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. > > [...] > > [...] > 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. I wonder what is the real benefit of a separate downloads DPI. Is it actually useful to have one downloads window for all Dillo processes? The downloads DPI is rather different from all the rest: it is the only one that links to FLTK and it doesn't send HTML back to Dillo. Do we really benefit from putting downloading in a separate process? Regards, Jeremy Henty

Jan. 1, 2013

Render bug

by Hole.destructor＠gmx.de

On Mon, Dec 31, 2012 at 07:52:11PM +0000, corvid wrote: > What if we do something like the attached? We might be able to get away > with a smaller fix, but this seemed sensible conceptually. Thanks, your patch fixes this issue (and I don't see any side effects). Best, Alex

Dec. 31, 2012

Render bug

by corvid＠lavabit.com

Alexander wrote: > 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 What if we do something like the attached? We might be able to get away with a smaller fix, but this seemed sensible conceptually.

Dec. 31, 2012