- Dillo-dev - lists.mailman3.com

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