- Dillo-dev - lists.mailman3.com

patch: [Re: [Dillo-dev] Linked image borders.]
by mr_semantics＠hotmail.com May 3, 2011

May 3, 2011

> > I am still working on trying to figure out the issue with the segfault on the other machine. > > Have you been able to wring any new information out of it? > Not yet, but I have not had much time either. Still thinking about a plan of attack. Not sure if I mentioned it, but Jorge had mentioned trying a different compiler, which I did (rebuilt both FLTK & Dillo 1.3) with gcc 4.4, 4.5, _and_ 4.6. Nothing different. Tried building FLTK2 on the problem machine, and could not get a clean compile. This interests me, as I have no problem building it on my desktop. I am going to look into that more.

1 0

Linked image borders.
by mr_semantics＠hotmail.com May 3, 2011

May 3, 2011

On this page,?http://www3.sympatico.ca/rsquared/gdb/, there are two images at the bottom which link to the W3C HTML and CSS validation pages. ?The inline style for the images is as follows: style="border:0;width:88px;height:31px" On every browser I have used, including Dillo 2.2, the blue link box around the images has not been displayed. ?Under the Dillo FLTK 1.3 port, it shows them. ?My question is, why? ?Which is the correct behaviour? Rob

3 5

Fw: Re: [Dillo-dev] next release of dillo?
by itsme_410＠yahoo.com May 2, 2011

May 2, 2011

--- On Sun, 5/1/11, corvid <corvid(a)lavabit.com> wrote: > From: corvid <corvid(a)lavabit.com> > Subject: Re: [Dillo-dev] next release of dillo? > To: Dillo-dev(a)dillo.org > Date: Sunday, May 1, 2011, 1:18 AM > Globe Trotter wrote: > > just wondering when the next release of dillo will be, > > i.e. if there is a planned timeline? we appear to be at > > dillo2.2 for a while now? > > > IIRC, maybe a month or two ago, Jorge wanted to wait until > FLTK 1.3 was released before making any Dillo releases at all, > but it seems that users find fltk bugs at the same rate that > developers fix them ( http://fltk.org/roadmap.php#1.3 ), so... > Yes, i know, thanks! Hopefully, fltk1.3 will not go the same way as fltk2. IMO, dillo's adoption seems to be negatively affected largely because of the uncertain pace and status of fltk....for instance, fedora repos are not updating dillo from 0.8.6 simply because it is based on fltk2, which is not released and perhaps will never be, though even that is not clear..... T

5 6

patch: configure rm libpng version tests
by corvid＠lavabit.com May 2, 2011

May 2, 2011

It seems that libpng is up to 1.5.0 now, so it's time to rip out some version tests.

4 16

Bookmarks sections
by dukeofperl＠ml1.net May 2, 2011

May 2, 2011

Hi ... I created a section, and immediately under that "top-level" section, 3 additional "sub-sections". No problems here. I now want to create another (and additional) "top-level" sections. I can't seem to figure out how to do that. Each new section, is created as a "sub-section" of the original "top-level" one. Anybody know if it's possible to do what I'm after? TIA ... -- Duke

1 0

Issues building Dillo
by dukeofperl＠ml1.net May 2, 2011

May 2, 2011

Hi ... I just pulled the repo did a: hg update make [output] cc1plus: warning: command line option "-fno-exceptions" is valid for Modula-2 but not for C++ mv -f .deps/object.Tpo .deps/object.Po rm -f liblout.a ar cru liblout.a container.o identity.o misc.o object.o signal.o ranlib liblout.a make[2]: Leaving directory `/home/dnormandin/Downloads/dev/dillo_port1.3/lout' Making all in dw make[2]: Entering directory `/home/dnormandin/Downloads/dev/dillo_port1.3/dw' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/dnormandin/Downloads/dev/dillo_port1.3/dw' Making all in dlib make[2]: Entering directory `/home/dnormandin/Downloads/dev/dillo_port1.3/dlib' gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/local/include -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -Waggregate-return -MT dlib.o -MD -MP -MF .deps/dlib.Tpo -c -o dlib.o dlib.c In file included from /usr/include/bits/errno.h:25, from /usr/include/errno.h:36, from dlib.c:25: /usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory dlib.c: In function 'dGetcwd': dlib.c:838: error: 'ERANGE' undeclared (first use in this function) dlib.c:838: error: (Each undeclared identifier is reported only once dlib.c:838: error: for each function it appears in.) make[2]: *** [dlib.o] Error 1 make[2]: Leaving directory `/home/dnormandin/Downloads/dev/dillo_port1.3/dlib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/dnormandin/Downloads/dev/dillo_port1.3' make: *** [all] Error 2 [/output] What did I do wrong? -- Duke

4 10

next release of dillo?
by corvid＠lavabit.com May 1, 2011

May 1, 2011

Globe Trotter wrote: > IMO, dillo's adoption seems to be negatively affected largely because of the uncertain pace and status of fltk. Are there others that make a point of being fast and light?

3 4

downloads dpi
by jcid＠dillo.org April 30, 2011

April 30, 2011

Hi there, These days I noticed I was using the FLTK2-based dpis with the fltk-1.3 dillo. :-o ! Then found a bunch of bugs and glitches in the new downloads dpi. Now the repo has a couple of patches that address the problems. After some testing it works well for download, stop, resume, rename, multiple items, etc. Please check. -- Cheers Jorge.-

1 0

Re: Page reload issue
by dukeofperl＠ml1.net April 30, 2011

April 30, 2011

On Fri, 29 Apr 2011, Duke Normandin wrote: > It seems that Dillo is not loading a fresh copy of a page when doing a > C-r or clicking on the Reload button. It seems to be reading the > cached copy only. > > I'm working on a local html page with a "link"ed css file. I change > the css, click reload - nothing happens. I have to exit and restart > Dillo for the changes to be recognized. > > Also ... > > Just crashed Dillo when trying to view the css file by right-clicking > on the current page. Just to be clear ... C-r or reload doesn;t seem to reload the external css file. OTOH, it _does_ load a fresh copy of the html file and it's changes. -- Duke

2 3

Page reload issue
by dukeofperl＠ml1.net April 29, 2011

April 29, 2011

It seems that Dillo is not loading a fresh copy of a page when doing a C-r or clicking on the Reload button. It seems to be reading the cached copy only. I'm working on a local html page with a "link"ed css file. I change the css, click reload - nothing happens. I have to exit and restart Dillo for the changes to be recognized. Also ... Just crashed Dillo when trying to view the css file by right-clicking on the current page. -- Duke

1 0

"Edit with" feature request
by dukeofperl＠ml1.net April 29, 2011

April 29, 2011

Hello folks ... This note may not be seen by too many Dillo aficionados, because most of you will no doubt be exercising your invitations to the British Royal Wedding. :) Please convey my best wishes to the Royal couple, and have a glass of "cold punch" on me! Now back to regularly scheduled programming ... How hard would it be to add a button or menu items that would allow for the editing of a page being currently viewed, the the option to declare an external editor in ~/.dillo/dillorc? -- Duke

2 6

bg_color question
by dukeofperl＠ml1.net April 28, 2011

April 28, 2011

Hey ... I've set: allow_white_bg=NO #let's see if red does show up bg_color=0xff0000 in ~/.dillo/dillorc I don't see no red anywhere - not that I want it ;) Just for debugging. Turning off white, gives me a "yellowish" bg, but I thought that setting bg_color would give me _anything but white_. Doesn't seem to be how it works. What am I missing? -- Duke

1 1

No probs - Dillo & Xubuntu 11.04
by dukeofperl＠ml1.net April 28, 2011

April 28, 2011

Hey ... FYI Just got finished an "automatic" upgrade to Xubuntu 11.04! Dillo still works great! So anybody on Ubuntu et al, don't be shy. :) -- Duke

1 0

Settings Seg-fault
by dukeofperl＠ml1.net April 28, 2011

April 28, 2011

hey ... New to the list and Dillo! I'm on an Xubuntu 10.10 box. dnormandin@select-man:~$ dillo -v Dillo version 3.0-pre dnormandin@select-man:~$ dillo & [1] 12085 dnormandin@select-man:~$ dillo_dns_init: Here we go! (threaded) Disabling cookies. Nav_open_url: new url='about:splash' [1]+ Segmentation fault dillo dnormandin@select-man:~$ This happened when i clicked on the Settings button in the toolbar. -- Duke Normandin Turner Valley, Alberta, Canada

4 20

Debug build
by mr_semantics＠hotmail.com April 25, 2011

April 25, 2011

Is there a way to turn on a debug mode when building? I have done ./configure --help, and don't see much there. Basically I am stuck - I built dillo 1.3 on my opensuse machine, and it was segfaulting. I won't fill in the details of a long story, but I went and built it on a Fedora 14 machine (actually the same machine, just booted into Fedora), and the segfault did not happen. Built it on Linux Mint (Debian edition) and the same segfault is back. It is showing the problem as being in libc, but when I do a backtrace, there is not much meaningful stuff there. I would basically like to see more information - starting with turning off the optimisation, and possibly cranking the level of the debug from -g to -ggdb3. I just wanted to ask before I started monkeying with the configure files...

3 3

HTML5
by mr_semantics＠hotmail.com April 20, 2011

April 20, 2011

Hello all, Forgive me if this has been discussed before (I do not recall seeing it since I have been following the mailing list). ?I recently started experimenting with some HTML5 stuff on a page I maintain, and as expected, dillo indicated an error in the html source. ?You can see the page here: http://www3.sympatico.ca/rsquared/gdb/ The error is: "HTML warning: line 2, the required DOCTYPE declaration is missing (or invalid)" Now this does not surprise me at all, as I presume dillo is not expecting the new doctype declaration. ?Anyway, I thought I might raise this issue, and see what sort of mind the devs have about implementing HTML5 in dillo. ?Of course, I realise you fellows are probably up to your ears in the FLTK 1.3 port, but I thought this might make for an interesting discussion, if nothing else. ?To start off, I suppose the danger in implementing any of the new html stuff is that it is not standardised at all yet. ?See here for more: http://en.wikipedia.org/wiki/HTML5#W3C_standardization_process I guess the worry is that it could possibly be a bit of a moving target. Rob

2 2

Large Panel
by jcid＠dillo.org April 17, 2011

April 17, 2011

Hi there, Does anybody use "panel_size=large" in dillorc? I'd like to remove the option in the 1.3 branch, and keep tiny, small and medium. -- Cheers Jorge.-

4 7

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