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

[patch]: more configure.in cleanups

by jcid＠dillo.org

On Wed, Jan 05, 2011 at 08:24:58AM +0000, Jeremy Henty wrote: > On Tue, Jan 04, 2011 at 07:12:34PM -0300, Jorge Arellano Cid wrote: > > On Tue, Jan 04, 2011 at 07:01:24PM +0000, Jeremy Henty wrote: > > > On Sat, Jan 01, 2011 at 11:13:10AM +0000, Jeremy Henty wrote: > > > > > > Bump? I have one upvote from corvid, what do the other devs think? > > > (If nothing else I'd like to fix the "AC_ARG_PROGRAM was called before > > > AC_CANONICAL_TARGET" warning, since it was my fault!) > > > > When a simple patch doesn't work as expected, there's an > > excellent excuse for a cleanup around it. ;-) > > > > My vote is: go ahead quickly! > > OK, done! It works for me. Now let's see what the list says. -- Cheers Jorge.-

Jan. 5, 2011

[patch]: more configure.in cleanups

by onepoint＠starurchin.org

On Tue, Jan 04, 2011 at 07:12:34PM -0300, Jorge Arellano Cid wrote: > On Tue, Jan 04, 2011 at 07:01:24PM +0000, Jeremy Henty wrote: > > On Sat, Jan 01, 2011 at 11:13:10AM +0000, Jeremy Henty wrote: > > > > Bump? I have one upvote from corvid, what do the other devs think? > > (If nothing else I'd like to fix the "AC_ARG_PROGRAM was called before > > AC_CANONICAL_TARGET" warning, since it was my fault!) > > When a simple patch doesn't work as expected, there's an > excellent excuse for a cleanup around it. ;-) > > My vote is: go ahead quickly! OK, done! Regards, Jeremy Henty

Jan. 5, 2011

Not to name dillo 1.3 & not to drop fltk 2.0 support

by rogerx.oss＠gmail.com

On Wed, Jan 05, 2011 at 12:30:22AM +0000, corvid wrote: >Roger wrote: >> fltk-3.0 is the next, hopefully very soon to be released stable version. > >Is anything still going on with 3.0? It seems like I haven't heard anything >about it for some time now... OOPS! My bag. I meant fltk-1.3 is the next version. (... dumb typos... wish God would make them disappear.) But, while we're on the topic of fltk-3.0 version, from what I read on the fltk website, 3.0 is the future version planned to incorporate 2.0 changes from the earlier 1.0 branch, if they aren't already incorporated to 1.* versions. (I'm no expert on fltk/dillo, just trying to correctly relay what I read.) -- Roger http://rogerx.freeshell.org/

Jan. 5, 2011

Not to name dillo 1.3 & not to drop fltk 2.0 support

by corvid＠lavabit.com

Roger wrote: > fltk-3.0 is the next, hopefully very soon to be released stable version. Is anything still going on with 3.0? It seems like I haven't heard anything about it for some time now...

Jan. 5, 2011

Not to name dillo 1.3 & not to drop fltk 2.0 support

by rogerx.oss＠gmail.com

On Tue, Jan 04, 2011 at 08:48:05AM +0100, Diego . wrote: >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. >From other posters here and from previously reading the FLTK homepage concerning future versions of FLTK, FLTK is the package downgrading it's version to 1.3 (from 2.0) for the next future release -- not Dillo. >Second. I want to suggest to not to remove the fltk 2.0 support code from dillo. If you spend some time reading the FLTK homepage, you'll begin to understand why fltk-2.0 is deprecated. fltk-3.0 is the next, hopefully very soon to be released stable version. Gentoo has a fltk-1.3rc ebuild availabe on bugs.gentoo.org. -- Roger http://rogerx.freeshell.org/

Jan. 5, 2011

[patch]: more configure.in cleanups

by jcid＠dillo.org

On Tue, Jan 04, 2011 at 07:01:24PM +0000, Jeremy Henty wrote: > On Sat, Jan 01, 2011 at 11:13:10AM +0000, Jeremy Henty wrote: > > Bump? I have one upvote from corvid, what do the other devs think? > (If nothing else I'd like to fix the "AC_ARG_PROGRAM was called before > AC_CANONICAL_TARGET" warning, since it was my fault!) When a simple patch doesn't work as expected, there's an excellent excuse for a cleanup around it. ;-) My vote is: go ahead quickly! -- Cheers Jorge.-

Jan. 4, 2011

[patch]: more configure.in cleanups

by onepoint＠starurchin.org

On Sat, Jan 01, 2011 at 11:13:10AM +0000, Jeremy Henty wrote: Bump? I have one upvote from corvid, what do the other devs think? (If nothing else I'd like to fix the "AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET" warning, since it was my fault!) Regards, Jeremy Henty > 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… > # HG changeset patch > # Parent dc2a158373516a528d7e02fbfb21a5722a21a1ca > configure.in: move AC_CANONICAL_SYSTEM to fix an autoconf warning. > > diff -r dc2a15837351 -r 676eaaad8f1b configure.in > --- a/configure.in Sat Jan 01 09:42:40 2011 +0000 > +++ b/configure.in Sat Jan 01 10:39:06 2011 +0000 > @@ -1,13 +1,14 @@ > dnl Process this file with aclocal, autoconf and automake. > > AC_INIT([dillo], [2.2]) > + > +dnl Detect the canonical host and target build environment > +AC_CANONICAL_SYSTEM > + > AM_INIT_AUTOMAKE > AC_CONFIG_SRCDIR([src/dillo.cc]) > AC_CONFIG_HEADERS([config.h]) > > -dnl Detect the canonical host and target build environment > -AC_CANONICAL_SYSTEM > - > sysconfdir=${sysconfdir}/${PACKAGE} > > dnl Options > # HG changeset patch > # Parent dc17d306c0cd8ebb53cc61ef98f85096d50f0157 > configure.in: remove obsolete AM_PROG_CC_STDC. > > diff -r dc17d306c0cd -r 5085c1daa875 configure.in > --- a/configure.in Thu Dec 30 12:48:30 2010 +0000 > +++ b/configure.in Fri Dec 31 08:48:17 2010 +0000 > @@ -39,7 +39,6 @@ > AC_ARG_ENABLE(rtfl, [ --enable-rtfl Build with rtfl messages]) > AC_PROG_CC > AC_PROG_CXX > -AM_PROG_CC_STDC > AC_PROG_RANLIB > AC_PROG_CPP > > # HG changeset patch > # Parent 5085c1daa8755400e84974cd7f8d4dd54f3e005d > configure.in: remove obsolescent AC_HEADER_STDC. > > diff -r 5085c1daa875 -r 9041562674a8 configure.in > --- a/configure.in Fri Dec 31 08:48:17 2010 +0000 > +++ b/configure.in Fri Dec 31 09:26:48 2010 +0000 > @@ -448,7 +448,6 @@ > dnl Checks for header files > dnl ----------------------- > dnl > -AC_HEADER_STDC > AC_CHECK_HEADERS(fcntl.h unistd.h sys/uio.h) > > dnl -------------------------- > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 4, 2011

Not to name dillo 1.3 & not to drop fltk 2.0 support

by jcid＠dillo.org

Hi, On Tue, Jan 04, 2011 at 08:48:05AM +0100, Diego . wrote: > [...] > 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. Unfortunately this is not true. Dw has an abstraction layer, but all the user interface is native. > 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. Given the manpower, this *may* be possible. Although I don't see much worth in supporting a dead library, given the new one is less buggy and more capable. YMMV. -- Cheers Jorge.-

Jan. 4, 2011

Not to name dillo 1.3 & not to drop fltk 2.0 support

by corvid＠lavabit.com

Diego wrote: > 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. We don't plan to decrease dillo's version number. Sorry for the confusion there. > 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. Given the amount of fltk2 code in src/ now, I have to wonder how well we could support multiple toolkits even in the case when they are all healthy and active...

Jan. 4, 2011

Not to name dillo 1.3 & not to drop fltk 2.0 support

by darkspirit5000＠gmail.com

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.

Jan. 4, 2011