- Dillo-dev - lists.mailman3.com

patch: configure rm libpng version tests

by weigelt＠metux.de

* corvid <corvid(a)lavabit.com> schrieb: > + PNG_CONFIG=`which libpng-config` > fi Why not just using pkg-config ? (which would be _much_ more distmaintainer/packager-friendly) PKG_CHECK_MODULE([...]) 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. 29, 2011

Final release of FLTK 2.0 Dillo

by itsme_410＠yahoo.com

I wonder what a projected timeline for the 1.3 release will be.... T --- On Tue, 1/25/11, Alexander Voigt <Hole.destructor(a)gmx.de> wrote: > From: Alexander Voigt <Hole.destructor(a)gmx.de> > Subject: [Dillo-dev] Final release of FLTK 2.0 Dillo > To: "Dillo Mailinglist" <dillo-dev(a)dillo.org> > Date: Tuesday, January 25, 2011, 3:21 AM > Dear Dillo developers, > > since you started porting Dillo to FLTK 1.3, I wonder if > you plan to > do a last release of the current FLTK 2.0 Dillo?? > (This would seem > reasonable to me, since this version works pretty well and > some of us > can't wait so long for the next release. :) > > Many thanks in advance, > Alexander Voigt > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 29, 2011

[patch]: clean up the build and make d_size.h static.

by onepoint＠starurchin.org

Jeremy Henty wrote: > *Bump* Can I push this or are there objections? OK, I think I got enough encouragement to justify a push, so I have. Regards, Jeremy Henty

Jan. 28, 2011

[patch]: clean up the build and make d_size.h static.

by Johannes.Hofmann＠gmx.de

On Mon, Jan 17, 2011 at 08:58:04PM +0000, Jeremy Henty wrote: > corvid wrote: > > Jeremy wrote: > > > corvid wrote: > > > > > > > Found the problem. > > > > > > > > The autoconf 2.66 release announcement > > > > http://lists.gnu.org/archive/html/autotools-announce/2010-07/msg00000.html > > > > includes: > > > > > > > > ** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and > > > > AC_TYPE_INT64_T work again. Regression introduced in 2.65. > > > > > So is this a reason to hold back this patch? > > > > I...don't think so. > > My thinking went: > > 1. It broke harmlessly. > > 2. But maybe it would break seriously for someone else. > > 3. But if we'd made the change before 2.65 came out, would we do > > anything about it, or would we say "Well, that's too bad for > > autoconf-2.65"? No doubt the latter unless we knew of real > > breakage. > > So is it OK to push? Does anyone else have comments? I like the change and we are at autoconf-2.68 now - but I don't feel very competent in this area. Cheers, Johannes

Jan. 27, 2011

[patch]: clean up the build and make d_size.h static.

by onepoint＠starurchin.org

Jeremy Henty wrote: > corvid wrote: > > Jeremy wrote: > > > corvid wrote: > > > > > > > Found the problem. > > > > > > > > The autoconf 2.66 release announcement > > > > http://lists.gnu.org/archive/html/autotools-announce/2010-07/msg00000.html > > > > includes: > > > > > > > > ** The macros AC_TYPE_INT8_T, AC_TYPE_INT16_T, AC_TYPE_INT32_T, and > > > > AC_TYPE_INT64_T work again. Regression introduced in 2.65. > > > > > So is this a reason to hold back this patch? > > > > I...don't think so. > > My thinking went: > > 1. It broke harmlessly. > > 2. But maybe it would break seriously for someone else. > > 3. But if we'd made the change before 2.65 came out, would we do > > anything about it, or would we say "Well, that's too bad for > > autoconf-2.65"? No doubt the latter unless we knew of real > > breakage. > > So is it OK to push? Does anyone else have comments? *Bump* Can I push this or are there objections? Regards, Jeremy Henty

Jan. 27, 2011

1.3 port status

by rogerx.oss＠gmail.com

>On top of that, this "solution" doesn't really solve anything -- it >still takes time away from development, requires developers to learn >the new abstraction layer, and won't make up for functional >incompatibilities/missing features between different toolkits or >versions. ?It sounds like a great idea in theory -- and IIRC, the >Dillo renderer (but not the rest of the interface) is already built on >an abstraction layer -- but in practice it would mostly amount to >needlessly re-inventing the wheel. > >Disclaimer: I'm not one of the core developers, and this is only my >personal view. > >~Benjamin It sounds like your issues would be more effectively resolved if you posted them to the fltk mailing list. Or, the news & blog threads concerning fltk versioning. Although from what they have stated, almost all development has occurred within the fltk-1.3 branch for the past year, still somebody posted concerning pushing further development on fltk-2.0 recently. <sigh> I'm just going with the flow here.

Jan. 27, 2011

1.3 port status

by obeythepenguin＠gmail.com

On 1/26/11, corvid <corvid(a)lavabit.com> wrote: > Benjamin, > > 1) If your boat is sinking, you get into a different boat. All I'm saying is Dillo seems to get into a *lot* of leaky boats. > 2) Man, the idea with Free Software is community and sharing and > common good, and not Corvid-does-everything-himself. I didn't mean that as personal criticism -- I was simply pointing out how the situation might look to an outsider not really active in Dillo development. (I work as a technical editor, so reading too much into things is literally my job.) My point, in short, is that Dillo's already had to switch from one obsolete toolkit, and doing it again doesn't reflect well on the project, however necessary or justified it is. This is the "damned if you do" to everyone else's collective "damned if you don't." But I suppose I've wasted enough words in making my point. ~Benjamin

Jan. 26, 2011

1.3 port status

by corvid＠lavabit.com

Benjamin, 1) If your boat is sinking, you get into a different boat. 2) Man, the idea with Free Software is community and sharing and common good, and not Corvid-does-everything-himself.

Jan. 26, 2011

patch: configure rm libpng version tests

by corvid＠lavabit.com

Jorge wrote: > On Wed, Jan 26, 2011 at 03:49:05AM +0000, corvid wrote: > > [...] > > Is there a good reason not to use whatever libpng-config is linked to? > > I don't know these days, but a few years ago I had to add all > of those tests because of different names of the configure script > and there were distros packing two versions of the library and > using the script name to differentitate among them. > > *Handle with care* Okay, how about rearranging to put libpng-config first to get whatever they prefer, and we can add in backup tests for versions with less... I was going to say 'urgency', but of course we haven't released a version that handles 1.4 yet... (Aside: With eleven years of history now, we seem to run into a lot of "I think a long time ago, we needed that for something" which suggests that we should be a bit obsessive about our documentation. Sometimes you can get a hint from the list archives, but often the pattern is "A release looms, and someone contacts Jorge off-list about whatever problem, and it is quietly patched".)

Jan. 26, 2011

1.3 port status

by obeythepenguin＠gmail.com

Oops, I meant to send this to the list, not just Alexander -- apologies for that. On Wed, Jan 26, 2011 at 9:12 AM, Alexander Voigt <Hole.destructor(a)gmx.de> wrote: > Maybe this is a solution to the upcomming problem(s). ?What one needs > to do is to build an abstraction and an implementor and pack all > toolkit specific things into concrete implementors (i.e. the FLTK 2.0, > or FLTK 1.3 specific things). There's one obvious problem there: the toolkit is *already* an abstraction. ?(FLTK's not strictly an abstraction layer, because it implements its own widget set, but the purpose of any toolkit is to provide some sort of abstraction over the native APIs.) On top of that, this "solution" doesn't really solve anything -- it still takes time away from development, requires developers to learn the new abstraction layer, and won't make up for functional incompatibilities/missing features between different toolkits or versions. ?It sounds like a great idea in theory -- and IIRC, the Dillo renderer (but not the rest of the interface) is already built on an abstraction layer -- but in practice it would mostly amount to needlessly re-inventing the wheel. Disclaimer: I'm not one of the core developers, and this is only my personal view. ~Benjamin

Jan. 26, 2011