- Dillo-dev - lists.mailman3.com

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

hg repo

by corvid＠lavabit.com

Fredrik wrote: > On Mon, Jan 03, 2011 at 05:10:26PM +0000, corvid wrote: > > Fredrik wrote: > > > On Mon, Jan 03, 2011 at 12:54:09PM -0300, Jorge Arellano Cid wrote: > > > > * Can corvid make another repo in the same server? (e.g. for the port > > > > to fltk-1.3) > > > Isn't it better to just make an other branch in the same repo? Can't everybody > > > with commit access do that? That should make bug fix sharing easier, > > > right? > > > > How much does that complicate usage? Is it pretty much 1) name a new branch > > and 2) use the same hg commands as usual but add some branch argument? > > > > I actually don't know, that's why I asked. I'm not that familiar with hg > but with git. In git it would be very easy, and hg and git is very alike > according to branching if I recall correct. > > However a hg guru should answear that question. http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.h… makes it sounds like either a new repository or a new branch would be a fairly standard response to our situation. > In git you define your branch when you clone the repository and > thereafter use git as usual. (of course you can change branches after a > clone etc.). > > The main point is, that a bug found in dillo with fltk 2.0 that is > also in dillo with fltk 1.3 should be able to be fixed with the same > commit. This is known as the double maintenance problem. One commit is visible in both branches?

Jan. 3, 2011

hg repo

by iveqy＠iveqy.com

On Mon, Jan 03, 2011 at 05:10:26PM +0000, corvid wrote: > Fredrik wrote: > > On Mon, Jan 03, 2011 at 12:54:09PM -0300, Jorge Arellano Cid wrote: > > > * Can corvid make another repo in the same server? (e.g. for the port > > > to fltk-1.3) > > Isn't it better to just make an other branch in the same repo? Can't everybody > > with commit access do that? That should make bug fix sharing easier, > > right? > > How much does that complicate usage? Is it pretty much 1) name a new branch > and 2) use the same hg commands as usual but add some branch argument? > I actually don't know, that's why I asked. I'm not that familiar with hg but with git. In git it would be very easy, and hg and git is very alike according to branching if I recall correct. However a hg guru should answear that question. In git you define your branch when you clone the repository and thereafter use git as usual. (of course you can change branches after a clone etc.). The main point is, that a bug found in dillo with fltk 2.0 that is also in dillo with fltk 1.3 should be able to be fixed with the same commit. This is known as the double maintenance problem. /iveqy

Jan. 3, 2011

hg repo

by corvid＠lavabit.com

Fredrik wrote: > On Mon, Jan 03, 2011 at 12:54:09PM -0300, Jorge Arellano Cid wrote: > > * Can corvid make another repo in the same server? (e.g. for the port > > to fltk-1.3) > Isn't it better to just make an other branch in the same repo? Can't everybody > with commit access do that? That should make bug fix sharing easier, > right? How much does that complicate usage? Is it pretty much 1) name a new branch and 2) use the same hg commands as usual but add some branch argument?

Jan. 3, 2011

hg repo

by iveqy＠iveqy.com

On Mon, Jan 03, 2011 at 12:54:09PM -0300, Jorge Arellano Cid wrote: > * Can corvid make another repo in the same server? (e.g. for the port > to fltk-1.3) Isn't it better to just make an other branch in the same repo? Can't everybody with commit access do that? That should make bug fix sharing easier, right? //iveqy

Jan. 3, 2011