- Dillo-dev - lists.mailman3.com

Question about local file browsing
by obeythepenguin＠gmail.com April 9, 2011

April 9, 2011

I'm sure this has been asked before, but why on earth is something so basic as local file browsing implemented through the (ludicrously complicated, IMHO) DPI system rather than built in to the program? ~Benjamin

4 5

[bug]: '<META HTTP-EQUIV="Expires" CONTENT="-1">' => endless calls to Nav_open_url()
by onepoint＠starurchin.org March 31, 2011

March 31, 2011

I got the attached bit of HTML from a broken RSS feed and it causes Dillo to thrash, endlessly calling Nav_open_url(). It is the 'HTTP-EQUIV="Expires"' header that is responsible. Any ideas how to fix this? I am afraid this bit of the code makes my head spin so some guidance would be a big help. Regards, Jeremy Henty

2 4

Re: Dillo-dev Digest, Vol 67, Issue 20
by mrgnash＠sdf.lonestar.org March 28, 2011

March 28, 2011

I hope that I am not sending this to the wrong place or anything, but I just wanted to express my sincere gratitude to all the people working on this, the great browser around :)

2 1

[bug]: CSS image crash
by onepoint＠starurchin.org March 27, 2011

March 27, 2011

If you point dillo at http://www.youtube.com/user/zynaddsubfx and scroll down then Dillo will crash before you get to the bottom. I have attached a minimal test case that reproduces this (strangely, the empty SRC attribute on the img element is necessary). GDB shows that the drawing code is dereferencing a NULL FltkColor*: #0 0x080a4811 in dw::fltk::FltkViewBase::drawPolygon (this=0x49f4318, color=0x0, shading=dw::core::style::Color::SHADING_NORMAL, filled=true, points=0xbeae1a48, npoints=4) at /home/jeremy/.packages/dillo/HG/local/dw/fltkviewbase.cc:464 464 setcolor(((FltkColor*)color)->colors[shading]); Regards, Jeremy Henty

4 19

Test case for a possible fltk1.3 bug
by jcid＠dillo.org March 23, 2011

March 23, 2011

Hi there, Please help me with this one. Attached goes a small program that shows what may be a bug in fltk-1.3: * resize the window back and forth and both "Group 1" and "Group 2" keep their heights. OK here. * With a small window, hide "Group 2" and resize to a big window, then show "Group 2". It grew while hidden!? My doubts are: Is this intended or a bug? If not a bug, how is the desired behaviour suppossed to be implemented? I know an ugly way to workaround it (used with the findbar), but, if it's a bug, I'd prefer to have it fixed, and to keep the code clean. What do you think? PS: compile with: fltk-config --compile rsz.cc -- Cheers Jorge.-

3 8

Main Dillo HG repository
by onepoint＠starurchin.org March 22, 2011

March 22, 2011

Has this been fixed? I have not been pulling from it because I didn't want the FLTK-1.3 code to land on me. Regards, Jeremy Henty

3 4

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

Yong Li added you as a business connection on Plaxo
by plaxo＠mx.plaxo.com Feb. 2, 2011

Feb. 2, 2011

Yong Li wants to add you as a business connection on Plaxo. To accept this connection request, go to: http://www.plaxo.com/invite?lang=en&i=120351393&k=1829487072&l=en&src=email… Thanks, The Plaxo team Plaxo - your address book for life. Don't want to receive emails from Plaxo any more? Go to: http://www.plaxo.com/stop?src=email&et=1&est=business&etv=jun10d&el=en&emai… Plaxo, Inc. - 203 Ravendale Drive - Mountain View - CA - 94043 - USA

2 1

Final release of FLTK 2.0 Dillo
by Hole.destructor＠gmx.de Jan. 30, 2011

Jan. 30, 2011

Dear Dillo developers, since you started porting Dillo to FLTK 1.3, I wonder if you plan to do a last release of the current FLTK 2.0 Dillo? (This would seem reasonable to me, since this version works pretty well and some of us can't wait so long for the next release. :) Many thanks in advance, Alexander Voigt

7 10

[patch]: clean up the build and make d_size.h static.
by onepoint＠starurchin.org Jan. 28, 2011

Jan. 28, 2011

These patches clean up the build system some more and then address the issue raised here[1], by using autoconf to define int32_t etc. and turning d_size.h into a static source file instead of building it. A nice simplification! Note that it depends on adding -I.$(top_srcdir) to AM_CPPFLAGS so that d_size.h can be #include-ed anywhere. 1: Finish the work begun in changeset 90603f572f75 by replacing paths that use ../ with full paths from $(top_builddir). 2: Add -I$(top_srcdir) to AM_CPPFLAGS everywhere. (This is necessary to allow the next change.) 3: Determine int32_i and friends with autoconf macros and make d_size.h a static file. Now "make distcheck" works at last! (It used to fail because d_size.h was left behind after a clean.) Comments are welcome. Regards, Jeremy Henty [1] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005135.html

3 9

1.3 port status
by obeythepenguin＠gmail.com Jan. 27, 2011

Jan. 27, 2011

Oops, I meant to send this to the list, not just Alexander -- apologies for that. On Wed, Jan 26, 2011 at 9:12 AM, Alexander Voigt <Hole.destructor(a)gmx.de> wrote: > Maybe this is a solution to the upcomming problem(s). ?What one needs > to do is to build an abstraction and an implementor and pack all > toolkit specific things into concrete implementors (i.e. the FLTK 2.0, > or FLTK 1.3 specific things). There's one obvious problem there: the toolkit is *already* an abstraction. ?(FLTK's not strictly an abstraction layer, because it implements its own widget set, but the purpose of any toolkit is to provide some sort of abstraction over the native APIs.) On top of that, this "solution" doesn't really solve anything -- it still takes time away from development, requires developers to learn the new abstraction layer, and won't make up for functional incompatibilities/missing features between different toolkits or versions. ?It sounds like a great idea in theory -- and IIRC, the Dillo renderer (but not the rest of the interface) is already built on an abstraction layer -- but in practice it would mostly amount to needlessly re-inventing the wheel. Disclaimer: I'm not one of the core developers, and this is only my personal view. ~Benjamin

2 1

1.3 port status
by rogerx.oss＠gmail.com Jan. 26, 2011

Jan. 26, 2011

> On Mon, Jan 24, 2011 at 06:11:31PM +0000, corvid wrote: >Roger wrote: >> 'hg update' && patch from this thread. > >Your backtrace doesn't match up for dw/layout.cc, for instance. >Is there an 'hg pull' in there as well? >(Also, if it wasn't clear, a new version of the UI patch went up >yesterday.) > >> Going from memory, I believe they were window functions calling the old 2.0 >> branch names instead of 1.3. >> >> I believe I already sent you the details, but since they were only test >> programs and didn't hinder dillo from being built, they aren't a high priority. > >I fixed up the Browser test to compile a couple of days ago. Yup. I performed the 'hg tip' and compared with your times and mine still showed older. This is exactly what I was afraid of. svn/cvs update seems so much friendlier! So, I just wiped and re-cloned. Within the following compiler error stdout's, please ignore the "-I/usr/include/fltk-1.1" as the package maintainer for fltk-1.3 ebuilds on bugs.gentoo.org is working to get the library slotted correctly. I only have fltk-1.3 and fltk-2.0 libraries installed here. Here's that pthread issue again: g++ -I/usr/include/libpng14 -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 -L/usr/local/lib -o dillo dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib -lpng14 -L/usr/lib/fltk-1.1 -Wl,-rpath,/usr/lib/fltk-1.1 -lfltk -lXext -lXft -lfontconfig -ldl -lm -lX11 -lz dns.o: In function `Dns_server_req': /home/roger/src/dillo/dillo_port1.3/src/dns.c:360: undefined reference to `pthread_create' Too resolve, ./configure --disable-threaded-dns (or am I missing a dep?... I don't think so.) Here's the Flock() function call to the old fltk-2.0 lock function: g++ -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 -L/usr/local/lib -o downloads.dpi downloads_dpi-downloads.o dpiutil.o -L/usr/lib/fltk-1.1 -Wl,-rpath,/usr/lib/fltk-1.1 -lfltk -lXext -lXft -lfontconfig -ldl -lm -lX11 ../dpip/libDpip.a ../dlib/libDlib.a downloads_dpi-downloads.o: In function `main': /home/roger/src/dillo/dillo_port1.3/dpi/downloads.cc:1105: undefined reference to `Fl::lock()' Test programs compiled without errors. On execute, I see the "Back, Forward, Home, ..." buttons with a slice of the bottom of the "File, View, ..." stuff. Everything else seems frozen. If I'm not mistaken, I can see the toolbar window extend a third of the way down the screen. Then the next 2/3's I see the light grey browser window with slider. Then 3/3 I can see the top slice of "File, View, ..." toolbar window. Oh. I found the hidden "File" button from "File, View, ..." toolbar. But I can't open a url. But did get a new blank tab open. No pages loaded yet. ctrl-s gets me search the web, and ctrl-r seems to be reloading an invisible page (likely google.com as I see it loads two images from the text info). ctrl-l (open file) and ctrl-n (new window) works. ctrl-l fails to open an applet (open url). Looks like pages are loading by looking at the console and the text info detailing "images loaded", but everything is invisible ... windows borking? Looks like rendering pages is being done invisible because the applets/windows are failing.

4 11

1.3 port status
by corvid＠lavabit.com Jan. 25, 2011

Jan. 25, 2011

Roger wrote: > Capi_filters_test: DENY from 'news.google.com' to 'nt3.ggpht.com' If you want all of those, in dillorc, change filter_auto_requests to allow_all.

1 0

1.3 port status
by corvid＠lavabit.com Jan. 24, 2011

Jan. 24, 2011

The fltk-1.3 port is decently usable now if you take http://hg.dillo.org/dillo_port1.3/ and apply my quick hacky UI patch http://www.dillo.org/test/1.3_ui_hardcoded.patch (Anyone want to write a proper one? :) I see that it's segfaulting when leaving pages with image inputs because of something to do with complexbutton, but...decently usable, certainly.

4 9

Not to name dillo 1.3 & not to drop fltk 2.0 support
by hulladiho＠googlemail.com Jan. 18, 2011

Jan. 18, 2011

While this mail is meant as a follow-up to http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-January/007943.html, I'd first like to tell you that I'm neither a Dillo nor an FLTK developer, but reading the mails from the archive in this discussion thread got me the impression that Dillo uses FLTK 2.0 internally and that it is intended to switch to 1.3. I wonder if this would actually make sense with respect to an anticipated FLTK 3.0, which, following links from the FLTK project website (http://www.fltk.org/) to the FLTK 3 proposal (http://www.fltk.org/articles.php?L1031) and from there to the more detailed explanations' (http://www.fltk.org/links.php?LC+P402+Q) section 2 (http://www.fltk.org/links.php?V404+Q) is described as build on the FLTK 2 API with FLTK 1.3 interna for stability in the last paragraph of the aforementioned text section. I'd like to restate that I have no idea in which ways Dillo and FLTK are actually connected, but it looks to me like it would be a good idea for Dillo developers to check what's planned with FLTK 3 and perhaps get in contact with FLTK developers on this before switching Dillo code based on FLTK 2 to FLTK 1.3, if the only reason for that is to base Dillo code on an API that will see support in the future. Just my two cents, I hope this mail is appropriately placed here, otherwise apologies, for this is my first mail to any mailing list ever and I'm still quite uncertain about how referring to messages in the archived thread actually works. P.S.: The preceding sentence is not entirely true, as I have already tried yesterday to send the above text to the mailing list. As it didn't appear in the archive until now, I've subscribed to the list as a debugging measure and try it again, in case prior subscription to the list is required to send messages to it. In that case, I'd also like to suggest that such a requirement be communicated at the information page (http://www.dillo.org/MListinfo.html)

4 4

Q: offical bug report address?
by onepoint＠starurchin.org Jan. 17, 2011

Jan. 17, 2011

AC_INIT takes an optional URL for bug reports. Should we use it, and what URL would be appropriate? Regards, Jeremy Henty

2 3

[patch]: more spring cleaning of configure.in
by onepoint＠starurchin.org Jan. 12, 2011

Jan. 12, 2011

Time to retire some more obsolete autoconf macros. See [1] for details. 1: Replace AC_CANONICAL_SYSTEM with AC_CANONICAL_TARGET . 2: Replace AC_ERROR with AC_MSG_ERROR . 3: Replace AC_TRY_COMPILE with AC_COMPILE_IFELSE / AC_LANG_PROGRAM . This doesn't break for me, but it affects some host-dependent parts of configure.in . It would be good to know that this works on hosts with unusual socket / iconv library routines. 4: Replace AC_TRY_LINK_FUNC with AC_LINK_IFELSE / AC_LANG_CALL . This only affects target OSes *other* than linux, solaris, osf1 and minix. Can anyone test on such a thing? 5: Indentation tweak for consistency. Regards, Jeremy Henty [1] http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html#…

4 6

.hgignore
by corvid＠lavabit.com Jan. 10, 2011

Jan. 10, 2011

These should be in .hgignore, shouldn't they? $ hg status ? dpi/vsource.filter.dpi ? dpid/dpidc ? dpid/dpidrc

3 6

regular expressions
by gsavix＠gmail.com Jan. 9, 2011

Jan. 9, 2011

very good mails articles about regular expressions. congratulations! i learn lots in these mails. thanks for all! debian lenny 5.0.6 (i386) -- gilberto dos santos alves (11) 8646-5049 s?o paulo - SP - Brasil

1 0

hg repo
by jcid＠dillo.org Jan. 8, 2011

Jan. 8, 2011

Hi Andreas K., Just a couple of questions: * Does Sebastian Geerken have commit permission in our hg repo? (if not, please enable him). * Can corvid make another repo in the same server? (e.g. for the port to fltk-1.3) TIA -- Cheers Jorge.-

4 10

Not to name dillo 1.3 & not to drop fltk 2.0 support
by darkspirit5000＠gmail.com Jan. 7, 2011

Jan. 7, 2011

Hello and happy new year. I want to suggest something for fltk 1.3 port. First. I think that to name dillo 1.3 vs dillo 2.0 is confusing. Dillo was 2.0 for a lot of changes (css, etc) one of them fltk port. Second. I want to suggest to not to remove the fltk 2.0 support code from dillo. DilloWidget support more than one "backend" so fltk 1.3 can be added whitout remove fltk 2.0 and selected at compile time or even runtime. Using 1.3 and compile time as sane defaults, of course. A test version that draw 2 windows aech one with a "backend" can ve used to compare visual results during the port to 1.3. To support 2 "backend" now can heltp to support others in the future. ?what about a directfb one? Debian instaler will thanks it even i them use X now. Sorry for my bad english Diego.

6 8

Copy and paste from page content area
by obeythepenguin＠gmail.com Jan. 7, 2011

Jan. 7, 2011

Was this ever implemented in the X11 version? I don't have access to a Unix box right now, otherwise I'd just test it myself. :-) ~Benjamin

3 4

configure.in
by corvid＠lavabit.com Jan. 6, 2011

Jan. 6, 2011

In configure.in, why is it LIBFLTK_LIBS=`fltk2-config --use-images --ldflags` if we use the system png/jpeg/etc. libraries and not the fltk ones? I just tried removing the --use-images argument, and everything still works for me.

2 2

[patch]: more configure.in cleanups
by onepoint＠starurchin.org Jan. 5, 2011

Jan. 5, 2011

Some more cleaning up of configure.in: Move AC_CANONICAL_SYSTEM We should call AC_CANONICAL_SYSTEM immediately after AC_INIT otherwise autoconf throws a warning "AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET". (This was introduced by my previous configure.in patch, oops!) Remove AM_PROG_CC_STDC AM_PROG_CC_STDC has been folded into AC_PROG_CC . Amusing facts: * This removes 670 lines (~ 9%) from configure! * AM_PROG_CC_STDC is so obsolete it's not even mentioned in the current docs! I Googled an old version[1] to confirm that it's been obsolete since automake 1.8 (released 2003-12-10). After removing this macro, AM_INIT_AUTOMAKE is the only AM_* macro that Dillo uses. Remove AC_HEADER_STDC This isn't actually marked as obsolete but the manual[2] states: This macro is obsolescent, as current systems have conforming header files. New programs need not use this macro. The Dillo source does not use the variable STDC_HEADERS that AC_HEADER_STDC defines. Please comment. Regards, Jeremy Henty [1] http://www.delorie.com/gnu/docs/automake/automake_24.html [2] http://www.gnu.org/software/autoconf/manual/html_node/Particular-Headers.ht…

3 7

Happy new year!
by jcid＠dillo.org Jan. 3, 2011

Jan. 3, 2011

Hi there, Please receive my best wishes and thanks to the team. Let's hope this year will help our project thrive again, in both the distros and the collaboration agreement we're trying to make. (-: 2011 :-) -- Cheers Jorge.-

3 2

[patch]: modernize configure.in's initialization and configuration
by onepoint＠starurchin.org Jan. 2, 2011

Jan. 2, 2011

Dillo's configure.in uses some obsolete autoconf/automake macros and calls some others in obsolete ways. This patch brings it (mostly) up to date. Any problems with this or shall I push it? Regards, Jeremy Henty References: AC_INIT autoconf manual: section 4.1: Initializing configure http://www.gnu.org/software/autoconf/manual/html_node/Initializing-configur… AC_INIT (obsolete form) autoconf manual: section 18.4: Obsolete Macros http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html AM_INIT_AUTOMAKE automake manual: section 6.4.1: Public Macros http://www.gnu.org/software/autoconf/manual/automake/Public-Macros.html AM_CONFIG_HEADER (obsolete) automake manual: section 6.4.2: Obsolete Macros http://www.gnu.org/software/autoconf/manual/automake/Obsolete-Macros.html

4 9

[jcid@dillo.org: Re: [Dillo-dev] [patch]: modernize configure.in's initialization and configuration]
by jcid＠dillo.org Dec. 30, 2010

Dec. 30, 2010

Just noticed I didn't replied this to the list (by mistake). -- Cheers Jorge.-

1 0

A question about the nature of this list
by mr_semantics＠hotmail.com Dec. 28, 2010

Dec. 28, 2010

Gentlemen,? Is it permissible to ask questions about odd dillo behavior on this list? ?I have a weird issue that I have not encountered before, and it is best "described" with a picture, but before I post anything, I want to ensure that it is ok to do so.? Regards, Rob Somers

3 5

FLTK 1.3.0 RC 1 released!
by jcid＠dillo.org Dec. 28, 2010

Dec. 28, 2010

Hi there, Good news, it looks as though FLTK-1.3.0 is close to an official release. This is an important fact because once dillo is ported to it, distros repos could carry dillo again. http://fltk.org/articles.php?L1028 -- Cheers Jorge.-

4 8

Re: FLTK 1.3.0 RC 1 released!
by rogerx.oss＠gmail.com Dec. 28, 2010

Dec. 28, 2010

Dunno about the *other* distros, but Gentoo has several versions of FLTK available including 2.0_pre branch. And, somebody has volunteered a FLTK-1.3_rc1 ebuild on bugs.gentoo.org. Dillo is extremely important on all my platforms as I use Intel P3 CPU's. Using any other browser, and I'm just wasting my CPU cycles with unneeded html scripts -- even with noscript & no-ads plugins for Seamonkey! Maybe hook-up with the FLTK mailing list to see if they're really going to push 1.3? From what I read a week ago, they're devoting all efforts on 1.3 and deprecated 2.0 branch. 2.0 branch might get it's features ported to 1.3. Cheers! -- Roger http://rogerx.freeshell.org/

2 1

Merry Christmas! I've got presents :-)
by obeythepenguin＠gmail.com Dec. 27, 2010

Dec. 27, 2010

Specifically, the latest round of patches: http://dillo-win32.sourceforge.net/dillo/patches.php The biggest changes are the preferences dialog and the libcurl-based downloader, which removes Dillo's dependency on wget and allows it to function as a completely self-contained executable. (By default it's disabled, and Dillo continues to use the old downloads DPI.) There are also various smaller fixes, including a slightly-reworked DNS patch. With static linking and UPX compression, I've got the Windows binary down to a single 1.2MB executable: http://dillo-win32.sourceforge.net/files/dillo.exe Just thought I'd share in case anyone was interested. ~Benjamin

4 10

Re: complex buttons and limit text width
by Johannes.Hofmann＠gmx.de Dec. 20, 2010

Dec. 20, 2010

On Tue, Nov 30, 2010 at 09:15:26PM +0100, Johannes Hofmann wrote: > On Tue, Nov 30, 2010 at 07:07:40PM +0000, corvid wrote: > > Do you remember whether that was a Hard Problem, or just > > one that we didn't get around to looking into? > > I don't remember, but a 100% CPU hog sounds fixable. Haha, famous last words. I still didn't find cause. It's a redraw loop somehow. Cheers, Johannes

1 0

[patch]: CSS parser cleanup and media-conditional @import.
by onepoint＠starurchin.org Dec. 18, 2010

Dec. 18, 2010

Reposting my CSS parser cleanup patches and adding the implementation of CSS2 media-conditional @import rules. Please comment. Regards, Jeremy Henty

2 3

patch: border-color: transparent
by corvid＠lavabit.com Dec. 14, 2010

Dec. 14, 2010

With user agent set to firefox, google likes to give me a border-color: transparent, and I was tired of the no-values msg.

3 3

[patch]: CSS parser cleanup
by onepoint＠starurchin.org Dec. 14, 2010

Dec. 14, 2010

Just some small cleanup and refactoring of the CSS parser code. Any reason not to push these? Regards, Jeremy Henty

2 2

[henry@compdata.org: Dillo 2.2 NetBSD macppc StrawBerry iMac 333]
by jcid＠dillo.org Dec. 13, 2010

Dec. 13, 2010

FYI, -- Cheers Jorge.-

2 3

Yong Li wants to stay in touch on LinkedIn
by sdliyong＠gmail.com Dec. 13, 2010

Dec. 13, 2010

LinkedIn ------------ I'd like to add you to my professional network on LinkedIn. - Yong Li Yong Li platform software developer at Hewlett-Packard China Confirm that you know Yong Li https://www.linkedin.com/e/m1sm8i-ghnbkyy3-6p/isd/2018522004/2K69vPKA/ -- (c) 2010, LinkedIn Corporation

1 0

[patch]: dpip.c: remove unused static
by onepoint＠starurchin.org Dec. 7, 2010

Dec. 7, 2010

Does anyone know what the static variable DpipTag in dpip.c was used for? It's not used any more. Shall I push this? Regards, Jeremy Henty

3 3

[patch]: fix the obsolete usage of AC_OUTPUT
by onepoint＠starurchin.org Dec. 3, 2010

Dec. 3, 2010

While implementing the Lua DPI I saw that configure.in uses AC_OUTPUT in an obsolete way. This patch changes it to use the modern calling convention. (It also puts each of the generated files on a separate line, which makes it much easier to read patches that modify that list.) Regards, Jeremy Henty

3 4

Dillo needs scripting
by onepoint＠starurchin.org Nov. 30, 2010

Nov. 30, 2010

I thought it would be fun if I could write a DPI filter as easily as this: #!/usr/lib/dillo/bin/lua-dpi -- -*- lua -*- dpi [[ Content-type: text/html <!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN'> <html> <head><title>Hello World - Lua DPI</title></head> <body> From inside a Dillo DPI, Lua says "Hello World!". </body> </html> ]] Well, now I can! http://starurchin.org/dillo/dillo_lua_dpi.png It's still just a toy at the moment, but I'm pleased with it. Regards, Jeremy Henty

3 4

[patch]: fix .hgignore
by onepoint＠starurchin.org Nov. 29, 2010

Nov. 29, 2010

I was freaking out a bit for a while there because I had created some files with names like dillo_hg_* and "hg status" was not reporting them as untracked, even though I had not "hg add"-ed them. The problem was that .hgignore contains a line "dillo", which ignores every file with the string "dillo" anywhere in its path. Many other lines in .hgignore are similarly inappropriate. It looks as though these lines were written to be interpreted as glob-style patterns, but in fact mercurial interprets every line as a regexp. So here's patch to make .hgignore a little more sensible. Regards, Jeremy Henty

4 8