- Dillo-dev - lists.mailman3.com

1.3 port status

by corvid＠lavabit.com

The fltk-1.3 port is decently usable now if you take http://hg.dillo.org/dillo_port1.3/ and apply my quick hacky UI patch http://www.dillo.org/test/1.3_ui_hardcoded.patch (Anyone want to write a proper one? :) I see that it's segfaulting when leaving pages with image inputs because of something to do with complexbutton, but...decently usable, certainly.

Jan. 22, 2011

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

by rogerx.oss＠gmail.com

>>At this point I'm half-tempted to throw together an API wrapper myself, >>just so we can have something and save ourselves the trouble of rewriting >>Dillo (again). > >Ditto. I've tinkering around just trying to compile Dillo against fltk-1.3 >here on Gentoo for kicks. Got a running bug here with not being able to enter >keyboard text within fields after switching virtual desktop in DWM (aka tags). Changed the following to use fltk(1-3) libs instead of fltk-2. File: configure.in dnl ---------------------- dnl Test for FLTK library dnl ---------------------- dnl dnl For debugging and to be user friendly AC_MSG_CHECKING([FLTK2]) if sh -c "fltk-config --version" >/dev/null 2>&1 then AC_MSG_RESULT(yes) LIBFLTK_CXXFLAGS=`fltk-config --cxxflags` LIBFLTK_CFLAGS=`fltk-config --cflags` LIBFLTK_LIBS=`fltk-config --ldflags` else AC_MSG_RESULT(no) AC_MSG_ERROR(FLTK2 must be installed!) fi ./autogen && ./configure && make Resulted in a large number of function changes. (aka underfined reference errors) Now I can see why you're dragging your feet on just creating a CVS/SVN repository for fltk-1.3! -- Roger http://rogerx.freeshell.org/

Jan. 18, 2011

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

by rogerx.oss＠gmail.com

> On Mon, Jan 17, 2011 at 10:21:18AM -0500, Benjamin Johnson wrote: >On Mon, 17 Jan 2011 09:32:09 -0500, Jorge Arellano Cid <jcid(a)dillo.org> >wrote: > >> Point taken. >> >> I'll get in contact with them. >> >> The background is: they've changed plans several times. We got >> in very close contact before going with F2, and they said it was >> to be released real soon (as now with F1.3 and F3). Five years >> later F2 is dead and we're out of distros. >> >> At some point they reached consensus and decided to push F1.3 >> forward, and it's being moving at good pace. Hopefully with a >> release in this quarter. >> >> I agree that having F3 with F2's API would be the best. The >> doubt is when will this happen if ever. Although I'm just a bystander concerning Dillo (my favorite all time browser), I agree. The way they're wording is published on the FLTK website concerning F3, it won't ever likely happen (unless things really take off with F1.3.) >At this point I'm half-tempted to throw together an API wrapper myself, >just so we can have something and save ourselves the trouble of rewriting >Dillo (again). Ditto. I've tinkering around just trying to compile Dillo against fltk-1.3 here on Gentoo for kicks. Got a running bug here with not being able to enter keyboard text within fields after switching virtual desktop in DWM (aka tags). >As an aside, I wish just one of the major toolkits would get its act >together; we all know about GTK+, and I'm still using Qt 3 because 4.x is >such a mess. It's sad when coding directly against native APIs -- Win32, >Cocoa, pure Xlib -- is almost the more attractive option. Ditto. FLTK has a great idea, but seems to be low on man power. Qt just makes me ill to be stomach -- to Qt for me. Don't care about flowers, just gimme something to clickity-click on! -- Roger http://rogerx.freeshell.org/

Jan. 18, 2011

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

by onepoint＠starurchin.org

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

Jan. 17, 2011

Q: offical bug report address?

by onepoint＠starurchin.org

I wrote: > corvid wrote: > > Jeremy wrote: > > > AC_INIT takes an optional URL for bug reports. Should we use > > > it, and what URL would be appropriate? > > > > Does anything happen beyond PACKAGE_BUGREPORT getting defined, and > > developers getting to put it in MSG()s if they so desire? > > It adds a line "Report bugs to <...>" at the end of the output of > "./configure --help". > > I agree it's not urgent but I tend to prefer following the > conventions unless there is good reason not to. Any other opinions from the devs? Regards, Jeremy Henty

Jan. 17, 2011

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

by obeythepenguin＠gmail.com

On Mon, 17 Jan 2011 09:32:09 -0500, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Point taken. > > I'll get in contact with them. > > The background is: they've changed plans several times. We got > in very close contact before going with F2, and they said it was > to be released real soon (as now with F1.3 and F3). Five years > later F2 is dead and we're out of distros. > > At some point they reached consensus and decided to push F1.3 > forward, and it's being moving at good pace. Hopefully with a > release in this quarter. > > I agree that having F3 with F2's API would be the best. The > doubt is when will this happen if ever. At this point I'm half-tempted to throw together an API wrapper myself, just so we can have something and save ourselves the trouble of rewriting Dillo (again). As an aside, I wish just one of the major toolkits would get its act together; we all know about GTK+, and I'm still using Qt 3 because 4.x is such a mess. It's sad when coding directly against native APIs -- Win32, Cocoa, pure Xlib -- is almost the more attractive option. ~Benjamin

Jan. 17, 2011

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

by jcid＠dillo.org

On Sun, Jan 16, 2011 at 10:25:07PM +0000, Karsten Witzman wrote: > While this mail is meant as a follow-up to > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-January/007943.html, > I'd first like to tell you that I'm neither a Dillo nor an FLTK > developer, but reading the mails from the archive in this discussion > thread got me the impression that Dillo uses FLTK 2.0 internally and > that it is intended to switch to 1.3. > > I wonder if this would actually make sense with respect to an > anticipated FLTK 3.0, which, following links from the FLTK project > website (http://www.fltk.org/) to the FLTK 3 proposal > (http://www.fltk.org/articles.php?L1031) and from there to the more > detailed explanations' (http://www.fltk.org/links.php?LC+P402+Q) > section 2 (http://www.fltk.org/links.php?V404+Q) is described as > build on the FLTK 2 API with FLTK 1.3 interna for stability in the > last paragraph of the aforementioned text section. > > I'd like to restate that I have no idea in which ways Dillo and FLTK > are actually connected, but it looks to me like it would be a good > idea for Dillo developers to check what's planned with FLTK 3 and > perhaps get in contact with FLTK developers on this before switching > Dillo code based on FLTK 2 to FLTK 1.3, if the only reason for that is > to base Dillo code on an API that will see support in the future. Point taken. I'll get in contact with them. The background is: they've changed plans several times. We got in very close contact before going with F2, and they said it was to be released real soon (as now with F1.3 and F3). Five years later F2 is dead and we're out of distros. At some point they reached consensus and decided to push F1.3 forward, and it's being moving at good pace. Hopefully with a release in this quarter. I agree that having F3 with F2's API would be the best. The doubt is when will this happen if ever. -- Cheers Jorge.-

Jan. 17, 2011

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

by hulladiho＠googlemail.com

While this mail is meant as a follow-up to http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-January/007943.html, I'd first like to tell you that I'm neither a Dillo nor an FLTK developer, but reading the mails from the archive in this discussion thread got me the impression that Dillo uses FLTK 2.0 internally and that it is intended to switch to 1.3. I wonder if this would actually make sense with respect to an anticipated FLTK 3.0, which, following links from the FLTK project website (http://www.fltk.org/) to the FLTK 3 proposal (http://www.fltk.org/articles.php?L1031) and from there to the more detailed explanations' (http://www.fltk.org/links.php?LC+P402+Q) section 2 (http://www.fltk.org/links.php?V404+Q) is described as build on the FLTK 2 API with FLTK 1.3 interna for stability in the last paragraph of the aforementioned text section. I'd like to restate that I have no idea in which ways Dillo and FLTK are actually connected, but it looks to me like it would be a good idea for Dillo developers to check what's planned with FLTK 3 and perhaps get in contact with FLTK developers on this before switching Dillo code based on FLTK 2 to FLTK 1.3, if the only reason for that is to base Dillo code on an API that will see support in the future. Just my two cents, I hope this mail is appropriately placed here, otherwise apologies, for this is my first mail to any mailing list ever and I'm still quite uncertain about how referring to messages in the archived thread actually works. P.S.: The preceding sentence is not entirely true, as I have already tried yesterday to send the above text to the mailing list. As it didn't appear in the archive until now, I've subscribed to the list as a debugging measure and try it again, in case prior subscription to the list is required to send messages to it. In that case, I'd also like to suggest that such a requirement be communicated at the information page (http://www.dillo.org/MListinfo.html)

Jan. 16, 2011

Q: offical bug report address?

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > AC_INIT takes an optional URL for bug reports. Should we use it, > > and what URL would be appropriate? > > Does anything happen beyond PACKAGE_BUGREPORT getting defined, and > developers getting to put it in MSG()s if they so desire? It adds a line "Report bugs to <...>" at the end of the output of "./configure --help". I agree it's not urgent but I tend to prefer following the conventions unless there is good reason not to. Regards, Jeremy Henty

Jan. 15, 2011

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

by corvid＠lavabit.com

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.

Jan. 14, 2011