- Dillo-dev - lists.mailman3.com

[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

1.3 port status

by Hole.destructor＠gmx.de

Dear Dillo developers. > - Twelve years and three toolkits later, there's still no support > for such basic functionality as floating elements (HTML "align=" or > CSS "float:"). See my other two points. If you allow, I would like to make a constructive proposal at this point. There is an interesting Object Orientated Design Pattern called `Bridge', which is intended to separate an abstraction from the implementation. This is especially convenient if one wants to support more than one toolkit or the toolkit changes frequently. (I think one is not forced to use C++ for this purpose. It should be possible to use pure C and select the concrete implementation at compile time.) 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). For examples see: http://en.wikipedia.org/wiki/Bridge_pattern and Gamma, E, Helm, R, Johnson, R, Vlissides, J: Design Patterns, page 151. Addison-Wesley, 1995 Kind regards, Alexander Voigt

Jan. 26, 2011

1.3 port status

by obeythepenguin＠gmail.com

On Wed, 26 Jan 2011 01:42:38 -0500, corvid <corvid(a)lavabit.com> wrote: > The hope is that someone (with any luck, not me) will > learn enough FLTK 1.3 to figure out how to make it nice. I'm sorry, but everything about that sentence makes me cringe. Not meaning this to attack anyone personally, but here's how I'd read the situation as an outsider: - Project leadership wants to switch toolkits, not for the first time. This takes time away from "real" development work (new features, bugfixes, documentation...), and suggests poor planning and indecisiveness. - The current developers aren't familiar with the new toolkit, and suggest -- seriously or otherwise -- they aren't particularly interested in learning it. This takes even more time away from real development, potentially results in buggier, lower quality software, and suggests all sorts of other things besides. - Twelve years and three toolkits later, there's still no support for such basic functionality as floating elements (HTML "align=" or CSS "float:"). See my other two points. I really like Dillo, and I really enjoy hacking on it (both for the code and the great development team). But the whole toolkit situation is throwing up all sorts of red flags, so I hope you can forgive me for voicing a few concerns. ~Benjamin

Jan. 26, 2011