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

compile error

by corvid＠lavabit.com

T wrote: > While trying make on the latest version of dillo3, I get the following: > > g++ -I/usr/include/libpng12 -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions? -L/usr/local/lib -o dillo dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -L/usr/lib64 -lpng12 -lpng12 -lfltk -lz -lpthread > /usr/bin/ld: xembed.o: undefined reference to symbol 'XSync' > /usr/bin/ld: note: 'XSync' is defined in DSO /usr/lib64/libX11.so.6 so try adding it to the linker command line > /usr/lib64/libX11.so.6: could not read symbols: Invalid operation > collect2: ld returned 1 exit status > make[3]: *** [dillo] Error 1 > > > How does one fix this?? When FLTK is being configured, does it complain about not finding X or something?

Aug. 7, 2011

Geometry handling+reporting problems under ICEWM

by waltdnes＠waltdnes.org

> FYI: fltk-1.3 is already in Gentoo Portage. You can emerge it after doing: > > $ echo "=x11-libs/fltk-1.3*" >> /etc/portage/package.keywords > $ echo "=x11-libs/fltk-2*" >> /etc/portage/package.mask > > However, sounds like users are still just pulling fltk hg because the in tree > builds won't play nicely with fltk-2 installed. (... stupid fltk versioning > screwup.) I blew away most of /home/waltdnes/local, keyworded fltk-1.3* as ~amd64 and masked fltk-2* as suggested, rebuilt dillo, and got the same geometry (mis)behaviour. Another message here suggests that it's a known fltk problem. Gentoo users will have to keep masking fltk-3 manually, until dillo-3 is ready to go stable. At that time, we'll have to ask the maintainers of the dillo ebuild and the fltk ebuild to *SIMULTANEOUSLY*... - make a stable dillo3 ebuild - mask fltk-3 That'll be "fun". -- Walter Dnes <waltdnes(a)waltdnes.org>

Aug. 7, 2011

Geometry handling+reporting problems under ICEWM

by corvid＠lavabit.com

Walter wrote: > On Sat, Aug 06, 2011 at 10:17:57PM +0000, corvid wrote > > > FLTK seems to have problems with geometry. If you go to the FLTK test/ > > directory and play with them, they misbehave similarly. > > (I use fvwm, incidentally.) > > Has a bug report been filed with upstream fltk developers? Umm... not that I'm aware of. You can look through http://fltk.org/roadmap.php (all of those 1.4 bugs were moved there to get them out of the way for the 1.3.0 release, but they're still really 1.3 bugs)

Aug. 7, 2011

fltk widget schemes

by corvid＠lavabit.com

Do you think any good could come from playing around with the different widget schemes? "none" is the default, and "plastic" and "gtk+" are the other choices. e.g.: diff -r 6fe817711ef4 src/dillo.cc --- a/src/dillo.cc Fri Aug 05 21:39:27 2011 -0400 +++ b/src/dillo.cc Sat Aug 06 22:34:28 2011 +0000 @@ -379,6 +379,8 @@ // only way to set the // default font in fltk1.3 + Fl::scheme("plastic"); + // Create a new UI/bw pair BrowserWindow *bw = a_UIcmd_browser_window_new(0, 0, xid, NULL);

Aug. 7, 2011

Geometry handling+reporting problems under ICEWM

by waltdnes＠waltdnes.org

On Sat, Aug 06, 2011 at 10:17:57PM +0000, corvid wrote > FLTK seems to have problems with geometry. If you go to the FLTK test/ > directory and play with them, they misbehave similarly. > (I use fvwm, incidentally.) Has a bug report been filed with upstream fltk developers? -- Walter Dnes <waltdnes(a)waltdnes.org>

Aug. 7, 2011

Geometry handling+reporting problems under ICEWM

by corvid＠lavabit.com

Walter wrote: > I don't know if this is a problem with ICEWM on my machine or dillo. > I've only seen it with dillo, so I assume that's the source. I'm > running Gentoo Linux (pure 64-bit mode) on an Intel i3, with ICEWM as > the WM. I have a 1920x1080 LCD monitor. FLTK 1.3 and dillo3 are under > /home/waltdnes/local, and PATH includes /home/waltdnes/local/bin I did > an "hg pull" last night, so this should be a recent version. > > In ~/.dillorc, I have... > geometry=950x1050+960+0 > but pressing {ALT}{LEFT-MOUSE} on the dillo window frame reports a > geometry of 850x949+956-24 > > Looking at the display, I see two separate problems... > > 1) Positioning > ============== > The URL is flush against the top of the display, and the title bar > is off the top of the display. Changing ~/.dillorc to... > geometry=950x1050+960+24 > results in the title bar being fully visible, like I expect. I don't > know whether it's a fixed offset of 24, or if dillo is ignoring the > height of the WM window decoration when positioning at startup. > > 2) Reporting size > ================= > When I click {ALT}{LEFT-MOUSE} on the frame, the reported size values > are too small. I specify size 950x1050 in the .dillorc geometry setting > but the reported size is 850x949. The *ACTUAL* size of the dillo window > appears to be correct, but the *REPORTED* size is wrong. I have an > Opera window open that's 950x1050, and the dillo window overlays it > almost exactly. I maximized the dillo window using the WM maximize > button on the upper right. {ALT}{LEFT-MOUSE} on the dillo window frame, > reports 1820x959-4-4 but my display is 1920x1080. The reported geometry > seems to have the x-coordinate consistently 100 pixels too small. The > y-coordinate is also too small, but I'm not sure of the exact amount, or > whether it's constant. My guess is that it's 101 pixels too small, > after counting the -24 offset. FLTK seems to have problems with geometry. If you go to the FLTK test/ directory and play with them, they misbehave similarly. (I use fvwm, incidentally.)

Aug. 7, 2011

Geometry handling+reporting problems under ICEWM

by rogerx.oss＠gmail.com

> On Sat, Aug 06, 2011 at 04:45:46PM -0400, Walter Dnes wrote: > I don't know if this is a problem with ICEWM on my machine or dillo. >I've only seen it with dillo, so I assume that's the source. I'm >running Gentoo Linux (pure 64-bit mode) on an Intel i3, with ICEWM as >the WM. I have a 1920x1080 LCD monitor. FLTK 1.3 and dillo3 are under >/home/waltdnes/local, and PATH includes /home/waltdnes/local/bin I did >an "hg pull" last night, so this should be a recent version. FYI: fltk-1.3 is already in Gentoo Portage. You can emerge it after doing: $ echo "=x11-libs/fltk-1.3*" >> /etc/portage/package.keywords $ echo "=x11-libs/fltk-2*" >> /etc/portage/package.mask However, sounds like users are still just pulling fltk hg because the in tree builds won't play nicely with fltk-2 installed. (... stupid fltk versioning screwup.) -- Roger http://rogerx.freeshell.org/

Aug. 6, 2011

compile error

by itsme_410＠yahoo.com

While trying make on the latest version of dillo3, I get the following: g++ -I/usr/include/libpng12 -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions? -L/usr/local/lib -o dillo dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -L/usr/lib64 -lpng12 -lpng12 -lfltk -lz -lpthread /usr/bin/ld: xembed.o: undefined reference to symbol 'XSync' /usr/bin/ld: note: 'XSync' is defined in DSO /usr/lib64/libX11.so.6 so try adding it to the linker command line /usr/lib64/libX11.so.6: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[3]: *** [dillo] Error 1 How does one fix this?? Best! T

Aug. 6, 2011

Geometry handling+reporting problems under ICEWM

by waltdnes＠waltdnes.org

I don't know if this is a problem with ICEWM on my machine or dillo. I've only seen it with dillo, so I assume that's the source. I'm running Gentoo Linux (pure 64-bit mode) on an Intel i3, with ICEWM as the WM. I have a 1920x1080 LCD monitor. FLTK 1.3 and dillo3 are under /home/waltdnes/local, and PATH includes /home/waltdnes/local/bin I did an "hg pull" last night, so this should be a recent version. In ~/.dillorc, I have... geometry=950x1050+960+0 but pressing {ALT}{LEFT-MOUSE} on the dillo window frame reports a geometry of 850x949+956-24 Looking at the display, I see two separate problems... 1) Positioning ============== The URL is flush against the top of the display, and the title bar is off the top of the display. Changing ~/.dillorc to... geometry=950x1050+960+24 results in the title bar being fully visible, like I expect. I don't know whether it's a fixed offset of 24, or if dillo is ignoring the height of the WM window decoration when positioning at startup. 2) Reporting size ================= When I click {ALT}{LEFT-MOUSE} on the frame, the reported size values are too small. I specify size 950x1050 in the .dillorc geometry setting but the reported size is 850x949. The *ACTUAL* size of the dillo window appears to be correct, but the *REPORTED* size is wrong. I have an Opera window open that's 950x1050, and the dillo window overlays it almost exactly. I maximized the dillo window using the WM maximize button on the upper right. {ALT}{LEFT-MOUSE} on the dillo window frame, reports 1820x959-4-4 but my display is 1920x1080. The reported geometry seems to have the x-coordinate consistently 100 pixels too small. The y-coordinate is also too small, but I'm not sure of the exact amount, or whether it's constant. My guess is that it's 101 pixels too small, after counting the -24 offset. -- Walter Dnes <waltdnes(a)waltdnes.org>

Aug. 6, 2011

focus stays on address bar on dillo-3.0 pre

by waltdnes＠waltdnes.org

On Sat, Aug 06, 2011 at 06:44:32PM +0300, Rogut??s Sparnuotos wrote > Jorge Arellano Cid (2011-08-06 11:17): > > > > I've found use for both, but now tend more to focusing the main area. > > > > Quick poll: what do you prefer? > > I wonder who would want to type another URL right after loading the first > one? > > I think that it is more convenient when focus is moved to content. I also want focus on main. I agree with the parent post that if you've just typed/selected a URL, you wouldn't normally want to input a new one. -- Walter Dnes <waltdnes(a)waltdnes.org>

Aug. 6, 2011