- Dillo-dev - lists.mailman3.com

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

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