- Dillo-dev - lists.mailman3.com

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

hg repo

by jcid＠dillo.org

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.-

Jan. 3, 2011

Happy new year!

by rogerx.oss＠gmail.com

... Eh, for any computer user whom doesn't want to waste their precious RAM and CPU cycles on ads, scripts & plain simple bloat! Can't remember a time when somebody said I needed a very expensive BMW or Ferrari to get from point A to point B! Elinks & Dillo are just fine for reading text! On Sun, Jan 02, 2011 at 09:59:58PM +0100, Martin Jernberg wrote: > Happy new year and continue doing the greatest browser for older computers > :) > > > Date: Sun, 2 Jan 2011 12:39:25 -0300 > > From: jcid(a)dillo.org > > To: dillo-dev(a)dillo.org > > Subject: [Dillo-dev] Happy new year! > > > > 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. -- Roger http://rogerx.freeshell.org/

Jan. 3, 2011

[patch]: more configure.in cleanups

by corvid＠lavabit.com

Jeremy wrote: > corvid wrote: > > Jeremy wrote: > > > Some more cleaning up of configure.in: > > > > It all seems reasonable to me -- and works when I run it :) > > > > > > Looking through configure.in, I remember that Joerg wanted us to > > update the AC_CHECK_SIZEOF stuff at one point... > > TO_DO++ :-) . Any idea what he thought needed doing? http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-October/005135.html has: Consider to replace the AC_CHECK_SIZEOF() point and d_size.h magic with AC_TYPE_UINT16_T and friends. THose use either the system macros or figure out the rest (just include inttypes.h and sys/types.h if present).

Jan. 2, 2011

[patch]: modernize configure.in's initialization and configuration

by weigelt＠metux.de

* Jeremy Henty <onepoint(a)starurchin.org> schrieb: > On Sat, Jan 01, 2011 at 10:28:55AM +0000, corvid wrote: > > Now that I run it instead of just reading the documentation > > (reminds me of that one Knuth line), I get some > > > > configure.in:9: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET > > ./../lib/autoconf/general.m4:1843: AC_CANONICAL_SYSTEM is expanded from... > > configure.in:9: the top level > > Yes, my fault, AC_CANONICAL_SYSTEM needs to be called immediately > after AC_INIT . Just about to submit a fix! BTW: if you someday encounter issues with certain previously set variables ending up empty, it also might have to do with that ordering. (IIRC AC_INIT() seems to clear variables). Autoconf is hell ;-o cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt(a)metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------

Jan. 2, 2011