- Dillo-dev - lists.mailman3.com

fltk1.3 port
by jcid＠dillo.org March 18, 2011

March 18, 2011

Hi, Just committed some keybindings and operative findbar patches. It feels quite operative now. Minor things remain. BTW, there's a pending bug report to FLTK (see comments in code). -- Cheers Jorge.-

3 7

dillo_port1.3: error: ‘class Fl_Tree’ has no member named ‘item_labelfont’
by rogerx.oss＠gmail.com March 17, 2011

March 17, 2011

++ -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/local/include -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT libDw_fltk_a-fltkpreview.o -MD -MP -MF .deps/libDw_fltk_a-fltkpreview.Tpo -c -o libDw_fltk_a-fltkpreview.o `test -f 'fltkpreview.cc' || echo './'`fltkpreview.cc mv -f .deps/libDw_fltk_a-fltkpreview.Tpo .deps/libDw_fltk_a-fltkpreview.Po g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/local/include -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT libDw_fltk_a-fltkui.o -MD -MP -MF .deps/libDw_fltk_a-fltkui.Tpo -c -o libDw_fltk_a-fltkui.o `test -f 'fltkui.cc' || echo './'`fltkui.cc fltkui.cc: In member function ?virtual void dw::fltk::ui::FltkListResource::setWidgetStyle(Fl_Widget*, dw::core::style::Style*)?: fltkui.cc:1075: error: ?class Fl_Tree? has no member named ?item_labelfont? fltkui.cc:1076: error: ?class Fl_Tree? has no member named ?item_labelsize? fltkui.cc:1077: error: ?class Fl_Tree? has no member named ?item_labelfgcolor? fltkui.cc:1078: error: ?class Fl_Tree? has no member named ?item_labelbgcolor? make[2]: *** [libDw_fltk_a-fltkui.o] Error 1 make[2]: Leaving directory `/home/roger/src/dillo/dillo_port1.3/dw' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/roger/src/dillo/dillo_port1.3' make: *** [all] Error 2 -- Roger http://rogerx.freeshell.org/

2 2

big mistake with hg
by jcid＠dillo.org March 11, 2011

March 11, 2011

Hi there, I just pushed 120 changesets to hg "dillo" instead of "dillo_port1.3" by mistake (wrong default). Is there a simple way to clean the mess by purging the changes? -- Cheers Jorge.-

4 7

Resizing a window changes the reading location
by dennisn＠dennisn.dyndns.org March 3, 2011

March 3, 2011

When windows (with wrapping lines) are resized, the page position changes, and users have to manually find where they left off. It looks like a rounding error, since the % in the page is roughly the same -- but not exactly.

2 1

Bug: dillo fails to follow the redirects and reach the webpage
by higuita7＠yahoo.co.uk March 1, 2011

March 1, 2011

Hi i setup my RSS feeder to use dillo, but i found that dillo cant open the request pages for many feeds... example: http://feedproxy.google.com/~r/Phoronix/~3/TPVKpXMovJ8/vr.php Looks like dillo sees the first redirect, but dont really follow it to see the next redirect... yet i see it follow other redirects just fine... If i pick the redirect url and give it to dillo, it opens the page just fine. So i would say that dillo fails to follow 2 or more redirects. Thanks for dillo and for the help higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

4 4

dillo_port1.3: ‘class Fl_Tree’ has no member named ‘item_labelfont’
by rogerx.oss＠gmail.com Feb. 13, 2011

Feb. 13, 2011

After doing hg pull && hg update, and then make clean && ./configure && make: mv -f .deps/libDw_fltk_a-fltkpreview.Tpo .deps/libDw_fltk_a-fltkpreview.Po g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT libDw_fltk_a-fltkui.o -MD -MP -MF .deps/libDw_fltk_a-fltkui.Tpo -c -o libDw_fltk_a-fltkui.o `test -f 'fltkui.cc' || echo './'`fltkui.cc fltkui.cc: In member function ?virtual void dw::fltk::ui::FltkListResource::setWidgetStyle(Fl_Widget*, dw::core::style::Style*)?: fltkui.cc:1075: error: ?class Fl_Tree? has no member named ?item_labelfont? fltkui.cc:1076: error: ?class Fl_Tree? has no member named ?item_labelsize? fltkui.cc:1077: error: ?class Fl_Tree? has no member named ?item_labelfgcolor? fltkui.cc:1078: error: ?class Fl_Tree? has no member named ?item_labelbgcolor? make[2]: *** [libDw_fltk_a-fltkui.o] Error 1 make[2]: Leaving directory `/home/roger/src/dillo/dillo_port1.3/dw' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/roger/src/dillo/dillo_port1.3' make: *** [all] Error 2

2 2

for 1.3 port, latest fltk snapshot is required
by corvid＠lavabit.com Feb. 12, 2011

Feb. 12, 2011

..because we're using some new stuff that they added for us http://fltk.org/newsgroups.php?s23204+gfltk.general+v23210+T0

2 1

Valgrind errors from downloads.cc
by corvid＠lavabit.com Feb. 10, 2011

Feb. 10, 2011

Jeremy wrote: > Valgrind is reporting uninitialised data in DLItem::update() in > downloads.cc[1]. Here's the code with the offending lines (705, 706) > marked. > > /* Rate */ > if (csec >= 2) { > tsec = (float) (curr_time - twosec_time); > ! rate = ((float)(curr_bytesize-twosec_bytesize) / 1024) / tsec; > ! snprintf(str, 64, (rate < 100) ? "%.1fK/s" : "%.0fK/s", rate); > prRate->copy_label(str); > prRate->redraw_label(); > } > > I'm wondering what is happening here. DLItem::update() is scheduled > to be run every second. I think that twosec_time is only set to an > initialised value when the function has been run at least twice > before. Also, csec is calculated from the difference between the > current time and the initial time. Is it possible that the "csec >= > 2" could be true even when the function has been run only once before? > After all, the timing of callbacks is never exact. Perhaps the > callback should explicitly count how many times it has been called > rather than attempt to work it out from the timing? (The list software never did send me a copy of your msg...) Would something like the following work? --- a/dpi/downloads.cc Tue Jan 11 01:18:28 2011 +0000 +++ b/dpi/downloads.cc Sun Feb 06 20:40:53 2011 +0000 @@ -318,6 +318,8 @@ // Init value. Reset later, upon the first data bytes arrival init_time = time(NULL); + twosec_time = onesec_time = init_time; + // BUG:? test a URL with ' inside. /* escape "'" character for the shell. Is it necessary? */ esc_url = Escape_uri_str(url, "'"); > [1] > http://starurchin.org/dillo/valgrind.html > http://starurchin.org/dillo/valgrind/6444c6ff40e01e517ce6e802f23670c5422c6e… > http://starurchin.org/dillo/valgrind/68bd8732669bbac8e11f1ea5a692db022fc6a6… > http://starurchin.org/dillo/valgrind/6f1d6a4feadf8136cbed37497a1d6dbbfea4a3… > http://starurchin.org/dillo/valgrind/68026e750cc92b08699c26392ecfd92cf370a9… >

3 5

Valgrind errors from downloads.cc
by onepoint＠starurchin.org Feb. 7, 2011

Feb. 7, 2011

Valgrind is reporting uninitialised data in DLItem::update() in downloads.cc[1]. Here's the code with the offending lines (705, 706) marked. /* Rate */ if (csec >= 2) { tsec = (float) (curr_time - twosec_time); ! rate = ((float)(curr_bytesize-twosec_bytesize) / 1024) / tsec; ! snprintf(str, 64, (rate < 100) ? "%.1fK/s" : "%.0fK/s", rate); prRate->copy_label(str); prRate->redraw_label(); } I'm wondering what is happening here. DLItem::update() is scheduled to be run every second. I think that twosec_time is only set to an initialised value when the function has been run at least twice before. Also, csec is calculated from the difference between the current time and the initial time. Is it possible that the "csec >= 2" could be true even when the function has been run only once before? After all, the timing of callbacks is never exact. Perhaps the callback should explicitly count how many times it has been called rather than attempt to work it out from the timing? Regards, Jeremy Henty [1] http://starurchin.org/dillo/valgrind.html http://starurchin.org/dillo/valgrind/6444c6ff40e01e517ce6e802f23670c5422c6e… http://starurchin.org/dillo/valgrind/68bd8732669bbac8e11f1ea5a692db022fc6a6… http://starurchin.org/dillo/valgrind/6f1d6a4feadf8136cbed37497a1d6dbbfea4a3… http://starurchin.org/dillo/valgrind/68026e750cc92b08699c26392ecfd92cf370a9…

1 0

dillo fltk-1.3 scroll bar delay
by rogerx.oss＠gmail.com Feb. 4, 2011

Feb. 4, 2011

I messed around with ltrace to debug the scrollbar delay within dillo fltk-1.3 port. Here's what I get so far. roger@localhost1 ~ $ ltrace -c -p 11442 % time seconds usecs/call calls function ------ ----------- ----------- --------- -------------------- 18.32 0.291790 6785 43 _ZN8Fl_Group4drawEv 11.69 0.186144 1861 100 _ZN7Fl_Tabs6handleEi 9.70 0.154394 8126 19 _ZN9Fl_Window5flushEv 9.41 0.149853 7887 19 _ZN9Fl_Window4drawEv 9.05 0.144073 7582 19 _ZN7Fl_Tabs4drawEv 8.98 0.142919 793 180 _ZN8Fl_Group6handleEi 6.62 0.105367 115 911 _Znwj 5.82 0.092602 101 911 _ZdlPv 4.82 0.076755 102 746 _ZN2Fl12event_insideEPK9Fl_Widget 2.34 0.037301 153 243 strlen 2.11 0.033615 107 314 malloc 2.06 0.032840 104 314 free 1.81 0.028844 1696 17 _Z9fl_scrolliiiiiiPFvPviiiiES_ 1.49 0.023788 141 168 _ZdaPv 1.11 0.017654 105 168 _Znaj 1.04 0.016517 105 157 __vsnprintf_chk 1.01 0.016079 102 157 _ZN9Fl_Input_5valueEPKc 0.89 0.014229 459 31 _ZN8Fl_Input6handleEi 0.39 0.006271 169 37 _ZNK8Fl_Group10draw_childER9Fl_Widget 0.34 0.005480 103 53 _ZNK8Fl_Group5arrayEv 0.31 0.004997 138 36 _ZNK8Fl_Group12update_childER9Fl_Widget 0.23 0.003682 108 34 _ZN9Fl_Slider11scrollvalueEiiii 0.16 0.002508 192 13 _ZN9Fl_Button4drawEv 0.12 0.001868 116 16 _ZN9Fl_Button6handleEi 0.11 0.001818 106 17 _ZN9Fl_Widget6damageEh 0.02 0.000380 190 2 _ZN6Fl_Box4drawEv 0.02 0.000361 180 2 _ZN8Fl_Input4drawEv 0.01 0.000227 113 2 _ZN9Fl_Window6resizeEiiii ------ ----------- ----------- --------- -------------------- 100.00 1.592356 4729 total roger@localhost1 ~ $ ltrace -c -p 11442 % time seconds usecs/call calls function ------ ----------- ----------- --------- -------------------- 29.26 29.729943 120364 247 _ZN8Fl_Group4drawEv 14.75 14.984334 149843 100 _ZN9Fl_Window5flushEv 14.72 14.952232 149522 100 _ZN9Fl_Window4drawEv 14.69 14.922999 149229 100 _ZN7Fl_Tabs4drawEv 13.48 13.693784 228229 60 _Z9fl_scrolliiiiiiPFvPviiiiES_ 4.09 4.157141 329 12601 strlen 2.28 2.320390 860 2695 _Znwj 2.28 2.317818 860 2695 _ZdlPv 2.15 2.186969 1436 1522 free 0.41 0.421299 141 2982 _ZNK8Fl_Group5arrayEv 0.23 0.238538 126 1884 _ZN2Fl12event_insideEPK9Fl_Widget 0.22 0.220701 147 1500 _ZNK8Fl_Group12update_childER9Fl_Widget 0.19 0.188841 2121 89 _ZN7Fl_Tabs6handleEi 0.18 0.179153 248 720 _ZN8Fl_Group6resizeEiiii 0.18 0.179127 117 1522 malloc 0.16 0.159278 556 286 _ZNK8Fl_Group10draw_childER9Fl_Widget 0.13 0.128988 503 256 _ZN8Fl_Group6handleEi 0.09 0.094990 124 761 __vsnprintf_chk 0.09 0.089326 117 761 _ZN9Fl_Input_5valueEPKc 0.08 0.082873 2762 30 _Z9fl_cursor9Fl_Cursorjj 0.08 0.078284 130 600 _ZN9Fl_Input_6resizeEiiii 0.05 0.048376 115 420 _ZN9Fl_Widget6resizeEiiii 0.04 0.042491 118 360 _Z8fl_widthPKci 0.04 0.036692 136 269 _Znaj 0.03 0.030249 112 269 _ZdaPv 0.02 0.024592 105 233 fl_utf8fwd 0.01 0.013969 194 72 _ZN8Fl_Input4drawEv 0.01 0.013501 112 120 _ZN9Fl_Slider11scrollvalueEiiii 0.01 0.012305 146 84 _ZN8Fl_Input6handleEi 0.01 0.012155 289 42 _ZNK9Fl_Widget10draw_labelEv 0.01 0.007515 121 62 fl_utf8back 0.01 0.007343 174 42 _ZNK9Fl_Widget13draw_backdropEv 0.01 0.006733 112 60 _ZN9Fl_Widget6damageEh 0.00 0.004839 115 42 _ZNK9Fl_Widget8draw_boxE10Fl_Boxtypej 0.00 0.002366 182 13 _ZN9Fl_Button4drawEv 0.00 0.001462 104 14 _ZN6Fl_Box6handleEi 0.00 0.001444 103 14 _ZN9Fl_Button6handleEi 0.00 0.000528 264 2 _ZN6Fl_Box4drawEv 0.00 0.000226 113 2 _ZN9Fl_Window6resizeEiiii ------ ----------- ----------- --------- -------------------- 100.00 101.593794 33631 total

3 5