- Dillo-dev - lists.mailman3.com

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

OT: freehg.org gone?
by onepoint＠starurchin.org Nov. 29, 2010

Nov. 29, 2010

Not that it affects us, but did anyone notice that freehg.org has gone? I can't Google anything useful, does anyone know more? Regards, Jeremy Henty

1 0

[patch]: @media support
by onepoint＠starurchin.org Nov. 22, 2010

Nov. 22, 2010

Does what it says on the tin. Please review and comment. I'm going to road-test this at home for a few days before pushing it. Naturally I won't push it if people have objections or corrections. But it does fix this site[1]! Regards, Jeremy Henty [1]: http://www.psychologicalscience.org/onlyhuman/2009/01/paradox-of-temptation…

3 3

[patch]: ignore unknown @-rules in CSS
by onepoint＠starurchin.org Nov. 21, 2010

Nov. 21, 2010

Currently Dillo tries to parse every @-rule in the same way (with CssParser::parseImport()). This causes problems, particularly with @media. Here[1] part of the style is missing so that the line size is smaller than the text. I have also attached a small test case where a @media rule causes the red style to go missing. So, here are two patches that make Dillo ignore @-rules that it does not recognise. The first patch just moves the test for the import keyword from CssParser::parseImport() into the main parser loop. Because it changes indentation it looks much more radical than it is. The second patch reworks the main parser loop so that CssParser::parseImport() is only called for @import and other @-rules are skipped. Please review and comment. I will push the patches if you think they are good. Regards, Jeremy Henty [1]http://johannhari.com//2010/11/19/we-should-not-tolerate-religious-excuse…

2 2

patch: text-indent
by corvid＠lavabit.com Nov. 19, 2010

Nov. 19, 2010

Johannes wrote: > On Sat, Nov 06, 2010 at 03:04:16PM +0000, corvid wrote: > > "Percentage values: refer to parent element's width" > > > > So a Textblock wants to decide how big it is, and it asks its children > > how big they are, and the child has, say, text-indent: 50%, and so it > > gets to wordWrap and asks "So, ah...how big are _you_?". And the parent > > doesn't know yet. > > Ah interesting.... > > What about using something like availWidth in Textblock::wordWrap() as an > aproximation of the future width of the Textblock? > Maybe this would be good enough. > In which cases would this be way off? That's a good idea! It seems to work pretty well in general... (You will note that this ignores negative values (LENGTH_PERCENTAGE) and allows overflow.)

3 11

fatal error while compiling fltk
by lolveley＠yahoo.fr Nov. 18, 2010

Nov. 18, 2010

fine! I compiled fltk without the text "glut" near DIRS, and then dillo, all this without errors. and now I have HTML support in claws-mail. thanks! olivier Le Thu, 18 Nov 2010 19:25:48 +0000, James Lovejoy <jameslovejoy(a)tiscali.co.uk> a ?crit : > Right, well it seems to me it's just building tests. So open > "Makefile" and delete the word "glut" from the DIRS variable. I > haven't tested it but it should work. > > On 18 Nov 2010, at 19:05, olivier SAINT-EVE <lolveley(a)yahoo.fr> wrote: > > > Hello, > > > > here is the result of the compilation of fltk: > > ******************************************************************** > > lolveley@linux-f5pi:~/bin/claws/fltk-2.0.x-r7725> make > > === making src === > > === making images/libjpeg === > > === making images/libpng === > > === making images === > > === making OpenGL === > > === making fluid === > > === making glut === > > Linking glpuzzle... > > glpuzzle.o: In function `redraw()': > > glpuzzle.cxx:(.text+0xbe7): undefined reference to `gluPerspective' > > glpuzzle.o: In function `selectPiece(int, int)': > > glpuzzle.cxx:(.text+0x12a6): undefined reference to `gluPickMatrix' > > glpuzzle.cxx:(.text+0x12da): undefined reference to `gluPerspective' > > collect2: ld returned 1 exit status > > make[1]: *** [glpuzzle] Erreur 1 > > make: *** [all] Erreur 2 > > ******************************************************************* > > I tried to compile glut and I have an error too. > > can give you this if you want. > > > > olivier > > > > Le 18/11/2010 19:56, James Lovejoy a ?crit : > >> Hi, > >> > >> Could you post the error because I think I got this error when > >> compiling fltk but I can't remember how I fixed it. Maybe it will > >> jog my memory. > >> > >> James > >> > >> On 18 Nov 2010, at 16:45, olivier SAINT-EVE <lolveley(a)yahoo.fr> > >> wrote: > >> > >> > >>> well, I tried to install mesa, but it is already installed, and > >>> the compilation with "--disable-gl" fails with an error while > >>> compiling glut. > >>> > >>> seems I will have HTML support in a long time, if so! > >>> > >>> olivier > >>> > >>> Le Thu, 18 Nov 2010 11:21:20 -0300, > >>> Jorge Arellano Cid <jcid(a)dillo.org> a ?crit : > >>> > >>> > >>>> On Thu, Nov 18, 2010 at 12:32:49PM +0100, Joerg Sonnenberger > >>>> wrote: > >>>> > >>>>> On Thu, Nov 18, 2010 at 12:16:40PM +0100, olivier SAINT-EVE > >>>>> wrote: > >>>>> > >>>>>> sounds like GLU is missing, but an internet search didn't help > >>>>>> me to find libglu-mesa, or libglu, or glu, in a rpm format. > >>>>>> > >>>>> Try Mesa. > >>>>> > >>>> You can install mesa GL, or you may try: > >>>> > >>>> ./configure --disable-gl ... > >>>> > >>>> when compiling FLTK. > >>>> > >>>> Disclaimer: I haven't tried it, but assume it should work. > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Dillo-dev mailing list > >>> Dillo-dev(a)dillo.org > >>> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > >>> > >> > >

1 0

fatal error while compiling fltk
by lolveley＠yahoo.fr Nov. 18, 2010

Nov. 18, 2010

Le 18/11/2010 20:05, olivier SAINT-EVE a ?crit : > Hello, > > here is the result of the compilation of fltk: > ******************************************************************** > lolveley@linux-f5pi:~/bin/claws/fltk-2.0.x-r7725> make > === making src === > === making images/libjpeg === > === making images/libpng === > === making images === > === making OpenGL === > === making fluid === > === making glut === > Linking glpuzzle... > glpuzzle.o: In function `redraw()': > glpuzzle.cxx:(.text+0xbe7): undefined reference to `gluPerspective' > glpuzzle.o: In function `selectPiece(int, int)': > glpuzzle.cxx:(.text+0x12a6): undefined reference to `gluPickMatrix' > glpuzzle.cxx:(.text+0x12da): undefined reference to `gluPerspective' > collect2: ld returned 1 exit status > make[1]: *** [glpuzzle] Erreur 1 > make: *** [all] Erreur 2 > ******************************************************************* > I tried to compile glut and I have an error too. > can give you this if you want. > > olivier > > Le 18/11/2010 19:56, James Lovejoy a ?crit : > >> Hi, >> >> Could you post the error because I think I got this error when compiling fltk but I can't remember how I fixed it. Maybe it will jog my memory. >> >> James >> >> On 18 Nov 2010, at 16:45, olivier SAINT-EVE <lolveley(a)yahoo.fr> wrote: >> >> >> >>> well, I tried to install mesa, but it is already installed, and the >>> compilation with "--disable-gl" fails with an error while compiling >>> glut. >>> >>> seems I will have HTML support in a long time, if so! >>> >>> olivier >>> >>> Le Thu, 18 Nov 2010 11:21:20 -0300, >>> Jorge Arellano Cid <jcid(a)dillo.org> a ?crit : >>> >>> >>> >>>> On Thu, Nov 18, 2010 at 12:32:49PM +0100, Joerg Sonnenberger wrote: >>>> >>>> >>>>> On Thu, Nov 18, 2010 at 12:16:40PM +0100, olivier SAINT-EVE wrote: >>>>> >>>>> >>>>>> sounds like GLU is missing, but an internet search didn't help me >>>>>> to find libglu-mesa, or libglu, or glu, in a rpm format. >>>>>> >>>>>> >>>>> Try Mesa. >>>>> >>>>> >>>> You can install mesa GL, or you may try: >>>> >>>> ./configure --disable-gl ... >>>> >>>> when compiling FLTK. >>>> >>>> Disclaimer: I haven't tried it, but assume it should work. >>>> >>>> >>>> >>> _______________________________________________ >>> Dillo-dev mailing list >>> Dillo-dev(a)dillo.org >>> http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >>> >>> >> >> >

1 0

fatal error while compiling fltk
by lolveley＠yahoo.fr Nov. 18, 2010

Nov. 18, 2010

hello, I have opensuse 11.3 with gnome, and claws-mail. in order to view html content on claws-mail, I had to compile dillo. so I went to the site, downloaded fltk and tried to compile it (fltk-2.0.x-r7725). but after entering "make", I had this error : ******************************************************************** === making src === Compiling addarc.cxx... In file included from ../fltk/x.h:38:0, from addarc.cxx:32: ../fltk/x11.h:65:38: fatal error: X11/extensions/XInput.h: Aucun fichier ou dossier de ce type compilation terminated. make[1]: *** [addarc.o] Erreur 1 make: *** [all] Erreur 2 ******************************************************************** can you tell me if a peculiar software is missing? I searched with google (X11,RPMs of dillo) but in vain. thanks, Olivier.

4 6

Dillo-Win32 patches - yet another update
by obeythepenguin＠gmail.com Nov. 18, 2010

Nov. 18, 2010

After noticing some weird performance/stability issues in the latest Win32 build, I went back and noticed there was a bug in the dFcntl implementation, where non-blocking socket IO was never actually activated on Win32 (Unix and other platforms weren't affected). So I've updated the patches to fix that and a few other small things I discovered. First, the link: http://dillo-win32.sourceforge.net/patches.html Other changes: I've numbered the patches to reflect the dependency order, as much for my own sanity as anything. I've also removed the Html_css_repush_callback patch, since it breaks CSS streaming, though I've kept a copy on the off-chance there's ever a legitimate issue after all. I also have an updated testing build (binary and source) online if anyone wants to play with it. My build is still based on revision 1755, but that's only because the latest rendering code in hg's being worked on -- the patch applies, builds, and runs fine with the newest code as well. Johannes: I have not yet updated the DNS patch, but I intend to this weekend if I have the time. Thanks again for everyone's help and suggestions with this. I hope I have more to contribute in the future :-) Cheers, ~Benjamin

1 0

[bug]: CssParser::{nextToken, skipString}() skip an extra character.
by onepoint＠starurchin.org Nov. 16, 2010

Nov. 16, 2010

The CssParser class has an unfortunate interaction between nextToken() and skipString(): they are both eager to call getChar(). The result is that when skipString() succeeds it has already getChar()-ed the character immediately after the string to be skipped, but nextToken() insists on calling getChar() again. This means that the character after the skipped string is also skipped. This causes two bugs. Firstly, if there is a completely empty CSS comment, ie. '/**/', then the closing '*/' is ignored (because it has already been partly skipped over). This generally causes most or all of the style to be ignored as the parser searches for the end of the comment. You can see this in the wild[1]! Secondly, if a token starts immediately after a CSS comment, then its first character is lost. The attached example shows both bugs. The first bug stops the red style from being applied to the <p> element, and the second bug applies the blue style to the <i> element instead of the <li> element. The quick fix is for skipString() to call ungetChar() before returning successfully (patch attached). Luckily only nextToken() calls skipString(). Should I push this, or is there a better way to do it? [1] http://layscience.net/node/1120

3 4

Dillo-Win32 patches, split and ready to merge
by obeythepenguin＠gmail.com Nov. 14, 2010

Nov. 14, 2010

Here are the split Dillo-Win32 patches, ready to merge into the upstream tree: http://dillo-win32.sourceforge.net/patches.html I've cleaned up the code somewhat, such as removing the ugly conditionals from dsock.h. This version no longer includes the infamous "timeout kludge"; however, it must be built against a patched FLTK2 library, as the upstream implementation is still very badly broken. (The necessary patch is available from the Dillo-Win32 SourceForge site.) These patches produce a working ./src/dillo.exe. DPI has not yet been ported, as I presently have neither the time nor interest to do so. I'll probably get a binary package and installer up sometime in the next few days for anyone who wants to play around with the latest and greatest. Let me know if I need to double-check anything. Cheers, ~Benjamin

4 7