January 2011 - Dillo-dev - lists.mailman3.com

1.3 port status

by corvid＠lavabit.com

It should be less crashy now when leaving pages with form widgets in general. It still doesn't like complexbutton, and you can get it to segfault if you play with tabs enough, which might simply be because my UI patch doesn't take the UI's y() value into account (nonzero once the tabs shift it down).

Jan. 23, 2011

1.3 port status

by corvid＠lavabit.com

I wrote: > Fredrik wrote: > > I've got some errors trying to compile. Is it my fault? > > For the moment, changing the > #if USE_X11 > to > #if 0 > in src/xembed.cc should make that go away. xembed.cc should compile now.

Jan. 23, 2011

1.3 port status

by corvid＠lavabit.com

Fredrik wrote: > I've got some errors trying to compile. Is it my fault? For the moment, changing the #if USE_X11 to #if 0 in src/xembed.cc should make that go away.

Jan. 22, 2011

1.3 port status

by iveqy＠iveqy.com

On Sat, Jan 22, 2011 at 03:59:37AM +0000, corvid wrote: > 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. > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev g++ -DHAVE_CONFIG_H -I. -I.. -I.. -DDILLO_SYSCONF='"/usr/local/etc/dillo/"' -DDILLO_DOCDIR='"/usr/local/share/doc/dillo/"' -I/usr/local/include -I/usr/include/libpng12 -I/usr/local/include -DUSE_X11 -D_THREAD_SAFE -D_REENTRANT -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT xembed.o -MD -MP -MF .deps/xembed.Tpo -c -o xembed.o xembed.cc xembed.cc: In member function ?void Xembed::setXembedInfo(long unsigned int)?: xembed.cc:43: error: ?fltk? has not been declared xembed.cc:48: error: ?fltk? has not been declared xembed.cc: In member function ?void Xembed::sendXembedEvent(uint32_t)?: xembed.cc:62: error: ?fltk? has not been declared xembed.cc:64: error: ?fltk? has not been declared xembed.cc:67: error: ?fltk? has not been declared xembed.cc:68: error: ?fltk? has not been declared xembed.cc: In function ?int event_handler(int, Fl_Window*)?: xembed.cc:80: error: ?fltk? has not been declared xembed.cc:82: error: ?fltk? has not been declared xembed.cc:83: error: ?fltk? has not been declared xembed.cc:84: error: ?fltk? has not been declared xembed.cc: In member function ?void Xembed::create()?: xembed.cc:108: error: ?fltk? has not been declared xembed.cc: In member function ?void Xembed::createInternal(uint32_t)?: xembed.cc:113: error: ?fltk? has not been declared xembed.cc:135: error: ?fltk? has not been declared xembed.cc:136: error: ?fltk? has not been declared xembed.cc:140: error: ?fltk? has not been declared xembed.cc:142: error: ?fltk? has not been declared make[3]: *** [xembed.o] Fel 1 make[3]: Leaving directory `/home/iveqy/slask/dillo_port1.3/src' make[2]: *** [all-recursive] Fel 1 make[2]: Leaving directory `/home/iveqy/slask/dillo_port1.3/src' make[1]: *** [all-recursive] Fel 1 make[1]: Leaving directory `/home/iveqy/slask/dillo_port1.3' make: *** [all] Fel 2 I've got some errors trying to compile. Is it my fault? -- Med v?nliga h?lsningar Fredrik Gustafsson tel: 0733-608274 e-post: iveqy(a)iveqy.com

Jan. 22, 2011

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