- Dillo-dev - lists.mailman3.com

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

by obeythepenguin＠gmail.com

On Fri, 07 Jan 2011 08:22:39 -0500, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > I would fully move over to fltk-1.3. We still keep the fltk2 code in > the history. > Of course if someone wants to maintain a fltk2 branch, that would be > nice. > > Cheers, > Johannes Maybe I'm in the minority here, but frankly I'd rather see Dillo just pick a toolkit and stick with it. FLTK2 might not have been the best choice in hindsight, but it does the job, and it has a much nicer API than 1.x (I've used both extensively). Porting to another toolkit, even a comparatively trivial port like switching FLTK versions, takes time away from "real" development; makes it difficult for outside developers to participate; and to an outside observer, makes project leadership look somewhat indecisive, especially when we've barely settled in after ditching GTK+ (I'll concede *that* switch was a necessary evil and a vast improvement). I understand the arguments for switching, but I'm not convinced the needs are really all that pressing, or that Dillo can really afford another such drastic overhaul right now. Cheers, ~Benjamin

Jan. 7, 2011

Copy and paste from page content area

by obeythepenguin＠gmail.com

On Fri, 07 Jan 2011 07:52:06 -0500, Johannes Hofmann <Johannes.Hofmann(a)gmx.de> wrote: > Hm, I would have thought that copy/paste just works on Windows > via the fltk::copy() call in FltkPlatform::copySelection(). > Does copy/paste work for fltk2/test programs on Windows? > > Cheers, > Johannes Copy/paste works from text boxes with the keyboard shortcuts. Select-and-middle-click works within FLTK (for example, I can copy from the content area to the address bar, no problem), but definitely not to other Windows apps. You'd think it would just work, but when you're dealing with a toolkit as badly broken as FLTK, just about anything is possible -- and don't get me started on X11-isms. I have not tried the test programs, but I will when I have a chance. Fortunately I'm no stranger to patching FLTK. Cheers, ~Benjamin

Jan. 7, 2011

hg repo

by corvid＠lavabit.com

Johannes wrote: > I would go with a separate repo for fltk-1.3 development. It's still > a branch, so we can use 3-way merging to keep things in sync with > mainline. The only difference is that you don't get fltk-1.3 > development stuff automatically when cloning the main repo - which I > think is a good thing. > Once it's ready we pull it over in the main repo. That's the same > procedure we used for the CSS-experimental branch. Andreas added a repository for me. I've done most of the really mindless parts now, so now we merely need to do all of the hard parts!

Jan. 7, 2011

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

by Johannes.Hofmann＠gmx.de

Hi, On Tue, Jan 04, 2011 at 12:43:49PM -0300, Jorge Arellano Cid wrote: > 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. I think it wouldn't even make sense to have an abstraction layer for the GUI. The GUI is concentrated in a small number of files in src/* and those files have to be ported. An abstraction layer here would complicate things more than it would help. > > > > 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. I would fully move over to fltk-1.3. We still keep the fltk2 code in the history. Of course if someone wants to maintain a fltk2 branch, that would be nice. Cheers, Johannes

Jan. 7, 2011

hg repo

by Johannes.Hofmann＠gmx.de

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 would go with a separate repo for fltk-1.3 development. It's still a branch, so we can use 3-way merging to keep things in sync with mainline. The only difference is that you don't get fltk-1.3 development stuff automatically when cloning the main repo - which I think is a good thing. Once it's ready we pull it over in the main repo. That's the same procedure we used for the CSS-experimental branch. Cheers, Johannes

Jan. 7, 2011

Copy and paste from page content area

by Johannes.Hofmann＠gmx.de

On Wed, Dec 29, 2010 at 03:13:02PM -0500, Benjamin Johnson wrote: > On Wed, 29 Dec 2010 14:56:43 -0500, corvid <corvid(a)lavabit.com> wrote: > > >It has that mechanism where you highlight text with the left mouse button > >to select it and middle button to paste somewhere, but it doesn't do the > >one that uses control keys (which I've never understood the value of). > > Non-X11 systems don't have the select-and-middle-click mechanism, > and with most X11 toolkits (Qt, GTK+, etc.), the control key > mechanism is more persistent. > > Anyway, thanks for the answer. That's one of the next things I was > planning to implement. Hm, I would have thought that copy/paste just works on Windows via the fltk::copy() call in FltkPlatform::copySelection(). Does copy/paste work for fltk2/test programs on Windows? Cheers, Johannes

Jan. 7, 2011

[patch]: more spring cleaning of configure.in

by corvid＠lavabit.com

Jeremy wrote: > 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. Works without giving me any problems...

Jan. 6, 2011

configure.in

by corvid＠lavabit.com

Jorge wrote: > On Wed, Jan 05, 2011 at 09:46:29PM +0000, corvid wrote: > > 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. > > Probably because that way it worked with an older version. > Does the generated binary size change? Or is there a change > with ldd? No difference. (I was hoping it might make it a bit smaller.) > If the button icons load OK, and the file chooser works, there > should be no problems. Those widgets *may* need the internal > image handling (but I don't know for sure).

Jan. 6, 2011

configure.in

by jcid＠dillo.org

On Wed, Jan 05, 2011 at 09:46:29PM +0000, corvid wrote: > 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. Probably because that way it worked with an older version. Does the generated binary size change? Or is there a change with ldd? If the button icons load OK, and the file chooser works, there should be no problems. Those widgets *may* need the internal image handling (but I don't know for sure). -- Cheers Jorge.-

Jan. 6, 2011

[patch]: more spring cleaning of configure.in

by onepoint＠starurchin.org

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#…

Jan. 5, 2011

configure.in

by corvid＠lavabit.com

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.

Jan. 5, 2011

[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

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

[patch]: more configure.in cleanups

by onepoint＠starurchin.org

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? Regards, Jeremy Henty

Jan. 2, 2011

Happy new year!

by cs_bittin＠msn.com

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. > > (-: 2011 :-) > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 2, 2011

Happy new year!

by jcid＠dillo.org

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. (-: 2011 :-) -- Cheers Jorge.-

Jan. 2, 2011

[patch]: more configure.in cleanups

by corvid＠lavabit.com

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

Jan. 1, 2011

[patch]: more configure.in cleanups

by onepoint＠starurchin.org

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…

Jan. 1, 2011

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

by onepoint＠starurchin.org

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! Regards, Jeremy Henty

Jan. 1, 2011

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

by corvid＠lavabit.com

BTW, I see that configure.ac is preferred to configure.in nowadays. http://www.mail-archive.com/autoconf@gnu.org/msg19641.html says: "...the naming change to configure.ac was YEARS ago, for autoconf 2.50. And now that autoconf 2.59 is about as old as you can reliably go (for example, RHEL 5 still uses autoconf 2.59), it is completely safe to use the (not so) new naming convention." It seems that 2.50 came out in 2001.

Jan. 1, 2011

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

by corvid＠lavabit.com

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

Jan. 1, 2011

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

by onepoint＠starurchin.org

On Fri, Dec 31, 2010 at 10:58:25PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Dec 30, 2010 at 01:22:38PM +0000, Jeremy Henty wrote: > > > > > > Dillo's configure.in uses some obsolete autoconf/automake macros and > > > calls some others in obsolete ways. This patch brings it (mostly) up > > > to date. > > > > > > Any problems with this or shall I push it? > > > > From the patch and docs, it looks OK to commit. > > +1 > > Ditto. Done! Regards, Jeremy Henty

Jan. 1, 2011

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

by corvid＠lavabit.com

Jorge wrote: > On Thu, Dec 30, 2010 at 01:22:38PM +0000, Jeremy Henty wrote: > > > > Dillo's configure.in uses some obsolete autoconf/automake macros and > > calls some others in obsolete ways. This patch brings it (mostly) up > > to date. > > > > Any problems with this or shall I push it? > > From the patch and docs, it looks OK to commit. > +1 Ditto.

Dec. 31, 2010

[jcid@dillo.org: Re: [Dillo-dev] [patch]: modernize configure.in's initialization and configuration]

by jcid＠dillo.org

Just noticed I didn't replied this to the list (by mistake). -- Cheers Jorge.-

Dec. 30, 2010

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

by onepoint＠starurchin.org

On Thu, Dec 30, 2010 at 02:38:23PM +0000, corvid wrote: > Jeremy wrote: > > Dillo's configure.in uses some obsolete autoconf/automake macros > > and calls some others in obsolete ways. This patch brings it > > (mostly) up to date. > > How ancient would a user's auto* have to be to be unable to > recognize the newer form? Users don't run autoconf. What matters is whether the dev's auto* versions are new enough. Unfortunately the man pages don't say when the new macro syntaxes were introduced, but my impression is that the old versions have been deprecated for years. For comparison my versions are autoconf 2.64 (released 2009/07/26) and automake 1.11 (released 2009/05/27). Are any devs using older versions? (I thought my system was usually older than the rest of yours, witness the time when I was still on GCC 3 and submitted patches that broke under GCC 4.) I checked the release announcements on the autotools list back to autoconf 2.60 (released 2006/06/26) and automake 1.10 (released 2006/08/15) and didn't see any references to the new syntaxes of AC_INIT and AM_INIT_AUTOMAKE, so I assume that we're OK unless some of the devs have tools from before the second half of 2006. Also, after searching the autotools mailing list archives (all the way back to Feb 2003): there are no references to AM_INIT_AUTOMAKE, and of the 5 mentions of AC_INIT, the only reference to new syntax is the addition of the optional 5th argument to specify the package URL. I think we're pretty safe with the new syntax! Regards, Jeremy Henty

Dec. 30, 2010

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

by jcid＠dillo.org

On Thu, Dec 30, 2010 at 01:22:38PM +0000, Jeremy Henty wrote: > > Dillo's configure.in uses some obsolete autoconf/automake macros and > calls some others in obsolete ways. This patch brings it (mostly) up > to date. > > Any problems with this or shall I push it? From the patch and docs, it looks OK to commit. +1 -- Cheers Jorge.-

Dec. 30, 2010

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

by corvid＠lavabit.com

Jeremy wrote: > Dillo's configure.in uses some obsolete autoconf/automake macros and > calls some others in obsolete ways. This patch brings it (mostly) up > to date. How ancient would a user's auto* have to be to be unable to recognize the newer form?

Dec. 30, 2010

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

by onepoint＠starurchin.org

Dillo's configure.in uses some obsolete autoconf/automake macros and calls some others in obsolete ways. This patch brings it (mostly) up to date. Any problems with this or shall I push it? Regards, Jeremy Henty References: AC_INIT autoconf manual: section 4.1: Initializing configure http://www.gnu.org/software/autoconf/manual/html_node/Initializing-configur… AC_INIT (obsolete form) autoconf manual: section 18.4: Obsolete Macros http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html AM_INIT_AUTOMAKE automake manual: section 6.4.1: Public Macros http://www.gnu.org/software/autoconf/manual/automake/Public-Macros.html AM_CONFIG_HEADER (obsolete) automake manual: section 6.4.2: Obsolete Macros http://www.gnu.org/software/autoconf/manual/automake/Obsolete-Macros.html

Dec. 30, 2010

Copy and paste from page content area

by obeythepenguin＠gmail.com

On Wed, 29 Dec 2010 14:56:43 -0500, corvid <corvid(a)lavabit.com> wrote: > It has that mechanism where you highlight text with the left mouse button > to select it and middle button to paste somewhere, but it doesn't do the > one that uses control keys (which I've never understood the value of). Non-X11 systems don't have the select-and-middle-click mechanism, and with most X11 toolkits (Qt, GTK+, etc.), the control key mechanism is more persistent. Anyway, thanks for the answer. That's one of the next things I was planning to implement. ~Benjamin

Dec. 29, 2010

Copy and paste from page content area

by corvid＠lavabit.com

Benjamin wrote: > 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. :-) It has that mechanism where you highlight text with the left mouse button to select it and middle button to paste somewhere, but it doesn't do the one that uses control keys (which I've never understood the value of). I was going to say that sometimes I double-click words with the expectation that they'll be selected, and this makes me think: What is the double click emitter for in dw/selection.cc, anyway? I don't see anything using it...

Dec. 29, 2010

Copy and paste from page content area

by obeythepenguin＠gmail.com

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

Dec. 29, 2010

A question about the nature of this list

by mr_semantics＠hotmail.com

---------------------------------------- > From: corvid(a)lavabit.com > Date: Tue, 28 Dec 2010 07:09:09 +0000 > Almost certainly something wrong in fltk2 or dillo. > The situations that I'm aware of that screw up rendering are: > - configuring fltk with --enable-cairo > - running on OSX > Do either of these apply? Well I did not explicitly do?--enable-cairo this time (or any other time I have built dillo), so I will say not. ? And I am running this on OpenSUSE Linux i386. For good measure, I went and built against a different version of fltk2, to see if I missed anything. ?Still the same trouble. ?My build process is outlined in a blog post I wrote so my friend could build it on her machine - it is ?found here (should any of you have the time to take a peek at how I built dillo) : http://totally-out-of-ideas.blogspot.com/2010/12/how-to-build-dillo-on-open… Anyway, I don't want to take up too much of your time on something that I have most likely done incorrectly in the build process. ?I will keep fiddling with it, to see what I can figure out on my own. Rob

Dec. 28, 2010

FLTK 1.3.0 RC 1 released!

by obeythepenguin＠gmail.com

Getting off-topic, I know, but since this is quite interesting... On Tue, 28 Dec 2010 10:43:08 -0500, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > I don't develop nor have a Windows machine, but have heard of > DLL hell (in the same sense as RPM hell ;). Having developed extensively for both -- at one point I was rolling my own Linux distribution -- I can say quite confidently that Linux/Unix has it worse. On the technical side, there's system-wide shared libraries and soname versioning; if the major version changes, everything linked to the library must be recompiled. To compound that, there's the larger development community's general disregard for backwards compatibility. The worst changes I had to make for Dillo-Win32 were patching two or three lines of FLTK-2.0, to support Windows 95. Even then, it was trivial to run a brand-new program on a fifteen-year-old operating system. (On a related note, it's nice that I can still use my nineteen-year-old copy of WordPerfect 5.1. When I ran Linux, I was lucky if I could run something I'd compiled just a year or two before.) > Anyway, the point seems clear to me. In the very old days, with > an Atari 800XL (or C64), developers had a great time. Binaries, > and even HW tricks were portable! > > These days, as you point out, it's very hard to acieve binary > compatibility with GNU/Linux (HW is different, distros are > different, libraries are different). If the problem was left to > the user, no progress could be made (most don't know what is to > compile, and shouldn't need IMHO). This is mainly solved by the > distro-packaged-SW, which users feel comfortable with. That's the > reason why it's so important for us to be back on this kind of > repositories. Windows achieves its binary compatibility largely because every Windows operating system is in the control of one vendor. If anything, the Linux distribution system is worse, because it places control of *applications* in the hands of the OS vendor as well. What I love most about Windows development is the ease of distribution: I just put the file online, and any user can download and run it without so much as a ./configure or even a chmod. No complication, and *no middleman*. I'm not disagreeing with you, by the way, just pointing out that the distribution system is badly flawed and unfriendly from both a user's and a developer's perspective. ~Benjamin

Dec. 28, 2010

FLTK 1.3.0 RC 1 released!

by jcid＠dillo.org

On Mon, Dec 27, 2010 at 04:41:04PM -0500, Benjamin Johnson wrote: > On Mon, 27 Dec 2010 15:38:55 -0500, Jorge Arellano Cid > <jcid(a)dillo.org> wrote: > > > Mainly GNU/Linux flavours. > > > > Most of them have a policy of not packing unreleased libraries > >(quite understandable if you ask me). FLTK-2.0 was never released > >so, as a most unfortunate side effect, we were left out of the > >repositories. > > That makes sense, though then again I've seen a lot of "released" > code in distributions much worse than FLTK-2.0... > > One thing I like about Windows development is that, with > comparatively little effort, you can produce a single executable > that runs on any Windows system. Binary compatibility isn't > possible to nearly that extent on Linux/Unix -- the software, even > the culture makes it limited and extremely difficult at best. Part > of the reason I stopped Unix development, but I digress. I know you > probably see things a bit differently. I don't develop nor have a Windows machine, but have heard of DLL hell (in the same sense as RPM hell ;). Anyway, the point seems clear to me. In the very old days, with an Atari 800XL (or C64), developers had a great time. Binaries, and even HW tricks were portable! These days, as you point out, it's very hard to acieve binary compatibility with GNU/Linux (HW is different, distros are different, libraries are different). If the problem was left to the user, no progress could be made (most don't know what is to compile, and shouldn't need IMHO). This is mainly solved by the distro-packaged-SW, which users feel comfortable with. That's the reason why it's so important for us to be back on this kind of repositories. -- Cheers Jorge.-

Dec. 28, 2010