- Dillo-dev - lists.mailman3.com

nytimes links and redirection

by corvid＠lavabit.com

I'd been in the habit of letting wget retrieve nytimes links, but today I finally fought with it long enought to learn a few things. - wget works because it remembers cookies while redirecting. I was sure that enabling cookies required a flag, but nope. - If I increase the maximum redirect level in dillo, it gets up to 9 before nytimes relents and figures out that I don't want to give it any cookies and provides me with the page. - If I change the www to www10, it works immediately and doesn't bother with redirection at all.

Sept. 5, 2009

perhaps an iterator bug

by Johannes.Hofmann＠gmx.de

On Thu, Sep 03, 2009 at 01:28:57PM -0400, Jorge Arellano Cid wrote: > On Thu, Sep 03, 2009 at 04:45:29PM +0000, corvid wrote: > > I wrote, back in February: > > > I was trying the new search functionality a bit more > > > and found this (it's also present in my Dec 2008 dillo*). > > > > > > With the page: > > > > > > <table> > > > <tr><td>no close-tr > > > <tr><td>has a close-tr</tr> > > > <tr><td>here's another line</tr> > > > </table> > > > > > > if I search for "rh", it finds one instance of it > > > split between the second and third table rows. > > > > At the time, I didn't recognize what the exact problem was. > > Now it dawns on me that the difference is really that > > line 2's text has whitespace before the next tag, > > and line 3's doesn't. > > > > It would be nice if the iterators thought of cells > > as being separated by whitespace, but I don't know yet > > whether there's a good and simple way to do that... > > A whitespace suffix with width=0 comes to mind... Or perhaps TableIterator() could generate some separators?

Sept. 3, 2009

perhaps an iterator bug

by jcid＠dillo.org

On Thu, Sep 03, 2009 at 04:45:29PM +0000, corvid wrote: > I wrote, back in February: > > I was trying the new search functionality a bit more > > and found this (it's also present in my Dec 2008 dillo*). > > > > With the page: > > > > <table> > > <tr><td>no close-tr > > <tr><td>has a close-tr</tr> > > <tr><td>here's another line</tr> > > </table> > > > > if I search for "rh", it finds one instance of it > > split between the second and third table rows. > > At the time, I didn't recognize what the exact problem was. > Now it dawns on me that the difference is really that > line 2's text has whitespace before the next tag, > and line 3's doesn't. > > It would be nice if the iterators thought of cells > as being separated by whitespace, but I don't know yet > whether there's a good and simple way to do that... A whitespace suffix with width=0 comes to mind... -- Cheers Jorge.-

Sept. 3, 2009

[devidfil@gmail.com: [Dillo-dev] Switch to fltk1.3?]

by jcid＠dillo.org

Hi there, Here comes the rest of the story, and the steps we're taking. On Sun, Aug 30, 2009 at 09:30:39AM -0400, Jorge Arellano Cid wrote: > On Sat, Aug 29, 2009 at 01:06:36PM +0200, Johannes Hofmann wrote: > > Hi Jorge, > > > > do you plan to answer this mail? > > Sorry I've been lost with other activities. > > > My point here is that we should > > stick with fltk2 until there is an official release of fltk1.3. > > Yes. I agree. We went with unreleased FLTK2 and it has caused > lots of problems (despite statical linking). > > > If there are license issues with fltk2 they should be handled > > between debian and the fltk community. Of course we could try to > > help. > > It looks like FLTK2 is quite stalled. Of course we can knock > the door again. Maybe this is also a good time to ask for > fltk1.3's timeline again. The last time, the optimistic release > date was near the middle of 2009. > > > > Date: Sat, 22 Aug 2009 18:40:03 +0200 > > From: Devid Antonio Filoni <devidfil(a)gmail.com> > > Subject: [Dillo-dev] Switch to fltk1.3? > > To: dillo-dev(a)dillo.org > > > > Hi, > > is possible to switch to fltk1.3? I sent a lot of emails to fltk > > developers trying to get the license issue of fltk2 > > (http://www.fltk.org/str.php?L2198+P0+S-2+C0+I0+E0+Qlicense) fixed but > > I still (after months of sent emails) haven't gotten a reply. dillo is > > going to be removed from Debian and Ubuntu repositories because it > > depends on removed packages and the newest dillo release cannot be > > uploaded because fltk2 is not in the repositories and it cannot be > > accepted due to the license issue. Is possible to switch to fltk1.3 or > > to another toolkit please? > > > > Thanks, > > Devid Antonio Filoni > > Hi Devid, > > We plan to switch to fltk1.3 soon. The point is to have a solid > release date to start the port. When we started with fltk2 it was > supposed to be released soon... :P > > I'm writing to the fltk1.3 team. Stay tuned. I wrote to Matthias Melcher and this is what happened: > [On Sep 2, Matthias wrote:] > > OK, here is the history of the license additions which should make things > clearer: > > All initial authors of FLTK (Bill, Mike, myself) had commercial > applications in mind or were actively working on them. GPL was out of > question. LGPL mostly fit Bill's ideas, but it had to be shoe-horned so > that "Nuke", the commercial product of his employer "Digital Domain" would > be satisfied. > > DD'd first problem was that they were afreid the Nuke would be seen as > derived work and hence require the source to be opened (yes, I know, but > that such is lawyer logic). > > The second issue was that DD did not want t have to mention any of that > brand new LGPL licensing stuff (LGPL was pretty much brand new 15 years ago > and highly disputed). > > Thirdly, Mike back then owned his own business, and he wanted to support > FLTK, but avoid similar risks. IIRC he added the ammendments. > > So here is my suggestion: > I will not be able to completely remove the ammendments, but I doubt that > there will be much of a fight if we change some wording. If I read the > artikles right, the May version would be acceptable for FLTK 2. If that is > so, I will push that through with the team. If neither wording works, > please have someone suggest a version in the light of the explanations > above. Devid, you're surely in a better position to judge the legal aspect of using the May version of the license. At least you can ask Debian legal! If that's enough to get FLTK2 packaged, we can push it forward this way. If not, I can talk the problem with the fltk-1.3 development team, try to get a release estimation date and speed up the port to fltk-1.3 accordingly. AFAIU the 1.3 branch has no license issues. I'll be expecting your answer to get back to fltk devs. TIA. -- Cheers Jorge.-

Sept. 3, 2009

whattheinternetknowsaboutyou

by Johannes.Hofmann＠gmx.de

On Wed, Sep 02, 2009 at 08:47:59PM +0000, corvid wrote: > Johannes wrote: > > this http://wtikay.com/docs/details.html is quite interesting. Dillo > > is not vulnerable, but we should keep this in mind when implementing > > background image support. > > Are background images the only way for them to > pull that off? The other way they describe uses Javascript. But it would also be possible to make links visible/invisible depending on whether the user has visited a site (see below). From what the user then clicks one might get a clue about his browser history. But this is not automatic and only one piece of history information per click. Cheers, Johannes <html> <head> <style type="text/css"> body {background-color: white} a {color: white} :visited #bad {color: red} :link #good {color: red} </style> <body> <a href="http://wikileaks.org"><a href="hevisitedwikileaks.html" id="bad">click here</a></a> <br/> <a href="http://wikileaks.org"><a href="heisok.html" id="good">click here</a></a> </body> </html>

Sept. 3, 2009

perhaps an iterator bug

by corvid＠lavabit.com

I wrote, back in February: > I was trying the new search functionality a bit more > and found this (it's also present in my Dec 2008 dillo*). > > With the page: > > <table> > <tr><td>no close-tr > <tr><td>has a close-tr</tr> > <tr><td>here's another line</tr> > </table> > > if I search for "rh", it finds one instance of it > split between the second and third table rows. At the time, I didn't recognize what the exact problem was. Now it dawns on me that the difference is really that line 2's text has whitespace before the next tag, and line 3's doesn't. It would be nice if the iterators thought of cells as being separated by whitespace, but I don't know yet whether there's a good and simple way to do that...

Sept. 3, 2009

whattheinternetknowsaboutyou

by corvid＠lavabit.com

Johannes wrote: > this http://wtikay.com/docs/details.html is quite interesting. Dillo > is not vulnerable, but we should keep this in mind when implementing > background image support. Are background images the only way for them to pull that off?

Sept. 2, 2009

whattheinternetknowsaboutyou

by Johannes.Hofmann＠gmx.de

Hi, this http://wtikay.com/docs/details.html is quite interesting. Dillo is not vulnerable, but we should keep this in mind when implementing background image support. Cheers, Johannes

Sept. 2, 2009

horizontal scrolling while searching

by Johannes.Hofmann＠gmx.de

On Wed, Sep 02, 2009 at 05:02:28PM +0000, corvid wrote: > Johannes wrote: > > corvid, you have just fixed an issue with horizontal scrolling > > during search. > > While testing it I realized, that horizontal scrolling during search > > does not work at all with plain text. Any idea why? > > Actually, I made a patch for that last night (attached). > > getAllocation() determines the boundaries and position > of a Word, and then Iterator's scrollTo() figures out how > to place it. > > But for plain text, the whole line is a Word, so scrollTo > was just positioning the line as a whole and considering its > work done. > > In the patch, I take start and end into account to figure out > what part of the Word we really want to see. > (The current behaviour of showing the whole word is a little > bit nicer for html with "normal"-sized Words, but...) > Cool! Please commit. Cheers, Johannes

Sept. 2, 2009

horizontal scrolling while searching

by corvid＠lavabit.com

Johannes wrote: > corvid, you have just fixed an issue with horizontal scrolling > during search. > While testing it I realized, that horizontal scrolling during search > does not work at all with plain text. Any idea why? Actually, I made a patch for that last night (attached). getAllocation() determines the boundaries and position of a Word, and then Iterator's scrollTo() figures out how to place it. But for plain text, the whole line is a Word, so scrollTo was just positioning the line as a whole and considering its work done. In the patch, I take start and end into account to figure out what part of the Word we really want to see. (The current behaviour of showing the whole word is a little bit nicer for html with "normal"-sized Words, but...)

Sept. 2, 2009