- Dillo-dev - lists.mailman3.com

[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