January 2011 - Dillo-dev - lists.mailman3.com

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

May 3, 2011

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

4 16

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