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

Test case for a possible fltk1.3 bug

by Johannes.Hofmann＠gmx.de

On Mon, Mar 21, 2011 at 08:20:07PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote: > > Hi there, > > > > Please help me with this one. > > > > Attached goes a small program that shows what may be a bug in > > fltk-1.3: > > > > * resize the window back and forth and both "Group 1" and > > "Group 2" keep their heights. OK here. > > * With a small window, hide "Group 2" and resize to a big > > window, then show "Group 2". It grew while hidden!? > > > > > > My doubts are: > > > > Is this intended or a bug? > > If not a bug, how is the desired behaviour suppossed to be > > implemented? > > > > > > I know an ugly way to workaround it (used with the findbar), > > but, if it's a bug, I'd prefer to have it fixed, and to keep > > the code clean. > > > > What do you think? > > Your test program shows even weirder behaviour with dwm here. > Initially the buttons are not visible and then scale in strange > ways. > I think this is because dwm is resizing the window as it is created. > > I suggest we don't use Fl_Pack and make our own solution. I will try > to get something running. Please check the attached modified version of your test program. Does the CustPack class solve your problem? Cheers, Johannes

March 21, 2011

Test case for a possible fltk1.3 bug

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote: > Hi there, > > Please help me with this one. > > Attached goes a small program that shows what may be a bug in > fltk-1.3: > > * resize the window back and forth and both "Group 1" and > "Group 2" keep their heights. OK here. > * With a small window, hide "Group 2" and resize to a big > window, then show "Group 2". It grew while hidden!? > > > My doubts are: > > Is this intended or a bug? > If not a bug, how is the desired behaviour suppossed to be > implemented? > > > I know an ugly way to workaround it (used with the findbar), > but, if it's a bug, I'd prefer to have it fixed, and to keep > the code clean. > > What do you think? Your test program shows even weirder behaviour with dwm here. Initially the buttons are not visible and then scale in strange ways. I think this is because dwm is resizing the window as it is created. I suggest we don't use Fl_Pack and make our own solution. I will try to get something running. Cheers, Johannes

March 21, 2011

Main Dillo HG repository

by jcid＠dillo.org

On Sat, Mar 19, 2011 at 07:44:26PM +0100, Johannes Hofmann wrote: > On Sat, Mar 19, 2011 at 01:11:22PM +0000, Jeremy Henty wrote: > > > > Has this been fixed? I have not been pulling from it because I didn't > > want the FLTK-1.3 code to land on me. > > No not yet. > BTW, you can always check with "hg incoming" what you would > get on a pull. I asked Andreas to fix it again (I messed with it twice) and now it's fixed. Thanks to him. -- Cheers Jorge.-

March 21, 2011

[bug]: '<META HTTP-EQUIV="Expires" CONTENT="-1">' => endless calls to Nav_open_url()

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > I got the attached bit of HTML from a broken RSS feed and it > > causes Dillo to thrash, endlessly calling Nav_open_url(). [...] > > To me, it looks like the refresh is responsible. Yes, you're right. (I don't know how I convinced myself otherwise - I was probably editing one copy of the file and testing another - <facepalm/>.) > Probably reads the 0.1 as 0 and does the same bad thing we usually > get when we have 0 and don't have a URL argument sending us > somewhere else... So the bug is that Html_tag_open_meta() does not check that it has found a URL before doing the redirect? Does the attached patch look sensible? (The patch is a little messy, but all it does is wrap the redirect code in a "if (*content) { ... }".) Regards, Jeremy Henty

March 21, 2011

Main Dillo HG repository

by onepoint＠starurchin.org

Johannes Hofmann wrote: > On Sat, Mar 19, 2011 at 01:11:22PM +0000, Jeremy Henty wrote: > > > > Has this been fixed? I have not been pulling from it because I > > didn't want the FLTK-1.3 code to land on me. > > No not yet. BTW, you can always check with "hg incoming" what you > would get on a pull. OK, thanks for the tip! I'll keep checking. Jeremy

March 21, 2011

[bug]: '<META HTTP-EQUIV="Expires" CONTENT="-1">' => endless calls to Nav_open_url()

by corvid＠lavabit.com

Jeremy wrote: > I got the attached bit of HTML from a broken RSS feed and it causes > Dillo to thrash, endlessly calling Nav_open_url(). It is the > 'HTTP-EQUIV="Expires"' header that is responsible. Any ideas how to > fix this? I am afraid this bit of the code makes my head spin so some > guidance would be a big help. To me, it looks like the refresh is responsible. Probably reads the 0.1 as 0 and does the same bad thing we usually get when we have 0 and don't have a URL argument sending us somewhere else...

March 19, 2011

[bug]: '<META HTTP-EQUIV="Expires" CONTENT="-1">' => endless calls to Nav_open_url()

by onepoint＠starurchin.org

I got the attached bit of HTML from a broken RSS feed and it causes Dillo to thrash, endlessly calling Nav_open_url(). It is the 'HTTP-EQUIV="Expires"' header that is responsible. Any ideas how to fix this? I am afraid this bit of the code makes my head spin so some guidance would be a big help. Regards, Jeremy Henty

March 19, 2011

Main Dillo HG repository

by Johannes.Hofmann＠gmx.de

On Sat, Mar 19, 2011 at 01:11:22PM +0000, Jeremy Henty wrote: > > Has this been fixed? I have not been pulling from it because I didn't > want the FLTK-1.3 code to land on me. No not yet. BTW, you can always check with "hg incoming" what you would get on a pull. Cheers, Johannes

March 19, 2011

Main Dillo HG repository

by onepoint＠starurchin.org

Has this been fixed? I have not been pulling from it because I didn't want the FLTK-1.3 code to land on me. Regards, Jeremy Henty

March 19, 2011

fltk1.3 port

by rogerx.oss＠gmail.com

>> > >> Just finally got around to creating a fltk-1.3-r9999.ebuild (SVN version) for >> > >> Gentoo and, pulled/built dillo_fltk-1.3_port. >> > >> >> > >> Tabs look way much nicer now. However, if the bookmarks (dpi:/bm/) rolls-off the >> > >> screen because the user has a long list of bookmarks, scrolling to the next >> > >> page does not work using the scrollbar. >> > >> >> > >> As such, I need to manually resize the window larger then my screen to see & use the >> > >> bookmarks listed off-screen. >> > > >> > > It works perfectly here... >> > >> > Are you using a recently pulled fltk-1.3 svn? >> >> r8514 >> >> but it has worked well since much before r8411 (for months) >> >> > ... I'm betting, this is likely a fltk bug. >> > >> > I should also mention I'm using DWM. :-/ >> >> AFAIR, Johannes uses DWM... > >Right, but it works fine for me. >Roger, do you try to scroll by clicking and dragging the scrollbar >with the mouse or do you use PageDown or Space keys? >For the latter to work I also need to first click the main area to >get focus. Yes, just tried using pgdown/pgup as well as cursor keys and Dillo FLTK-1.3 SVN only scrolls so far to the bottom of the list, while not showing my last bookmark in the list. This looks like a SVN bug to me as this is the first I've seen this too. Also, tabs are not opening in the background as I previously configured. (SVN bug here or current dillo_port-1.3 bug?)... and Dillo > File > Exit displays the "Close all tabs too?" question dialog behind the browser. This later issue sounds more like fltk-1.3 svn. (I just hope the fltk team starts pushing for releases sometime soon vs. never like 2.0!)

March 18, 2011