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@waltdnes.org>
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/
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@waltdnes.org>
On Sat, Aug 06, 2011 at 07:02:12PM -0400, Walter Dnes wrote:
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".
Good luck. lol Me and another guy were working fltk-1.3 on bugs.gentoo.com and the bug maintainer(s) didn't seem to want to mess with the slotting, etc. As such, it's slotted along side fltk-1, which sucks if you need fltk-1.1.10 (ie. app-text/htmldoc requires fltk-1 and not fltk-1.3) (Sorry for hijacking the thread.) -- Roger http://rogerx.freeshell.org/
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.)
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@waltdnes.org>
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)
participants (3)
-
corvid＠lavabit.com -
rogerx.oss＠gmail.com -
waltdnes＠waltdnes.org