From Johannes.Hofmann at gmx.de Tue Sep 1 21:30:54 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Sep 1 21:33:15 2009 Subject: [Dillo-dev] Planning In-Reply-To: <20090724171943.GA4464@blob.baaderstrasse.com> References: <20090724153328.GG9247@dillo.org> <20090724171943.GA4464@blob.baaderstrasse.com> Message-ID: <20090901193039.GA3040@blob.baaderstrasse.com> On Fri, Jul 24, 2009 at 07:19:43PM +0200, Johannes Hofmann wrote: > Hi, > > On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > Here are some pending issues which I've partially sorted by > > priority (at least the top half). Please add the missing ones and > > let's try to finish sorting it, with a view to planify our work. > > > > > > * Make DIV-based pages render correctly. > > This is the most visible rendering fault in Dillo. The > > textblock doesn't have a way to handle it (not implemented). > > IIRC I'm willing to dig into it and Johannes will help. > > e.g. http://www.advogato.org/faq.html > > With DIV-based pages you mean floats as in > http://www.w3.org/TR/CSS21/visuren.html#floats? > Yes, this is the most obvious rendering problem atm. > > > > > * Add blocker (this also has to do with privacy). > > A full RE-based one may have significant overhead (test > > required), but simple string-matching may do most of the trick. > > I've also thought for a long time that a "don't load from > > other sites" preference may help a lot. The whole topic needs > > some thought but it's not hard to implement. > > e.g. doubleclick. > > > > * Handle negative values in CSS. e.g. wikipedia. > > Actually it's dw/* that needs to be adapted to handle negative > margins. This might be related to the floats stuff. > > > > > * What will we do with xhtml? To render or not to render... > > FF doesn't validate. BUG#732 > > One solution is to add a notification widget area below the > > control panel that hides/unhides as the find bar, to warn when a > > xhtml file has detected bugs (we'd also move the meta refresh > > warning to display here). I already have a simple patch to add > > xhtml rendering. The widget implemetation is the missing part. > > It should be much simpler than the close button in each tab. :-) > > e.g. http://planet.postgresql.org/ > > > > * Jump to #anchor doesn't work correctly. > > It looks like a timing issue, but the idle-call API needs a > > review as a whole. > > > > * dpi for "view page source" (it re-uses search capability). > > This requires a check of the current data-passing inside DPIP. > > > > * Improve the DPI development/debug framework. > > > > * https dialog bombing issue. BUG#868 > > AKA make https dpi a server (i.e. not a filter dpi). > > > > * Render bug at http://www.directfb.org/ (and its links). The > > table has too wide a first column. Back/Fwd solves it. > > Yes, I've seen this on several pages. > > > > > *   handling in fltk.org > > The relevant point is to define a consistent way to handle > > whitespace in the textblock. > > Can you explain the problem a bit? > > > > > * FTP download doesn't work?! > > wget - based downloads work mostly fine for me. Where do you see an > issue? > > I've got one more point: > > * Add clipping to the fltk drawing code, so that e.g. margins of huge > boxes don't cause X11 coordinate overflows. > E.g. on http://alpen-panoramen.de/newcomments.php > I will try to fix that. Ok fix committed. This took a lot longer than expected. I almost had full polygon clipping implemented which is quite complex, until I realized that it is much simpler to change Style::drawBorder() to use rectangles and triangles instead of a single polygon for each side. That way we can easily clip the large part of the border (the rectangle) and avoid X11 coordinate overflows. It also seems that this makes dillo a bit snappier. Cheers, Johannes From Johannes.Hofmann at gmx.de Wed Sep 2 18:33:00 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Sep 2 18:35:16 2009 Subject: [Dillo-dev] horizontal scrolling while searching Message-ID: <20090902163300.GA1970@blob.baaderstrasse.com> 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? Cheers, Johannes From jcid at dillo.org Wed Sep 2 18:59:54 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Sep 2 19:01:16 2009 Subject: [Dillo-dev] Planning In-Reply-To: <20090901193039.GA3040@blob.baaderstrasse.com> References: <20090724153328.GG9247@dillo.org> <20090724171943.GA4464@blob.baaderstrasse.com> <20090901193039.GA3040@blob.baaderstrasse.com> Message-ID: <20090902165954.GC6312@dillo.org> On Tue, Sep 01, 2009 at 09:30:54PM +0200, Johannes Hofmann wrote: > On Fri, Jul 24, 2009 at 07:19:43PM +0200, Johannes Hofmann wrote: > > Hi, > > > > On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > > > Hi, > > > > > > Here are some pending issues which I've partially sorted by > > > priority (at least the top half). Please add the missing ones and > > > let's try to finish sorting it, with a view to planify our work. > > > > > > > > > * Make DIV-based pages render correctly. > > > This is the most visible rendering fault in Dillo. The > > > textblock doesn't have a way to handle it (not implemented). > > > IIRC I'm willing to dig into it and Johannes will help. > > > e.g. http://www.advogato.org/faq.html > > > > With DIV-based pages you mean floats as in > > http://www.w3.org/TR/CSS21/visuren.html#floats? > > Yes, this is the most obvious rendering problem atm. > > > > > > > > * Add blocker (this also has to do with privacy). > > > A full RE-based one may have significant overhead (test > > > required), but simple string-matching may do most of the trick. > > > I've also thought for a long time that a "don't load from > > > other sites" preference may help a lot. The whole topic needs > > > some thought but it's not hard to implement. > > > e.g. doubleclick. > > > > > > * Handle negative values in CSS. e.g. wikipedia. > > > > Actually it's dw/* that needs to be adapted to handle negative > > margins. This might be related to the floats stuff. > > > > > > > > * What will we do with xhtml? To render or not to render... > > > FF doesn't validate. BUG#732 > > > One solution is to add a notification widget area below the > > > control panel that hides/unhides as the find bar, to warn when a > > > xhtml file has detected bugs (we'd also move the meta refresh > > > warning to display here). I already have a simple patch to add > > > xhtml rendering. The widget implemetation is the missing part. > > > It should be much simpler than the close button in each tab. :-) > > > e.g. http://planet.postgresql.org/ > > > > > > * Jump to #anchor doesn't work correctly. > > > It looks like a timing issue, but the idle-call API needs a > > > review as a whole. > > > > > > * dpi for "view page source" (it re-uses search capability). > > > This requires a check of the current data-passing inside DPIP. > > > > > > * Improve the DPI development/debug framework. > > > > > > * https dialog bombing issue. BUG#868 > > > AKA make https dpi a server (i.e. not a filter dpi). > > > > > > * Render bug at http://www.directfb.org/ (and its links). The > > > table has too wide a first column. Back/Fwd solves it. > > > > Yes, I've seen this on several pages. > > > > > > > > *   handling in fltk.org > > > The relevant point is to define a consistent way to handle > > > whitespace in the textblock. > > > > Can you explain the problem a bit? > > > > > > > > * FTP download doesn't work?! > > > > wget - based downloads work mostly fine for me. Where do you see an > > issue? > > > > I've got one more point: > > > > * Add clipping to the fltk drawing code, so that e.g. margins of huge > > boxes don't cause X11 coordinate overflows. > > E.g. on http://alpen-panoramen.de/newcomments.php > > I will try to fix that. > > Ok fix committed. This took a lot longer than expected. I almost had > full polygon clipping implemented which is quite complex, until I > realized that it is much simpler to change Style::drawBorder() to > use rectangles and triangles instead of a single polygon for each > side. > That way we can easily clip the large part of the border (the > rectangle) and avoid X11 coordinate overflows. > It also seems that this makes dillo a bit snappier. Good, I also feel the extra snappiness! -- Cheers Jorge.- From corvid at lavabit.com Wed Sep 2 19:02:28 2009 From: corvid at lavabit.com (corvid) Date: Wed Sep 2 19:06:08 2009 Subject: [Dillo-dev] horizontal scrolling while searching In-Reply-To: <20090902163300.GA1970@blob.baaderstrasse.com> References: <20090902163300.GA1970@blob.baaderstrasse.com> Message-ID: <20090902170228.GK31054@local.gobigwest.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...) -------------- next part -------------- diff -r 1b4980dcee36 dw/textblock.cc --- a/dw/textblock.cc Wed Sep 02 00:47:10 2009 +0000 +++ b/dw/textblock.cc Wed Sep 02 03:49:54 2009 +0000 @@ -2159,10 +2159,27 @@ void Textblock::TextblockIterator::getAl Word *w = textblock->words->getRef(i); allocation->x += w->size.width + w->effSpace; } + if (start > 0 && word->content.type == core::Content::TEXT) { + allocation->x += textblock->layout->textWidth (word->style->font, + word->content.text, + start); + } allocation->y = textblock->allocation.y + textblock->lineYOffsetWidget (line) + line->ascent - word->size.ascent; + allocation->width = word->size.width; + if (word->content.type == core::Content::TEXT) { + int wordEnd = strlen(word->content.text); + + if (start > 0 || end < wordEnd) { + end = misc::min(end, wordEnd); /* end could be INT_MAX */ + allocation->width = + textblock->layout->textWidth (word->style->font, + word->content.text + start, + end - start); + } + } allocation->ascent = word->size.ascent; allocation->descent = word->size.descent; } From Johannes.Hofmann at gmx.de Wed Sep 2 21:40:26 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Sep 2 21:42:45 2009 Subject: [Dillo-dev] horizontal scrolling while searching In-Reply-To: <20090902170228.GK31054@local.gobigwest.com> References: <20090902163300.GA1970@blob.baaderstrasse.com> <20090902170228.GK31054@local.gobigwest.com> Message-ID: <20090902194026.GA15476@blob.baaderstrasse.com> 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 From Johannes.Hofmann at gmx.de Wed Sep 2 22:03:32 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Wed Sep 2 22:05:49 2009 Subject: [Dillo-dev] whattheinternetknowsaboutyou Message-ID: <20090902200331.GA16069@blob.baaderstrasse.com> 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 From corvid at lavabit.com Wed Sep 2 22:47:59 2009 From: corvid at lavabit.com (corvid) Date: Wed Sep 2 22:51:36 2009 Subject: [Dillo-dev] whattheinternetknowsaboutyou In-Reply-To: <20090902200331.GA16069@blob.baaderstrasse.com> References: <20090902200331.GA16069@blob.baaderstrasse.com> Message-ID: <20090902204759.GL31054@local.gobigwest.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? From corvid at lavabit.com Thu Sep 3 18:45:29 2009 From: corvid at lavabit.com (corvid) Date: Thu Sep 3 18:49:05 2009 Subject: [Dillo-dev] perhaps an iterator bug In-Reply-To: <20090209223810.GL8385@local.gobigwest.com> References: <20090209223810.GL8385@local.gobigwest.com> Message-ID: <20090903164529.GP31054@local.gobigwest.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: > > > > >
no close-tr >
has a close-tr
here's another line
> > 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... From Johannes.Hofmann at gmx.de Thu Sep 3 19:03:04 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Thu Sep 3 19:05:23 2009 Subject: [Dillo-dev] whattheinternetknowsaboutyou In-Reply-To: <20090902204759.GL31054@local.gobigwest.com> References: <20090902200331.GA16069@blob.baaderstrasse.com> <20090902204759.GL31054@local.gobigwest.com> Message-ID: <20090903170250.GA1108@blob.baaderstrasse.com> 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 click here
click here From jcid at dillo.org Thu Sep 3 19:20:00 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Sep 3 19:21:22 2009 Subject: [devidfil@gmail.com: [Dillo-dev] Switch to fltk1.3?] In-Reply-To: <20090830133039.GC3984@dillo.org> References: <20090829110636.GA1451@blob.baaderstrasse.com> <20090830133039.GC3984@dillo.org> Message-ID: <20090903172000.GC7900@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 > > Subject: [Dillo-dev] Switch to fltk1.3? > > To: dillo-dev@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.- From jcid at dillo.org Thu Sep 3 19:28:57 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Sep 3 19:30:20 2009 Subject: [Dillo-dev] perhaps an iterator bug In-Reply-To: <20090903164529.GP31054@local.gobigwest.com> References: <20090209223810.GL8385@local.gobigwest.com> <20090903164529.GP31054@local.gobigwest.com> Message-ID: <20090903172857.GE7900@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: > > > > > > > > > >
no close-tr > >
has a close-tr
here's another line
> > > > 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.- From Johannes.Hofmann at gmx.de Thu Sep 3 19:34:56 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Thu Sep 3 19:37:14 2009 Subject: [Dillo-dev] perhaps an iterator bug In-Reply-To: <20090903172857.GE7900@dillo.org> References: <20090209223810.GL8385@local.gobigwest.com> <20090903164529.GP31054@local.gobigwest.com> <20090903172857.GE7900@dillo.org> Message-ID: <20090903173456.GA1903@blob.baaderstrasse.com> 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: > > > > > > > > > > > > > > >
no close-tr > > >
has a close-tr
here's another line
> > > > > > 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? From corvid at lavabit.com Sat Sep 5 03:22:19 2009 From: corvid at lavabit.com (corvid) Date: Sat Sep 5 03:26:01 2009 Subject: [Dillo-dev] nytimes links and redirection Message-ID: <20090905012219.GT31054@local.gobigwest.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. From corvid at lavabit.com Mon Sep 7 01:17:25 2009 From: corvid at lavabit.com (corvid) Date: Mon Sep 7 01:21:04 2009 Subject: [Dillo-dev] experimental patch: image loading options "same domain", "same host" Message-ID: <20090906231725.GB621@local.gobigwest.com> I just put together a somewhat hacky patch to add "same host" and "same domain" for image loading from the tools button (or dillorc) http://www.dillo.org/test/img_loading_options.patch I ran on it as long as I could tolerate images over dialup (not long :), so here it is, and I will clean it up if there is interest shown in getting it into dillo. (I would probably want to change the names of the dillorc choices for image loading, make the internal value into an enum, look at the loadImages/autoload_image code duplication, etc., etc... Oh, and look up how to fix the tools menu width...) From jcid at dillo.org Mon Sep 7 20:23:13 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Sep 7 20:24:37 2009 Subject: [Dillo-dev] experimental patch: image loading options "same domain", "same host" In-Reply-To: <20090906231725.GB621@local.gobigwest.com> References: <20090906231725.GB621@local.gobigwest.com> Message-ID: <20090907182312.GA7624@dillo.org> On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: > I just put together a somewhat hacky patch to > add "same host" and "same domain" for image loading > from the tools button (or dillorc) > http://www.dillo.org/test/img_loading_options.patch > > I ran on it as long as I could tolerate images over > dialup (not long :), so here it is, and I will clean > it up if there is interest shown in getting it into > dillo. Good! I've had a similar idea for a long time. Since before the url filtering thread, I believe a simple blocking scheme based on same host/domain cuts most of the problem (bandwidth, privacy, tracking, web bugs etc). I'd suggest to add the filtering function in Capi. This is to make a_Capi_open_url() call a check function, e.g. if (Capi_filters_check_url(...) < 0) /* abort */ (you may add a ParentUrl DilloUrl to the webstructure). The point is to be able to reuse and improve the filter. (e.g. for CSS urls, sound streams, etc). > (I would probably want to change the names of the > dillorc choices for image loading, make the internal > value into an enum, look at the loadImages/autoload_image > code duplication, etc., etc... Oh, and look up how > to fix the tools menu width...) Something like: filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} should be enough to get started. -- Cheers Jorge.- From jcid at dillo.org Thu Sep 10 18:59:30 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Thu Sep 10 19:01:02 2009 Subject: [devidfil@gmail.com: [Dillo-dev] Switch to fltk1.3?] In-Reply-To: <20090830133039.GC3984@dillo.org> References: <20090829110636.GA1451@blob.baaderstrasse.com> <20090830133039.GC3984@dillo.org> Message-ID: <20090910165930.GB5310@dillo.org> Hi there, 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 > > Subject: [Dillo-dev] Switch to fltk1.3? > > To: dillo-dev@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. Excellent news on this thread! On Thu, Sep 10, 2009 at 09:17:52AM +0200, Matthias Melcher wrote: > > On 09.09.2009, at 17:35, Jorge Arellano Cid wrote: > >> Hi, >> >> Devid confirmed the proposed patch is OK! > > "Updated license to remain in the spirit of the original FLTK 2 license, > but at the same time complying to Debian license requirements." AFAIU this means the next FLTK2 snapshot will have the license change, and distros can package it with no concerns. Details here: http://fltk.org/newsgroups.php?s4036+gfltk.commit+v4055+T0 To us, it means we can untroubledly keep our fltk2-based dillo until fltk-1.3 sees an official release, and have it packaged by the main distros, without any legal troubles. :-) -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Thu Sep 10 21:01:51 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Thu Sep 10 21:04:12 2009 Subject: [devidfil@gmail.com: [Dillo-dev] Switch to fltk1.3?] In-Reply-To: <20090910165930.GB5310@dillo.org> References: <20090829110636.GA1451@blob.baaderstrasse.com> <20090830133039.GC3984@dillo.org> <20090910165930.GB5310@dillo.org> Message-ID: <20090910190151.GA969@blob.baaderstrasse.com> On Thu, Sep 10, 2009 at 12:59:30PM -0400, Jorge Arellano Cid wrote: > Hi there, > > > 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 > > > Subject: [Dillo-dev] Switch to fltk1.3? > > > To: dillo-dev@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. > > > Excellent news on this thread! > > > On Thu, Sep 10, 2009 at 09:17:52AM +0200, Matthias Melcher wrote: > > > > On 09.09.2009, at 17:35, Jorge Arellano Cid wrote: > > > >> Hi, > >> > >> Devid confirmed the proposed patch is OK! > > > > "Updated license to remain in the spirit of the original FLTK 2 license, > > but at the same time complying to Debian license requirements." > > > AFAIU this means the next FLTK2 snapshot will have the license > change, and distros can package it with no concerns. > > Details here: > > http://fltk.org/newsgroups.php?s4036+gfltk.commit+v4055+T0 > > To us, it means we can untroubledly keep our fltk2-based dillo > until fltk-1.3 sees an official release, and have it packaged by > the main distros, without any legal troubles. > > :-) Great! Thanks to everybody involved to get this resolved! Cheers, Johannes From corvid at lavabit.com Sat Sep 12 04:08:48 2009 From: corvid at lavabit.com (corvid) Date: Sat Sep 12 04:12:29 2009 Subject: [Dillo-dev] experimental patch: image loading options "same domain", "same host" In-Reply-To: <20090907182312.GA7624@dillo.org> References: <20090906231725.GB621@local.gobigwest.com> <20090907182312.GA7624@dillo.org> Message-ID: <20090912020848.GC10251@local.gobigwest.com> Jorge wrote: > On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: > > I just put together a somewhat hacky patch to > > add "same host" and "same domain" for image loading > > from the tools button (or dillorc) > > http://www.dillo.org/test/img_loading_options.patch > > > > I ran on it as long as I could tolerate images over > > dialup (not long :), so here it is, and I will clean > > it up if there is interest shown in getting it into > > dillo. > > Good! I've had a similar idea for a long time. > > Since before the url filtering thread, I believe a simple > blocking scheme based on same host/domain cuts most of the > problem (bandwidth, privacy, tracking, web bugs etc). > > I'd suggest to add the filtering function in Capi. This is > to make a_Capi_open_url() call a check function, e.g. > > if (Capi_filters_check_url(...) < 0) > /* abort */ > > (you may add a ParentUrl DilloUrl to the webstructure). > > The point is to be able to reuse and improve the filter. > (e.g. for CSS urls, sound streams, etc). > > > > (I would probably want to change the names of the > > dillorc choices for image loading, make the internal > > value into an enum, look at the loadImages/autoload_image > > code duplication, etc., etc... Oh, and look up how > > to fix the tools menu width...) > > Something like: > > filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} > > should be enough to get started. I made a new one: http://www.dillo.org/test/filtering.1.patch It doesn't have the menu stuff, so you have to set the preference. From corvid at lavabit.com Sat Sep 12 19:20:24 2009 From: corvid at lavabit.com (corvid) Date: Sat Sep 12 19:24:25 2009 Subject: organizational boundaries [Re: [Dillo-dev] experimental patch: image loading options "same domain", "same host"] In-Reply-To: <20090912020848.GC10251@local.gobigwest.com> References: <20090906231725.GB621@local.gobigwest.com> <20090907182312.GA7624@dillo.org> <20090912020848.GC10251@local.gobigwest.com> Message-ID: <20090912172024.GF10251@local.gobigwest.com> Looking around some more for information on how to deal with the fact that, e.g., www.dillo.org and hg.dillo.org are one thing and bbc.co.uk and theregister.co.uk aren't. (I'd like a better name for this than the "same domain" that I've been using.) And I discovered http://publicsuffix.org Perhaps someday we could let people stuff this big long list into .dillo/ if they want to. From Johannes.Hofmann at gmx.de Tue Sep 15 19:36:31 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Sep 15 19:38:53 2009 Subject: [Dillo-dev] experimental patch: image loading options "same domain", "same host" In-Reply-To: <20090912020848.GC10251@local.gobigwest.com> References: <20090906231725.GB621@local.gobigwest.com> <20090907182312.GA7624@dillo.org> <20090912020848.GC10251@local.gobigwest.com> Message-ID: <20090915173631.GA4102@blob.baaderstrasse.com> Hello, On Sat, Sep 12, 2009 at 02:08:48AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: > > > I just put together a somewhat hacky patch to > > > add "same host" and "same domain" for image loading > > > from the tools button (or dillorc) > > > http://www.dillo.org/test/img_loading_options.patch > > > > > > I ran on it as long as I could tolerate images over > > > dialup (not long :), so here it is, and I will clean > > > it up if there is interest shown in getting it into > > > dillo. > > > > Good! I've had a similar idea for a long time. > > > > Since before the url filtering thread, I believe a simple > > blocking scheme based on same host/domain cuts most of the > > problem (bandwidth, privacy, tracking, web bugs etc). > > > > I'd suggest to add the filtering function in Capi. This is > > to make a_Capi_open_url() call a check function, e.g. > > > > if (Capi_filters_check_url(...) < 0) > > /* abort */ > > > > (you may add a ParentUrl DilloUrl to the webstructure). > > > > The point is to be able to reuse and improve the filter. > > (e.g. for CSS urls, sound streams, etc). > > > > > > > (I would probably want to change the names of the > > > dillorc choices for image loading, make the internal > > > value into an enum, look at the loadImages/autoload_image > > > code duplication, etc., etc... Oh, and look up how > > > to fix the tools menu width...) > > > > Something like: > > > > filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} > > > > should be enough to get started. > > I made a new one: > http://www.dillo.org/test/filtering.1.patch > > It doesn't have the menu stuff, so you have to > set the preference. Hm... With "same_host" many sites no longer work because they seem to use redirects (e.g. heise.de -> www.heise.de) And once I have entered heise.de, www.heise.de doesn't work either. Generally, is it really a problem if we load url's from other hosts/domains? Or would it be enough to not send cookies or HTTP authentication data when loading such "unsafe" urls? Cheers, Johannes From 4winter at informatik.uni-hamburg.de Tue Sep 15 19:54:44 2009 From: 4winter at informatik.uni-hamburg.de (Justus Winter) Date: Tue Sep 15 19:55:35 2009 Subject: [Dillo-dev] experimental patch: image loading options "same domain", "same host" In-Reply-To: <20090915173631.GA4102@blob.baaderstrasse.com> References: <20090906231725.GB621@local.gobigwest.com> <20090907182312.GA7624@dillo.org> <20090912020848.GC10251@local.gobigwest.com> <20090915173631.GA4102@blob.baaderstrasse.com> Message-ID: <4AAFD4E4.4090605@informatik.uni-hamburg.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Hofmann wrote: > Hello, > > On Sat, Sep 12, 2009 at 02:08:48AM +0000, corvid wrote: >> Jorge wrote: >>> On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: >>>> I just put together a somewhat hacky patch to >>>> add "same host" and "same domain" for image loading >>>> from the tools button (or dillorc) >>>> http://www.dillo.org/test/img_loading_options.patch >>>> >>>> I ran on it as long as I could tolerate images over >>>> dialup (not long :), so here it is, and I will clean >>>> it up if there is interest shown in getting it into >>>> dillo. >>> Good! I've had a similar idea for a long time. >>> >>> Since before the url filtering thread, I believe a simple >>> blocking scheme based on same host/domain cuts most of the >>> problem (bandwidth, privacy, tracking, web bugs etc). >>> >>> I'd suggest to add the filtering function in Capi. This is >>> to make a_Capi_open_url() call a check function, e.g. >>> >>> if (Capi_filters_check_url(...) < 0) >>> /* abort */ >>> >>> (you may add a ParentUrl DilloUrl to the webstructure). >>> >>> The point is to be able to reuse and improve the filter. >>> (e.g. for CSS urls, sound streams, etc). >>> >>> >>>> (I would probably want to change the names of the >>>> dillorc choices for image loading, make the internal >>>> value into an enum, look at the loadImages/autoload_image >>>> code duplication, etc., etc... Oh, and look up how >>>> to fix the tools menu width...) >>> Something like: >>> >>> filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} >>> >>> should be enough to get started. >> I made a new one: >> http://www.dillo.org/test/filtering.1.patch >> >> It doesn't have the menu stuff, so you have to >> set the preference. > > Hm... With "same_host" many sites no longer work because they seem > to use redirects (e.g. heise.de -> www.heise.de) > And once I have entered heise.de, www.heise.de doesn't work either. > > Generally, is it really a problem if we load url's from other > hosts/domains? > > Or would it be enough to not send cookies or HTTP authentication > data when loading such "unsafe" urls? If you're trying to protect dillo users from {X,C}SRF attacks then stripping http authentication and cookies is a first step but it won't protect users of intranet applications that rely on the users ip address for authentication (think home routers with web interface). Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqv1OQACgkQoPmwNWhsaZb+FACghNtaYfxcboMp1ovLmBZoy7LK MW4An08UfIfzcU2ktLqtmTLmfivzrECR =NrPe -----END PGP SIGNATURE----- From Johannes.Hofmann at gmx.de Tue Sep 15 19:56:03 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Sep 15 19:58:31 2009 Subject: [Dillo-dev] experimental patch: image loading options "same domain", "same host" In-Reply-To: <4AAFD4E4.4090605@informatik.uni-hamburg.de> References: <20090906231725.GB621@local.gobigwest.com> <20090907182312.GA7624@dillo.org> <20090912020848.GC10251@local.gobigwest.com> <20090915173631.GA4102@blob.baaderstrasse.com> <4AAFD4E4.4090605@informatik.uni-hamburg.de> Message-ID: <20090915175603.GA4634@blob.baaderstrasse.com> On Tue, Sep 15, 2009 at 07:54:44PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Johannes Hofmann wrote: > > Hello, > > > > On Sat, Sep 12, 2009 at 02:08:48AM +0000, corvid wrote: > >> Jorge wrote: > >>> On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: > >>>> I just put together a somewhat hacky patch to > >>>> add "same host" and "same domain" for image loading > >>>> from the tools button (or dillorc) > >>>> http://www.dillo.org/test/img_loading_options.patch > >>>> > >>>> I ran on it as long as I could tolerate images over > >>>> dialup (not long :), so here it is, and I will clean > >>>> it up if there is interest shown in getting it into > >>>> dillo. > >>> Good! I've had a similar idea for a long time. > >>> > >>> Since before the url filtering thread, I believe a simple > >>> blocking scheme based on same host/domain cuts most of the > >>> problem (bandwidth, privacy, tracking, web bugs etc). > >>> > >>> I'd suggest to add the filtering function in Capi. This is > >>> to make a_Capi_open_url() call a check function, e.g. > >>> > >>> if (Capi_filters_check_url(...) < 0) > >>> /* abort */ > >>> > >>> (you may add a ParentUrl DilloUrl to the webstructure). > >>> > >>> The point is to be able to reuse and improve the filter. > >>> (e.g. for CSS urls, sound streams, etc). > >>> > >>> > >>>> (I would probably want to change the names of the > >>>> dillorc choices for image loading, make the internal > >>>> value into an enum, look at the loadImages/autoload_image > >>>> code duplication, etc., etc... Oh, and look up how > >>>> to fix the tools menu width...) > >>> Something like: > >>> > >>> filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} > >>> > >>> should be enough to get started. > >> I made a new one: > >> http://www.dillo.org/test/filtering.1.patch > >> > >> It doesn't have the menu stuff, so you have to > >> set the preference. > > > > Hm... With "same_host" many sites no longer work because they seem > > to use redirects (e.g. heise.de -> www.heise.de) > > And once I have entered heise.de, www.heise.de doesn't work either. > > > > Generally, is it really a problem if we load url's from other > > hosts/domains? > > > > Or would it be enough to not send cookies or HTTP authentication > > data when loading such "unsafe" urls? > If you're trying to protect dillo users from {X,C}SRF attacks then > stripping http authentication and cookies is a first step but it won't > protect users of intranet applications that rely on the users ip address > for authentication (think home routers with web interface). Ouch. Is there some general agreement on what web browsers should do in this regard? From joerg.sonnenberger at web.de Tue Sep 15 20:08:06 2009 From: joerg.sonnenberger at web.de (Joerg Sonnenberger) Date: Tue Sep 15 20:09:34 2009 Subject: [Dillo-dev] experimental patch: image loading options "same domain", "same host" In-Reply-To: <20090915173631.GA4102@blob.baaderstrasse.com> References: <20090906231725.GB621@local.gobigwest.com> <20090907182312.GA7624@dillo.org> <20090912020848.GC10251@local.gobigwest.com> <20090915173631.GA4102@blob.baaderstrasse.com> Message-ID: <20090915180806.GA16771@britannica.bec.de> On Tue, Sep 15, 2009 at 07:36:31PM +0200, Johannes Hofmann wrote: > Or would it be enough to not send cookies or HTTP authentication > data when loading such "unsafe" urls? Cookies have an explicit domain part if they are supposed to apply to more than the current host. HTTP authentication is URL specific or at most host specific. Joerg From Johannes.Hofmann at gmx.de Tue Sep 15 20:18:09 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Sep 15 20:20:32 2009 Subject: [Dillo-dev] experimental patch: image loading options "same domain", "same host" In-Reply-To: <20090915180806.GA16771@britannica.bec.de> References: <20090906231725.GB621@local.gobigwest.com> <20090907182312.GA7624@dillo.org> <20090912020848.GC10251@local.gobigwest.com> <20090915173631.GA4102@blob.baaderstrasse.com> <20090915180806.GA16771@britannica.bec.de> Message-ID: <20090915181809.GA4801@blob.baaderstrasse.com> On Tue, Sep 15, 2009 at 08:08:06PM +0200, Joerg Sonnenberger wrote: > On Tue, Sep 15, 2009 at 07:36:31PM +0200, Johannes Hofmann wrote: > > Or would it be enough to not send cookies or HTTP authentication > > data when loading such "unsafe" urls? > > Cookies have an explicit domain part if they are supposed to apply to > more than the current host. HTTP authentication is URL specific or at > most host specific. Not sure if that helps here. If the user has a cookie set that authenticates him at www.hisbank.com and a page on www.badguy.com contains an image with the url http://www.hisbank.com?transfer_to_badguy=100000 the browser would happily send the cookie to www.hisbank.com to authenticate him. Of course www.hisbank.com should have additional checks installed that prevent such misuse. Cheers, Johannes From corvid at lavabit.com Tue Sep 15 21:21:32 2009 From: corvid at lavabit.com (corvid) Date: Tue Sep 15 21:25:14 2009 Subject: [Dillo-dev] experimental patch: image loading options "same domain", "same host" In-Reply-To: <20090915173631.GA4102@blob.baaderstrasse.com> References: <20090906231725.GB621@local.gobigwest.com> <20090907182312.GA7624@dillo.org> <20090912020848.GC10251@local.gobigwest.com> <20090915173631.GA4102@blob.baaderstrasse.com> Message-ID: <20090915192132.GA1597@local.gobigwest.com> Johannes wrote: > Hm... With "same_host" many sites no longer work because they seem > to use redirects (e.g. heise.de -> www.heise.de) > And once I have entered heise.de, www.heise.de doesn't work either. I have also found same_host not to have any value. > Generally, is it really a problem if we load url's from other > hosts/domains? Sites have no right to redirect me to unrelated sites, and sites have no right to subject me to images from unrelated sites. > Or would it be enough to not send cookies or HTTP authentication > data when loading such "unsafe" urls? From dennisn at dennisn.dyndns.org Wed Sep 16 15:01:22 2009 From: dennisn at dennisn.dyndns.org (Dennis Nezic) Date: Wed Sep 16 15:02:22 2009 Subject: [Dillo-dev] View page source suggestions Message-ID: <20090916090122.446e8a72.dennisn@dennisn.dyndns.org> Currently, the "View page source" right-click context menu isn't available below the rendered html -- so if the actual html page is very small and/or dillo's window is very big, right clicking the bottom half (for example) of the browser does nothing :\. Also, is there a way to have the source viewed in one's preferred text editor? :b (read: gvim) From corvid at lavabit.com Wed Sep 16 17:48:06 2009 From: corvid at lavabit.com (corvid) Date: Wed Sep 16 17:51:48 2009 Subject: [Dillo-dev] View page source suggestions In-Reply-To: <20090916090122.446e8a72.dennisn@dennisn.dyndns.org> References: <20090916090122.446e8a72.dennisn@dennisn.dyndns.org> Message-ID: <20090916154806.GB1597@local.gobigwest.com> Dennis wrote: > Currently, the "View page source" right-click context menu isn't > available below the rendered html -- so if the actual html page is very > small and/or dillo's window is very big, right clicking the bottom half > (for example) of the browser does nothing :\. This one happens to have some complexity. The problem is that there aren't any widgets down there and they are what send the signals to trigger the menus. Maybe it would be possible to increase a layout's top-level widget's size to fill a viewport (if the layout isn't inside a button [if there's a way to check that] and the widget is a textblock), or maybe that would break something. (I actually wonder whether the signaling could be routed back through the layout or something [perhaps making handling the case easier from fltkviewbase], since all of the connectLink()s always seemed redundant to me. That might go against Dw philosophy, though, whatever that might be exactly.) > Also, is there a way to have the source viewed in one's preferred text > editor? :b (read: gvim) Only the usual way :) From jcid at dillo.org Wed Sep 16 18:52:22 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Sep 16 18:53:53 2009 Subject: [Dillo-dev] View page source suggestions In-Reply-To: <20090916154806.GB1597@local.gobigwest.com> References: <20090916090122.446e8a72.dennisn@dennisn.dyndns.org> <20090916154806.GB1597@local.gobigwest.com> Message-ID: <20090916165222.GA7143@dillo.org> On Wed, Sep 16, 2009 at 03:48:06PM +0000, corvid wrote: > Dennis wrote: > > Currently, the "View page source" right-click context menu isn't > > available below the rendered html -- so if the actual html page is very > > small and/or dillo's window is very big, right clicking the bottom half > > (for example) of the browser does nothing :\. > > This one happens to have some complexity. > > The problem is that there aren't any widgets down there and they are > what send the signals to trigger the menus. Maybe it would be possible > to increase a layout's top-level widget's size to fill a viewport > (if the layout isn't inside a button [if there's a way to check that] > and the widget is a textblock), or maybe that would break something. Yes. Maybe adding an empty widget at the bottom may solve this. > > Also, is there a way to have the source viewed in one's preferred text > > editor? :b (read: gvim) > > Only the usual way :) The idea for "View source" is to handle it with a dpi so we we can reuse dillo (it's faster and has a search function). Once this is done (which needs a review of dpip), it would be simple to adapt the dpi program to use an external editor (because a dpi program is an independent process, that in this case, would receive the source contents). I'm currently working deep in the dpi-framework. Hopefully some good news may come at the end of the month... -- Cheers Jorge.- From jcid at dillo.org Wed Sep 16 18:52:22 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Wed Sep 16 18:53:54 2009 Subject: [Dillo-dev] View page source suggestions In-Reply-To: <20090916154806.GB1597@local.gobigwest.com> References: <20090916090122.446e8a72.dennisn@dennisn.dyndns.org> <20090916154806.GB1597@local.gobigwest.com> Message-ID: <20090916165222.GA7143@dillo.org> On Wed, Sep 16, 2009 at 03:48:06PM +0000, corvid wrote: > Dennis wrote: > > Currently, the "View page source" right-click context menu isn't > > available below the rendered html -- so if the actual html page is very > > small and/or dillo's window is very big, right clicking the bottom half > > (for example) of the browser does nothing :\. > > This one happens to have some complexity. > > The problem is that there aren't any widgets down there and they are > what send the signals to trigger the menus. Maybe it would be possible > to increase a layout's top-level widget's size to fill a viewport > (if the layout isn't inside a button [if there's a way to check that] > and the widget is a textblock), or maybe that would break something. Yes. Maybe adding an empty widget at the bottom may solve this. > > Also, is there a way to have the source viewed in one's preferred text > > editor? :b (read: gvim) > > Only the usual way :) The idea for "View source" is to handle it with a dpi so we we can reuse dillo (it's faster and has a search function). Once this is done (which needs a review of dpip), it would be simple to adapt the dpi program to use an external editor (because a dpi program is an independent process, that in this case, would receive the source contents). I'm currently working deep in the dpi-framework. Hopefully some good news may come at the end of the month... -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Thu Sep 17 19:44:00 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Thu Sep 17 19:46:20 2009 Subject: [Dillo-dev] experimental patch: image loading options "same domain", "same host" In-Reply-To: <20090915192132.GA1597@local.gobigwest.com> References: <20090906231725.GB621@local.gobigwest.com> <20090907182312.GA7624@dillo.org> <20090912020848.GC10251@local.gobigwest.com> <20090915173631.GA4102@blob.baaderstrasse.com> <20090915192132.GA1597@local.gobigwest.com> Message-ID: <20090917174400.GA928@blob.baaderstrasse.com> On Tue, Sep 15, 2009 at 07:21:32PM +0000, corvid wrote: > Johannes wrote: > > Hm... With "same_host" many sites no longer work because they seem > > to use redirects (e.g. heise.de -> www.heise.de) > > And once I have entered heise.de, www.heise.de doesn't work either. > > I have also found same_host not to have any value. > > > Generally, is it really a problem if we load url's from other > > hosts/domains? > > Sites have no right to redirect me to unrelated sites, and > sites have no right to subject me to images from unrelated sites. I tend to agree. With your patch I noticed that many popular sites contain 1x1 images from some statistics gathering companies. However I think these images do not really leak additional information as the sites could report your IP address behind the scenes as well. Cheers, Johannes From corvid at lavabit.com Thu Sep 17 20:21:02 2009 From: corvid at lavabit.com (corvid) Date: Thu Sep 17 20:24:45 2009 Subject: [Dillo-dev] experimental patch: image loading options "same domain", "same host" In-Reply-To: <20090917174400.GA928@blob.baaderstrasse.com> References: <20090906231725.GB621@local.gobigwest.com> <20090907182312.GA7624@dillo.org> <20090912020848.GC10251@local.gobigwest.com> <20090915173631.GA4102@blob.baaderstrasse.com> <20090915192132.GA1597@local.gobigwest.com> <20090917174400.GA928@blob.baaderstrasse.com> Message-ID: <20090917182102.GI1597@local.gobigwest.com> Johannes wrote: > On Tue, Sep 15, 2009 at 07:21:32PM +0000, corvid wrote: > > Johannes wrote: > > > Hm... With "same_host" many sites no longer work because they seem > > > to use redirects (e.g. heise.de -> www.heise.de) > > > And once I have entered heise.de, www.heise.de doesn't work either. > > > > I have also found same_host not to have any value. > > > > > Generally, is it really a problem if we load url's from other > > > hosts/domains? > > > > Sites have no right to redirect me to unrelated sites, and > > sites have no right to subject me to images from unrelated sites. > > I tend to agree. With your patch I noticed that many popular sites > contain 1x1 images from some statistics gathering companies. > However I think these images do not really leak additional information as > the sites could report your IP address behind the scenes as well. I think the term "user agent" for a browser is very apt. These companies ask dillo to serve as an accomplice as they violate the user's right to privacy. From Johannes.Hofmann at gmx.de Sat Sep 19 11:31:54 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sat Sep 19 11:34:17 2009 Subject: [Dillo-dev] Textblock::drawLine() split Message-ID: <20090919093154.GA1254@blob.baaderstrasse.com> Hi corvid, this split was overdue! Thanks a lot for the cleanup. Cheers, Johannes From onepoint at starurchin.org Sun Sep 20 00:32:19 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Sun Sep 20 00:33:16 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code Message-ID: <20090919223219.GL32370@omphalos.singularity> Long time no post! Here's a fix for an outstanding TODO in html.cc. It replaces the code that creates the HTML META REFRESH warning (which sends HTML to Html_write_raw()) with a function that creates the widgets directly. There are still a few issues: * The HTML parser in table.cc does not create table widgets if USE_TABLES is not defined. Perhaps this code should do the same? * The new widgets do not have 'width="100%"' set, so the horizontal layout is slightly different. * The redirect link colour does not reflect whether the link URL has been visited. * It would be nice if the widgets and the redirect link were styled from the User Agent style in css.cc . I couldn't figure out how to do that so I just copied a few things like the link colour and text decoration. If someone tells me how to do this properly I'll revise the code. Please comment! Jeremy Henty -------------- next part -------------- diff -r dd7bcbcd0d21 src/html.cc --- a/src/html.cc Sat Sep 19 09:27:41 2009 +0100 +++ b/src/html.cc Sat Sep 19 22:30:49 2009 +0100 @@ -40,6 +40,7 @@ #include "table.hh" #include "dw/textblock.hh" +#include "dw/table.hh" #include "dw/bullet.hh" #include "dw/listitem.hh" #include "dw/image.hh" @@ -2806,23 +2807,116 @@ * http://lists.w3.org/Archives/Public/www-html/2000Feb/thread.html#msg232 * Instant client-side redirects (delay=0) are supported: * http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H76.html - * - * TODO: Note that we're sending custom HTML while still IN_HEAD. This - * is a hackish way to put the message. A much cleaner approach is to - * build a custom widget for it. */ + +static void Html_warn_about_refresh(DilloHtml *html, const char *url_str, + int delay) +{ + const char *warning = "Warning:"; + const int warning_color = 0xee0000; + const char *recommendation[] = { + "This page uses the NON-STANDARD meta refresh tag.", + "The HTML 4.01 SPEC (sec 7.4.4) " + "recommends explicitly to avoid it.", + }; + const int recommendation_color = 0x8899aa; + const char *redirect[] = { + "The author wanted you to go ", + "here", + " after %d second%s.", + }; + const int redirect_color = 0xa0a0a0; + /* the next three are copied from the user agent style in css.hh */ + const Cursor link_cursor = CURSOR_POINTER; + const TextDecoration link_textdecoration = TEXT_DECORATION_UNDERLINE; + const int link_color = 0x0000ff; + + DilloUrl *url; + + HT2TB(html)->addParbreak(0, html->styleEngine->wordStyle ()); + + Table *table = new Table(prefs.limit_text_width); + HT2TB(html)->addWidget (table, html->styleEngine->style ()); + + /* the warning */ + Textblock *warning_tb = + new Textblock (prefs.limit_text_width); + StyleAttrs warning_styleattrs = + *(html->styleEngine->style ()); + warning_styleattrs.backgroundColor = + Color::create(HT2LT(html), warning_color); + Style *warning_style = + Style::create(HT2LT(html), &warning_styleattrs); + warning_tb->setStyle (warning_style); + table->addCell(warning_tb, 1, 1); + warning_tb->addText(warning, html->styleEngine->wordStyle ()); + + /* the recommendation */ + Textblock *recommendation_tb = + new Textblock (prefs.limit_text_width); + StyleAttrs recommendation_styleattrs = + *(html->styleEngine->style ()); + recommendation_styleattrs.backgroundColor = + Color::create(HT2LT(html), recommendation_color); + Style *recommendation_style = + Style::create(HT2LT(html), &recommendation_styleattrs); + recommendation_tb->setStyle (recommendation_style); + table->addCell(recommendation_tb, 1, 1); + recommendation_tb->addText(recommendation[0], + html->styleEngine->wordStyle ()); + recommendation_tb->addLinebreak(html->styleEngine->wordStyle ()); + recommendation_tb->addText(recommendation[1], + html->styleEngine->wordStyle ()); + + /* the redirection table cell */ + + if ((url = a_Html_url_new(html, url_str, NULL, 0))) { + table->addRow(html->styleEngine->style ()); + + Textblock *redirect_tb = + new Textblock (prefs.limit_text_width); + StyleAttrs redirect_styleattrs = + *(html->styleEngine->style ()); + redirect_styleattrs.backgroundColor = + Color::create(HT2LT(html), redirect_color); + Style *redirect_style = + Style::create(HT2LT(html), &redirect_styleattrs); + redirect_tb->setStyle (redirect_style); + table->addCell(redirect_tb, 2, 1); + html->connectSignals(redirect_tb); + + /* the redirection text (part 1) */ + redirect_tb->addText(redirect[0], html->styleEngine->wordStyle ()); + + /* the redirection link */ + StyleAttrs link_styleattrs = + *(html->styleEngine->wordStyle ()); + link_styleattrs.x_link = + Html_set_new_link(html, &url); + link_styleattrs.cursor = link_cursor; + link_styleattrs.textDecoration = link_textdecoration; + link_styleattrs.color = + Color::create(HT2LT(html), link_color); + Style *link_style = + Style::create(HT2LT(html), &link_styleattrs); + redirect_tb->addText(redirect[1], link_style); + + /* the redirection text (part 2) */ + Dstr *redirect_ds = dStr_sized_new(256); + dStr_sprintf(redirect_ds, redirect[2], + delay, (delay > 1) ? "s" : ""); + redirect_tb->addText(redirect_ds->str, + html->styleEngine->wordStyle ()); + dStr_free(redirect_ds, 1); + } + + HT2TB(html)->addParbreak(0, html->styleEngine->wordStyle ()); +} + static void Html_tag_open_meta(DilloHtml *html, const char *tag, int tagsize) { - const char meta_template[] = -"\n" -" \n" -"
Warning:\n" -" This page uses the NON-STANDARD meta refresh tag.
The HTML 4.01 SPEC\n" -" (sec 7.4.4) recommends explicitly to avoid it.
The author wanted you to go\n" -" here%s

\n"; - const char *p, *equiv, *content, *new_content; - char delay_str[64], *mr_url; + char *mr_url; int delay; /* only valid inside HEAD */ @@ -2835,13 +2929,8 @@ if (!dStrcasecmp(equiv, "refresh") && (content = a_Html_get_attr(html, tag, tagsize, "content"))) { - /* Get delay, if present, and make a message with it */ - if ((delay = strtol(content, NULL, 0))) { - snprintf(delay_str, 64, " after %d second%s.", - delay, (delay > 1) ? "s" : ""); - } else { - sprintf(delay_str, "."); - } + /* Get delay, if present */ + delay = strtol(content, NULL, 0); /* Skip to anything after "URL=" */ while (*content && *(content++) != '=') ; /* Handle the case of a quoted URL */ @@ -2862,21 +2951,7 @@ a_UIcmd_redirection0((void*)html->bw, new_url); a_Url_free(new_url); } else { - /* Send a custom HTML message. - * TODO: This is a hairy hack, - * It'd be much better to build a widget. */ - Dstr *ds_msg = dStr_sized_new(256); - dStr_sprintf(ds_msg, meta_template, mr_url, delay_str); - { - int o_InFlags = html->InFlags; - int o_TagSoup = html->TagSoup; - html->InFlags = IN_BODY; - html->TagSoup = false; - Html_write_raw(html, ds_msg->str, ds_msg->len, 0); - html->TagSoup = o_TagSoup; - html->InFlags = o_InFlags; - } - dStr_free(ds_msg, 1); + Html_warn_about_refresh(html, mr_url, delay); } dFree(mr_url); From jcid at dillo.org Tue Sep 22 05:58:09 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Sep 22 06:00:02 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090919223219.GL32370@omphalos.singularity> References: <20090919223219.GL32370@omphalos.singularity> Message-ID: <20090922035809.GB5402@dillo.org> Hi Jeremy, Good to see you around! On Sat, Sep 19, 2009 at 11:32:19PM +0100, Jeremy Henty wrote: > > Long time no post! Here's a fix for an outstanding TODO in html.cc. > It replaces the code that creates the HTML META REFRESH warning (which > sends HTML to Html_write_raw()) with a function that creates the > widgets directly. Hopefully I'll review it in the next days. > There are still a few issues: > > * The HTML parser in table.cc does not create table widgets if > USE_TABLES is not defined. Perhaps this code should do the same? Not necessary. That was an old feature for narrow displays. > > * The new widgets do not have 'width="100%"' set, so the horizontal > layout is slightly different. > > * The redirect link colour does not reflect whether the link URL has > been visited. > > * It would be nice if the widgets and the redirect link were styled > from the User Agent style in css.cc . I couldn't figure out how > to do that so I just copied a few things like the link colour and > text decoration. If someone tells me how to do this properly I'll > revise the code. AFAIS, the warning widget needs its own scheme, like the rest of the panel. > Please comment! More in the next days... -- Cheers Jorge.- From onepoint at starurchin.org Tue Sep 22 08:47:09 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Tue Sep 22 08:48:03 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090922035809.GB5402@dillo.org> References: <20090919223219.GL32370@omphalos.singularity> <20090922035809.GB5402@dillo.org> Message-ID: <20090922064709.GP32370@omphalos.singularity> On Mon, Sep 21, 2009 at 11:58:09PM -0400, Jorge Arellano Cid wrote: > > * The HTML parser in table.cc does not create table widgets if > > USE_TABLES is not defined. Perhaps this code should do the > > same? > > Not necessary. That was an old feature for narrow displays. In that case, shouldn't we remove USE_TABLES entirely? > > * It would be nice if the widgets and the redirect link were > > styled from the User Agent style in css.cc . ... > > AFAIS, the warning widget needs its own scheme, like the rest of > the panel. Perhaps we could extend the default style in css.cc with clauses like "dillo meta-refresh-warning redirect { color: ... }", using "dillo" as a reserved CSS class for internal use? Then all of the style information would be in CSS and none of it would be hard-coded in the parser, which is how it should be. I still haven't worked out how to apply the CSS stylesheets to the widgets I create (the style engine mechanism isn't being applied because I create the widgets directly instead of from HTML). I tried adding calls to styleEngine->{startElement,endElement}() but nothing happened. I'm clearly still missing something. I'll have another look, but any tips will be welcome! Regards, Jeremy Henty From Johannes.Hofmann at gmx.de Tue Sep 22 18:21:11 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Sep 22 18:23:33 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090922064709.GP32370@omphalos.singularity> References: <20090919223219.GL32370@omphalos.singularity> <20090922035809.GB5402@dillo.org> <20090922064709.GP32370@omphalos.singularity> Message-ID: <20090922162111.GA986@blob.baaderstrasse.com> Hi Jeremy, On Tue, Sep 22, 2009 at 07:47:09AM +0100, Jeremy Henty wrote: > On Mon, Sep 21, 2009 at 11:58:09PM -0400, Jorge Arellano Cid wrote: > > > > * The HTML parser in table.cc does not create table widgets if > > > USE_TABLES is not defined. Perhaps this code should do the > > > same? > > > > Not necessary. That was an old feature for narrow displays. > > In that case, shouldn't we remove USE_TABLES entirely? > > > > * It would be nice if the widgets and the redirect link were > > > styled from the User Agent style in css.cc . ... > > > > AFAIS, the warning widget needs its own scheme, like the rest of > > the panel. > > Perhaps we could extend the default style in css.cc with clauses like > "dillo meta-refresh-warning redirect { color: ... }", using "dillo" > as a reserved CSS class for internal use? Then all of the style > information would be in CSS and none of it would be hard-coded in the > parser, which is how it should be. Yes, this would be possible. Other browsers also have similar extensions. They seem to start with a '-' usually ("-webkit...", "-moz..."). But generally if we generate messages in the rendering area, we can't avoid that someone fakes them on his webpage. > > I still haven't worked out how to apply the CSS stylesheets to the > widgets I create (the style engine mechanism isn't being applied > because I create the widgets directly instead of from HTML). I tried > adding calls to styleEngine->{startElement,endElement}() but nothing > happened. I'm clearly still missing something. I'll have another > look, but any tips will be welcome! That should work. You need those styleEngine->{startElement,endElement}() calls and then use styleEngine->style() for your widgets. See plain.cc for an example. And of course you need to specify corresponding css either in the user agent style in css.cc or for testing just in your ~/.dillo/style.css file. Regards, Johannes From corvid at lavabit.com Tue Sep 22 18:35:28 2009 From: corvid at lavabit.com (corvid) Date: Tue Sep 22 18:39:15 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090922162111.GA986@blob.baaderstrasse.com> References: <20090919223219.GL32370@omphalos.singularity> <20090922035809.GB5402@dillo.org> <20090922064709.GP32370@omphalos.singularity> <20090922162111.GA986@blob.baaderstrasse.com> Message-ID: <20090922163528.GA13919@local.gobigwest.com> Johannes wrote: > On Tue, Sep 22, 2009 at 07:47:09AM +0100, Jeremy Henty wrote: > > On Mon, Sep 21, 2009 at 11:58:09PM -0400, Jorge Arellano Cid wrote: > > > > > > * The HTML parser in table.cc does not create table widgets if > > > > USE_TABLES is not defined. Perhaps this code should do the > > > > same? > > > > > > Not necessary. That was an old feature for narrow displays. > > > > In that case, shouldn't we remove USE_TABLES entirely? > > > > > > * It would be nice if the widgets and the redirect link were > > > > styled from the User Agent style in css.cc . ... > > > > > > AFAIS, the warning widget needs its own scheme, like the rest of > > > the panel. > > > > Perhaps we could extend the default style in css.cc with clauses like > > "dillo meta-refresh-warning redirect { color: ... }", using "dillo" > > as a reserved CSS class for internal use? Then all of the style > > information would be in CSS and none of it would be hard-coded in the > > parser, which is how it should be. > > Yes, this would be possible. Other browsers also have similar > extensions. They seem to start with a '-' usually ("-webkit...", > "-moz..."). > But generally if we generate messages in the rendering area, we > can't avoid that someone fakes them on his webpage. Would it be less trouble to have this widget as a child of the UI instead of in the rendering area? (I sort of had the impression that was the plan, but maybe that was the xhtml one, or maybe I'm just mixed up.) From jcid at dillo.org Tue Sep 22 20:25:47 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Sep 22 20:27:20 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090922163528.GA13919@local.gobigwest.com> References: <20090919223219.GL32370@omphalos.singularity> <20090922035809.GB5402@dillo.org> <20090922064709.GP32370@omphalos.singularity> <20090922162111.GA986@blob.baaderstrasse.com> <20090922163528.GA13919@local.gobigwest.com> Message-ID: <20090922182547.GA8800@dillo.org> On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Sep 22, 2009 at 07:47:09AM +0100, Jeremy Henty wrote: > > > On Mon, Sep 21, 2009 at 11:58:09PM -0400, Jorge Arellano Cid wrote: > > > > > > > > * The HTML parser in table.cc does not create table widgets if > > > > > USE_TABLES is not defined. Perhaps this code should do the > > > > > same? > > > > > > > > Not necessary. That was an old feature for narrow displays. > > > > > > In that case, shouldn't we remove USE_TABLES entirely? > > > > > > > > * It would be nice if the widgets and the redirect link were > > > > > styled from the User Agent style in css.cc . ... > > > > > > > > AFAIS, the warning widget needs its own scheme, like the rest of > > > > the panel. > > > > > > Perhaps we could extend the default style in css.cc with clauses like > > > "dillo meta-refresh-warning redirect { color: ... }", using "dillo" > > > as a reserved CSS class for internal use? Then all of the style > > > information would be in CSS and none of it would be hard-coded in the > > > parser, which is how it should be. > > > > Yes, this would be possible. Other browsers also have similar > > extensions. They seem to start with a '-' usually ("-webkit...", > > "-moz..."). > > But generally if we generate messages in the rendering area, we > > can't avoid that someone fakes them on his webpage. > > Would it be less trouble to have this widget as a child of the UI > instead of in the rendering area? (I sort of had the impression that > was the plan, but maybe that was the xhtml one, or maybe I'm just > mixed up.) That's exactly the plan. A simple fltk widget that hides/shows (as the findext bar) and that gives a text message. It should also support a fake HTML link (underlined word that reacts to left click). Sorry for not having the time yet to test the code... -- Cheers Jorge.- From onepoint at starurchin.org Thu Sep 24 07:04:15 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Thu Sep 24 07:05:10 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090922182547.GA8800@dillo.org> References: <20090919223219.GL32370@omphalos.singularity> <20090922035809.GB5402@dillo.org> <20090922064709.GP32370@omphalos.singularity> <20090922162111.GA986@blob.baaderstrasse.com> <20090922163528.GA13919@local.gobigwest.com> <20090922182547.GA8800@dillo.org> Message-ID: <20090924050415.GA14706@omphalos.singularity> On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > Would it be less trouble to have this widget as a child of the UI > > instead of in the rendering area? (I sort of had the impression > > that was the plan... > > That's exactly the plan. > > A simple fltk widget that hides/shows (as the findext bar) and > that gives a text message. It should also support a fake HTML link > (underlined word that reacts to left click). Ah, I think I misunderstood the reference to "custom widget" in the TO DO note. I was fixated on the Dillo Widget system and didn't realise it was talking about a new FLTK widget. Maybe my patch isn't the way to go. Still, it would be nice for the custom widget to be properly CSS-styled. Maybe it be could another FltkViewport? Regards, Jeremy Henty From jcid at dillo.org Fri Sep 25 13:16:12 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Sep 25 13:17:45 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090924050415.GA14706@omphalos.singularity> References: <20090919223219.GL32370@omphalos.singularity> <20090922035809.GB5402@dillo.org> <20090922064709.GP32370@omphalos.singularity> <20090922162111.GA986@blob.baaderstrasse.com> <20090922163528.GA13919@local.gobigwest.com> <20090922182547.GA8800@dillo.org> <20090924050415.GA14706@omphalos.singularity> Message-ID: <20090925111612.GA3848@dillo.org> On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > Would it be less trouble to have this widget as a child of the UI > > > instead of in the rendering area? (I sort of had the impression > > > that was the plan... > > > > That's exactly the plan. > > > > A simple fltk widget that hides/shows (as the findext bar) and > > that gives a text message. It should also support a fake HTML link > > (underlined word that reacts to left click). > > Ah, I think I misunderstood the reference to "custom widget" in the TO > DO note. I was fixated on the Dillo Widget system and didn't realise > it was talking about a new FLTK widget. Maybe my patch isn't the way > to go. Still, it would be nice for the custom widget to be properly > CSS-styled. Maybe it be could another FltkViewport? As this is part of the UI, I'd suggest to use Xdefaults as Johannes suggested for colors some time ago. -- Cheers Jorge.- From jcid at dillo.org Fri Sep 25 13:39:28 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Sep 25 13:47:58 2009 Subject: [Dillo-dev] Weird chars bug Message-ID: <20090925113928.GB3848@dillo.org> Hi, Since dillo-2.1, enabled-CSS makes funny chars in this page: http://blogdrake.net/node/14916 Screenshot: http://www.dillo.org/test/weirdChars.jpg Disabling it from the tools button solves the problem. Does anybody know what's the problem here? -- Cheers Jorge.- From jcid at dillo.org Fri Sep 25 15:37:41 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Sep 25 15:39:15 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090925111612.GA3848@dillo.org> References: <20090919223219.GL32370@omphalos.singularity> <20090922035809.GB5402@dillo.org> <20090922064709.GP32370@omphalos.singularity> <20090922162111.GA986@blob.baaderstrasse.com> <20090922163528.GA13919@local.gobigwest.com> <20090922182547.GA8800@dillo.org> <20090924050415.GA14706@omphalos.singularity> <20090925111612.GA3848@dillo.org> Message-ID: <20090925133741.GF3848@dillo.org> On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote: > On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > > > Would it be less trouble to have this widget as a child of the UI > > > > instead of in the rendering area? (I sort of had the impression > > > > that was the plan... > > > > > > That's exactly the plan. > > > > > > A simple fltk widget that hides/shows (as the findext bar) and > > > that gives a text message. It should also support a fake HTML link > > > (underlined word that reacts to left click). > > > > Ah, I think I misunderstood the reference to "custom widget" in the TO > > DO note. I was fixated on the Dillo Widget system and didn't realise > > it was talking about a new FLTK widget. Maybe my patch isn't the way > > to go. Still, it would be nice for the custom widget to be properly > > CSS-styled. Maybe it be could another FltkViewport? > > As this is part of the UI, I'd suggest to use Xdefaults as > Johannes suggested for colors some time ago. Ehmmm, by "Xdefaults", I mean the default X resource files. -- Cheers Jorge.- From corvid at lavabit.com Fri Sep 25 20:04:10 2009 From: corvid at lavabit.com (corvid) Date: Fri Sep 25 20:07:57 2009 Subject: [Dillo-dev] Weird chars bug In-Reply-To: <20090925113928.GB3848@dillo.org> References: <20090925113928.GB3848@dillo.org> Message-ID: <20090925180410.GD13919@local.gobigwest.com> Jorge wrote: > Since dillo-2.1, enabled-CSS makes funny chars in this page: > > http://blogdrake.net/node/14916 > > Screenshot: > > http://www.dillo.org/test/weirdChars.jpg > > Disabling it from the tools button solves the problem. > Does anybody know what's the problem here? I suspect it has something to do with the font: 76% Trebuchet MS, Verdana, Arial, Helvetica, sans-serif; in http://blogdrake.net/themes/lightdrake/style.css Of course with my general paucity of fonts, it looks fine to me :) From corvid at lavabit.com Fri Sep 25 20:15:05 2009 From: corvid at lavabit.com (corvid) Date: Fri Sep 25 20:18:51 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090925133741.GF3848@dillo.org> References: <20090919223219.GL32370@omphalos.singularity> <20090922035809.GB5402@dillo.org> <20090922064709.GP32370@omphalos.singularity> <20090922162111.GA986@blob.baaderstrasse.com> <20090922163528.GA13919@local.gobigwest.com> <20090922182547.GA8800@dillo.org> <20090924050415.GA14706@omphalos.singularity> <20090925111612.GA3848@dillo.org> <20090925133741.GF3848@dillo.org> Message-ID: <20090925181505.GE13919@local.gobigwest.com> Jorge wrote: > On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote: > > On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > > > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > > > > > Would it be less trouble to have this widget as a child of the UI > > > > > instead of in the rendering area? (I sort of had the impression > > > > > that was the plan... > > > > > > > > That's exactly the plan. > > > > > > > > A simple fltk widget that hides/shows (as the findext bar) and > > > > that gives a text message. It should also support a fake HTML link > > > > (underlined word that reacts to left click). > > > > > > Ah, I think I misunderstood the reference to "custom widget" in the TO > > > DO note. I was fixated on the Dillo Widget system and didn't realise > > > it was talking about a new FLTK widget. Maybe my patch isn't the way > > > to go. Still, it would be nice for the custom widget to be properly > > > CSS-styled. Maybe it be could another FltkViewport? > > > > As this is part of the UI, I'd suggest to use Xdefaults as > > Johannes suggested for colors some time ago. > > Ehmmm, by "Xdefaults", I mean the default X resource files. ISTR that the latest was that Johannes was trying to get the FLTKers to enable the relevant code that had been commented out (rather than having dillo do it directly), but nothing happened on the fltk side. From jcid at dillo.org Fri Sep 25 23:11:35 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Fri Sep 25 23:13:09 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090925181505.GE13919@local.gobigwest.com> References: <20090919223219.GL32370@omphalos.singularity> <20090922035809.GB5402@dillo.org> <20090922064709.GP32370@omphalos.singularity> <20090922162111.GA986@blob.baaderstrasse.com> <20090922163528.GA13919@local.gobigwest.com> <20090922182547.GA8800@dillo.org> <20090924050415.GA14706@omphalos.singularity> <20090925111612.GA3848@dillo.org> <20090925133741.GF3848@dillo.org> <20090925181505.GE13919@local.gobigwest.com> Message-ID: <20090925211135.GG3848@dillo.org> On Fri, Sep 25, 2009 at 06:15:05PM +0000, corvid wrote: > Jorge wrote: > > On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote: > > > On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > > > > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > > > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > > > > > > > Would it be less trouble to have this widget as a child of the UI > > > > > > instead of in the rendering area? (I sort of had the impression > > > > > > that was the plan... > > > > > > > > > > That's exactly the plan. > > > > > > > > > > A simple fltk widget that hides/shows (as the findext bar) and > > > > > that gives a text message. It should also support a fake HTML link > > > > > (underlined word that reacts to left click). > > > > > > > > Ah, I think I misunderstood the reference to "custom widget" in the TO > > > > DO note. I was fixated on the Dillo Widget system and didn't realise > > > > it was talking about a new FLTK widget. Maybe my patch isn't the way > > > > to go. Still, it would be nice for the custom widget to be properly > > > > CSS-styled. Maybe it be could another FltkViewport? > > > > > > As this is part of the UI, I'd suggest to use Xdefaults as > > > Johannes suggested for colors some time ago. > > > > Ehmmm, by "Xdefaults", I mean the default X resource files. > > ISTR that the latest was that Johannes was trying > to get the FLTKers to enable the relevant code that > had been commented out (rather than having dillo > do it directly), but nothing happened on the fltk side. FLTK2 is dead (that's almost official). Progress will happen in 1.3.x branch (or whatever they chose to call a new branch merging FLTK2 and 1.3.x [1]). In the meanwhile, I'd be OK with a non-themeable warning widget with the same colors it used to have. ;-) FWIW: the patch should implement an fltk widget as described in a previous email. So, no further work on the proposed patch is necessary. [1] http://fltk.org/newsgroups.php?s7257+gfltk.development+v7263+T0 -- Cheers Jorge.- From rogerx at sdf.lonestar.org Sat Sep 26 08:52:11 2009 From: rogerx at sdf.lonestar.org (Roger) Date: Sat Sep 26 08:52:41 2009 Subject: [Dillo-dev] Typing Bug when moving Dillo on DWM's Virtual Desktops Message-ID: <1253947931.32559.5.camel@localhost2.local> I'm finally tackling a typing bug with Dillo, and have found it occurs when moving the Dillo browser to DMW's other virtual desktops. It doesn't occur when Dillo is first started. Nothing, if anything at all, shows within gdb. And, I can't really get to the debug output of DWM as I'm running nvidia proprietary drivers which blanks the terminal once X is started. I do have a laptop for which I can further investigate the DWM debug data, but figured I should post what I know to see if any of you notice similar. The basic bug scenario, move the Dillo browser to another Virtual Desktop within DWM and start typing (within the url field or within the Google search field.) I notice only certain keys type their characters and most others will either type nothing or may clear the entire field (ie. clear line) Possible a meta key sticks when moving the browser to another desktop?? -- Roger http://rogerx.freeshell.org From jcid at dillo.org Sat Sep 26 14:46:38 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sat Sep 26 14:47:13 2009 Subject: [Dillo-dev] Typing Bug when moving Dillo on DWM's Virtual Desktops In-Reply-To: <1253947931.32559.5.camel@localhost2.local> References: <1253947931.32559.5.camel@localhost2.local> Message-ID: <20090926124638.GA3594@dillo.org> Hi Roger, On Fri, Sep 25, 2009 at 10:52:11PM -0800, Roger wrote: > I'm finally tackling a typing bug with Dillo, and have found it occurs > when moving the Dillo browser to DMW's other virtual desktops. > > It doesn't occur when Dillo is first started. > > Nothing, if anything at all, shows within gdb. > > > And, I can't really get to the debug output of DWM as I'm running nvidia > proprietary drivers which blanks the terminal once X is started. I do > have a laptop for which I can further investigate the DWM debug data, > but figured I should post what I know to see if any of you notice > similar. > > > The basic bug scenario, move the Dillo browser to another Virtual > Desktop within DWM and start typing (within the url field or within the > Google search field.) I notice only certain keys type their characters > and most others will either type nothing or may clear the entire field > (ie. clear line) > > Possible a meta key sticks when moving the browser to another desktop?? It could be a bug in dwm, fltk2 or dillo. I assume you're using dillo2 (the FLTK2-based one). The dillo UI widgets you describe to fail are plain FLTK2 objects, so please do the following test: * Get to the fltk2 compilation directory and run test/input program, and then try to reproduce the bug as with dillo. -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Sun Sep 27 15:31:12 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sun Sep 27 15:33:33 2009 Subject: [Dillo-dev] Typing Bug when moving Dillo on DWM's Virtual Desktops In-Reply-To: <20090926124638.GA3594@dillo.org> References: <1253947931.32559.5.camel@localhost2.local> <20090926124638.GA3594@dillo.org> Message-ID: <20090927133112.GB1021@blob.baaderstrasse.com> On Sat, Sep 26, 2009 at 08:46:38AM -0400, Jorge Arellano Cid wrote: > Hi Roger, > > On Fri, Sep 25, 2009 at 10:52:11PM -0800, Roger wrote: > > I'm finally tackling a typing bug with Dillo, and have found it occurs > > when moving the Dillo browser to DMW's other virtual desktops. > > > > It doesn't occur when Dillo is first started. > > > > Nothing, if anything at all, shows within gdb. > > > > > > And, I can't really get to the debug output of DWM as I'm running nvidia > > proprietary drivers which blanks the terminal once X is started. I do > > have a laptop for which I can further investigate the DWM debug data, > > but figured I should post what I know to see if any of you notice > > similar. > > > > > > The basic bug scenario, move the Dillo browser to another Virtual > > Desktop within DWM and start typing (within the url field or within the > > Google search field.) I notice only certain keys type their characters > > and most others will either type nothing or may clear the entire field > > (ie. clear line) > > > > Possible a meta key sticks when moving the browser to another desktop?? > > It could be a bug in dwm, fltk2 or dillo. > > I assume you're using dillo2 (the FLTK2-based one). The dillo > UI widgets you describe to fail are plain FLTK2 objects, so > please do the following test: > > * Get to the fltk2 compilation directory and run test/input > program, and then try to reproduce the bug as with dillo. I quickly tried to reproduce the problem as I also use dwm, but could not see any problem until now. I opened dillo, focused the url field, send dillo to another tag with e.g. Alt-Shift 2, then went activated tag 2 with Alt 2, and continued typing. This seems to work here. Are you using the mouse maybe? Cheers, Johannes From Johannes.Hofmann at gmx.de Sun Sep 27 15:35:49 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sun Sep 27 15:38:15 2009 Subject: [Dillo-dev] Weird chars bug In-Reply-To: <20090925180410.GD13919@local.gobigwest.com> References: <20090925113928.GB3848@dillo.org> <20090925180410.GD13919@local.gobigwest.com> Message-ID: <20090927133548.GC1021@blob.baaderstrasse.com> On Fri, Sep 25, 2009 at 06:04:10PM +0000, corvid wrote: > Jorge wrote: > > Since dillo-2.1, enabled-CSS makes funny chars in this page: > > > > http://blogdrake.net/node/14916 > > > > Screenshot: > > > > http://www.dillo.org/test/weirdChars.jpg > > > > Disabling it from the tools button solves the problem. > > Does anybody know what's the problem here? > > I suspect it has something to do with the > font: 76% Trebuchet MS, Verdana, Arial, Helvetica, sans-serif; > in http://blogdrake.net/themes/lightdrake/style.css > > Of course with my general paucity of fonts, it looks fine to me :) Looks ok here too. Somehow dillo seems to pick some weird font on your system, that can't properly display the characters. There are quite a few open issues in the font selection code of dillo. Cheers, Johannes From Johannes.Hofmann at gmx.de Sun Sep 27 15:43:32 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Sun Sep 27 15:45:53 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090925211135.GG3848@dillo.org> References: <20090922035809.GB5402@dillo.org> <20090922064709.GP32370@omphalos.singularity> <20090922162111.GA986@blob.baaderstrasse.com> <20090922163528.GA13919@local.gobigwest.com> <20090922182547.GA8800@dillo.org> <20090924050415.GA14706@omphalos.singularity> <20090925111612.GA3848@dillo.org> <20090925133741.GF3848@dillo.org> <20090925181505.GE13919@local.gobigwest.com> <20090925211135.GG3848@dillo.org> Message-ID: <20090927134332.GD1021@blob.baaderstrasse.com> On Fri, Sep 25, 2009 at 05:11:35PM -0400, Jorge Arellano Cid wrote: > On Fri, Sep 25, 2009 at 06:15:05PM +0000, corvid wrote: > > Jorge wrote: > > > On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote: > > > > On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > > > > > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > > > > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > > > > > > > > > Would it be less trouble to have this widget as a child of the UI > > > > > > > instead of in the rendering area? (I sort of had the impression > > > > > > > that was the plan... > > > > > > > > > > > > That's exactly the plan. > > > > > > > > > > > > A simple fltk widget that hides/shows (as the findext bar) and > > > > > > that gives a text message. It should also support a fake HTML link > > > > > > (underlined word that reacts to left click). > > > > > > > > > > Ah, I think I misunderstood the reference to "custom widget" in the TO > > > > > DO note. I was fixated on the Dillo Widget system and didn't realise > > > > > it was talking about a new FLTK widget. Maybe my patch isn't the way > > > > > to go. Still, it would be nice for the custom widget to be properly > > > > > CSS-styled. Maybe it be could another FltkViewport? > > > > > > > > As this is part of the UI, I'd suggest to use Xdefaults as > > > > Johannes suggested for colors some time ago. > > > > > > Ehmmm, by "Xdefaults", I mean the default X resource files. > > > > ISTR that the latest was that Johannes was trying > > to get the FLTKers to enable the relevant code that > > had been commented out (rather than having dillo > > do it directly), but nothing happened on the fltk side. > > FLTK2 is dead (that's almost official). > > Progress will happen in 1.3.x branch (or whatever they chose to > call a new branch merging FLTK2 and 1.3.x [1]). > > In the meanwhile, I'd be OK with a non-themeable warning widget > with the same colors it used to have. ;-) > > FWIW: the patch should implement an fltk widget as described in > a previous email. So, no further work on the proposed patch is > necessary. You proposed a popup bar similar to the search bar, right? Do we really need to create a completly new mechansim for user notifications? Currently we have: * window title * status bar * popup Windows (from dpi's) I think we should try to keep the UI simple and consistent by reducing the number of concepts. Cheers, Johannes PS: I recently tried http://surf.suckless.org/ and I'm rather impressed by the minimal UI. From corvid at lavabit.com Sun Sep 27 17:52:38 2009 From: corvid at lavabit.com (corvid) Date: Sun Sep 27 17:56:24 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090927134332.GD1021@blob.baaderstrasse.com> References: <20090922064709.GP32370@omphalos.singularity> <20090922162111.GA986@blob.baaderstrasse.com> <20090922163528.GA13919@local.gobigwest.com> <20090922182547.GA8800@dillo.org> <20090924050415.GA14706@omphalos.singularity> <20090925111612.GA3848@dillo.org> <20090925133741.GF3848@dillo.org> <20090925181505.GE13919@local.gobigwest.com> <20090925211135.GG3848@dillo.org> <20090927134332.GD1021@blob.baaderstrasse.com> Message-ID: <20090927155238.GG13919@local.gobigwest.com> Johannes wrote: > On Fri, Sep 25, 2009 at 05:11:35PM -0400, Jorge Arellano Cid wrote: > > On Fri, Sep 25, 2009 at 06:15:05PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote: > > > > > On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > > > > > > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > > > > > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > > > > > > > > > > > Would it be less trouble to have this widget as a child of the UI > > > > > > > > instead of in the rendering area? (I sort of had the impression > > > > > > > > that was the plan... > > > > > > > > > > > > > > That's exactly the plan. > > > > > > > > > > > > > > A simple fltk widget that hides/shows (as the findext bar) and > > > > > > > that gives a text message. It should also support a fake HTML link > > > > > > > (underlined word that reacts to left click). > > > > > > > > > > > > Ah, I think I misunderstood the reference to "custom widget" in the TO > > > > > > DO note. I was fixated on the Dillo Widget system and didn't realise > > > > > > it was talking about a new FLTK widget. Maybe my patch isn't the way > > > > > > to go. Still, it would be nice for the custom widget to be properly > > > > > > CSS-styled. Maybe it be could another FltkViewport? > > > > > > > > > > As this is part of the UI, I'd suggest to use Xdefaults as > > > > > Johannes suggested for colors some time ago. > > > > > > > > Ehmmm, by "Xdefaults", I mean the default X resource files. > > > > > > ISTR that the latest was that Johannes was trying > > > to get the FLTKers to enable the relevant code that > > > had been commented out (rather than having dillo > > > do it directly), but nothing happened on the fltk side. > > > > FLTK2 is dead (that's almost official). > > > > Progress will happen in 1.3.x branch (or whatever they chose to > > call a new branch merging FLTK2 and 1.3.x [1]). > > > > In the meanwhile, I'd be OK with a non-themeable warning widget > > with the same colors it used to have. ;-) > > > > FWIW: the patch should implement an fltk widget as described in > > a previous email. So, no further work on the proposed patch is > > necessary. > > You proposed a popup bar similar to the search bar, right? > Do we really need to create a completly new mechansim for user > notifications? Currently we have: > > * window title > * status bar > * popup Windows (from dpi's) > > I think we should try to keep the UI simple and consistent by > reducing the number of concepts. Maybe it would be nice if popup windows turned into something like a popup bar. > PS: I recently tried http://surf.suckless.org/ and I'm rather > impressed by the minimal UI. I read a little about surf and uzbl recently, but then webkit was too big for me to want to download. (Surprised a person would intentionally name a browser 'surf' nowadays. I had thought of web "surfing" as a term as thankfully dead and buried as "information superhighway" or "cyberspace".) From rogutes at googlemail.com Sun Sep 27 19:39:45 2009 From: rogutes at googlemail.com (=?utf-8?Q?Rogut=C4=97s?= Sparnuotos) Date: Sun Sep 27 19:40:42 2009 Subject: [Dillo-dev] Typing Bug when moving Dillo on DWM's Virtual Desktops In-Reply-To: <20090927133112.GB1021@blob.baaderstrasse.com> References: <1253947931.32559.5.camel@localhost2.local> <20090926124638.GA3594@dillo.org> <20090927133112.GB1021@blob.baaderstrasse.com> Message-ID: <20090927173945.GA4680@urvas> Johannes Hofmann (2009-09-27 15:31): > On Sat, Sep 26, 2009 at 08:46:38AM -0400, Jorge Arellano Cid wrote: > > Hi Roger, > > > > On Fri, Sep 25, 2009 at 10:52:11PM -0800, Roger wrote: > > > I'm finally tackling a typing bug with Dillo, and have found it occurs > > > when moving the Dillo browser to DMW's other virtual desktops. > > > > > > It doesn't occur when Dillo is first started. > > > > > > Nothing, if anything at all, shows within gdb. > > > > > > > > > And, I can't really get to the debug output of DWM as I'm running nvidia > > > proprietary drivers which blanks the terminal once X is started. I do > > > have a laptop for which I can further investigate the DWM debug data, > > > but figured I should post what I know to see if any of you notice > > > similar. > > > > > > > > > The basic bug scenario, move the Dillo browser to another Virtual > > > Desktop within DWM and start typing (within the url field or within the > > > Google search field.) I notice only certain keys type their characters > > > and most others will either type nothing or may clear the entire field > > > (ie. clear line) > > > > > > Possible a meta key sticks when moving the browser to another desktop?? > > > > It could be a bug in dwm, fltk2 or dillo. > > > > I assume you're using dillo2 (the FLTK2-based one). The dillo > > UI widgets you describe to fail are plain FLTK2 objects, so > > please do the following test: > > > > * Get to the fltk2 compilation directory and run test/input > > program, and then try to reproduce the bug as with dillo. > > I quickly tried to reproduce the problem as I also use dwm, but > could not see any problem until now. > I opened dillo, focused the url field, send dillo to another tag > with e.g. Alt-Shift 2, then went activated tag 2 with Alt 2, and > continued typing. This seems to work here. > Are you using the mouse maybe? I've mentioned this bug some months ago and corvid seemed to confirm seeing it. Unfortunately, I still haven't found any way to reliably reproduce it, and what Roger writes doesn't trigger it here. I've seen this bug under dwm and xmonad, haven't used other WM's with dillo. Whenever this bug is triggered, the keyboard behaves as if a modifier was stuck: keyboard input seems to generate no response, until one tries to type in input boxes (e.g. the location bar). There, typing 'a' goes to the beginning of the line, 'e' goes to the end, etc., as if some modifier was pressed (e.g. try pressing u, or u, or u in the location bar with some text). -- -- Rogut?s Sparnuotos From corvid at lavabit.com Sun Sep 27 19:59:47 2009 From: corvid at lavabit.com (corvid) Date: Sun Sep 27 20:03:32 2009 Subject: [Dillo-dev] Typing Bug when moving Dillo on DWM's Virtual Desktops In-Reply-To: <20090927173945.GA4680@urvas> References: <1253947931.32559.5.camel@localhost2.local> <20090926124638.GA3594@dillo.org> <20090927133112.GB1021@blob.baaderstrasse.com> <20090927173945.GA4680@urvas> Message-ID: <20090927175947.GA26107@local.gobigwest.com> Rogut?s wrote: > Johannes Hofmann (2009-09-27 15:31): > > On Sat, Sep 26, 2009 at 08:46:38AM -0400, Jorge Arellano Cid wrote: > > > Hi Roger, > > > > > > On Fri, Sep 25, 2009 at 10:52:11PM -0800, Roger wrote: > > > > I'm finally tackling a typing bug with Dillo, and have found it occurs > > > > when moving the Dillo browser to DMW's other virtual desktops. > > > > > > > > It doesn't occur when Dillo is first started. > > > > > > > > Nothing, if anything at all, shows within gdb. > > > > > > > > > > > > And, I can't really get to the debug output of DWM as I'm running nvidia > > > > proprietary drivers which blanks the terminal once X is started. I do > > > > have a laptop for which I can further investigate the DWM debug data, > > > > but figured I should post what I know to see if any of you notice > > > > similar. > > > > > > > > > > > > The basic bug scenario, move the Dillo browser to another Virtual > > > > Desktop within DWM and start typing (within the url field or within the > > > > Google search field.) I notice only certain keys type their characters > > > > and most others will either type nothing or may clear the entire field > > > > (ie. clear line) > > > > > > > > Possible a meta key sticks when moving the browser to another desktop?? > > > > > > It could be a bug in dwm, fltk2 or dillo. > > > > > > I assume you're using dillo2 (the FLTK2-based one). The dillo > > > UI widgets you describe to fail are plain FLTK2 objects, so > > > please do the following test: > > > > > > * Get to the fltk2 compilation directory and run test/input > > > program, and then try to reproduce the bug as with dillo. > > > > I quickly tried to reproduce the problem as I also use dwm, but > > could not see any problem until now. > > I opened dillo, focused the url field, send dillo to another tag > > with e.g. Alt-Shift 2, then went activated tag 2 with Alt 2, and > > continued typing. This seems to work here. > > Are you using the mouse maybe? > > I've mentioned this bug some months ago and corvid seemed to confirm > seeing it. Unfortunately, I still haven't found any way to reliably > reproduce it, and what Roger writes doesn't trigger it here. I've seen > this bug under dwm and xmonad, haven't used other WM's with dillo. > > Whenever this bug is triggered, the keyboard behaves as if a modifier > was stuck: keyboard input seems to generate no response, until one tries > to type in input boxes (e.g. the location bar). There, typing 'a' goes > to the beginning of the line, 'e' goes to the end, etc., as if some > modifier was pressed (e.g. try pressing u, or u, or u > in the location bar with some text). Yeah, I can still get into the situation if I play around with modifiers and switching virtual desktops (fvwm) with enough determination and persistence, but it's no longer easy, and when I repeat what I think just made it break, it'll fail to break again. From jcid at dillo.org Sun Sep 27 21:59:28 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Sep 27 22:00:10 2009 Subject: [Dillo-dev] Typing Bug when moving Dillo on DWM's Virtual Desktops In-Reply-To: <20090927175947.GA26107@local.gobigwest.com> References: <1253947931.32559.5.camel@localhost2.local> <20090926124638.GA3594@dillo.org> <20090927133112.GB1021@blob.baaderstrasse.com> <20090927173945.GA4680@urvas> <20090927175947.GA26107@local.gobigwest.com> Message-ID: <20090927195928.GA20431@dillo.org> On Sun, Sep 27, 2009 at 05:59:47PM +0000, corvid wrote: > Rogut??s wrote: > > Johannes Hofmann (2009-09-27 15:31): > > > On Sat, Sep 26, 2009 at 08:46:38AM -0400, Jorge Arellano Cid wrote: > > > > Hi Roger, > > > > > > > > On Fri, Sep 25, 2009 at 10:52:11PM -0800, Roger wrote: > > > > > I'm finally tackling a typing bug with Dillo, and have found it occurs > > > > > when moving the Dillo browser to DMW's other virtual desktops. > > > > > > > > > > It doesn't occur when Dillo is first started. > > > > > > > > > > Nothing, if anything at all, shows within gdb. > > > > > > > > > > > > > > > And, I can't really get to the debug output of DWM as I'm running nvidia > > > > > proprietary drivers which blanks the terminal once X is started. I do > > > > > have a laptop for which I can further investigate the DWM debug data, > > > > > but figured I should post what I know to see if any of you notice > > > > > similar. > > > > > > > > > > > > > > > The basic bug scenario, move the Dillo browser to another Virtual > > > > > Desktop within DWM and start typing (within the url field or within the > > > > > Google search field.) I notice only certain keys type their characters > > > > > and most others will either type nothing or may clear the entire field > > > > > (ie. clear line) > > > > > > > > > > Possible a meta key sticks when moving the browser to another desktop?? > > > > > > > > It could be a bug in dwm, fltk2 or dillo. > > > > > > > > I assume you're using dillo2 (the FLTK2-based one). The dillo > > > > UI widgets you describe to fail are plain FLTK2 objects, so > > > > please do the following test: > > > > > > > > * Get to the fltk2 compilation directory and run test/input > > > > program, and then try to reproduce the bug as with dillo. > > > > > > I quickly tried to reproduce the problem as I also use dwm, but > > > could not see any problem until now. > > > I opened dillo, focused the url field, send dillo to another tag > > > with e.g. Alt-Shift 2, then went activated tag 2 with Alt 2, and > > > continued typing. This seems to work here. > > > Are you using the mouse maybe? > > > > I've mentioned this bug some months ago and corvid seemed to confirm > > seeing it. Unfortunately, I still haven't found any way to reliably > > reproduce it, and what Roger writes doesn't trigger it here. I've seen > > this bug under dwm and xmonad, haven't used other WM's with dillo. > > > > Whenever this bug is triggered, the keyboard behaves as if a modifier > > was stuck: keyboard input seems to generate no response, until one tries > > to type in input boxes (e.g. the location bar). There, typing 'a' goes > > to the beginning of the line, 'e' goes to the end, etc., as if some > > modifier was pressed (e.g. try pressing u, or u, or u > > in the location bar with some text). > > Yeah, I can still get into the situation if I play around with > modifiers and switching virtual desktops (fvwm) with enough > determination and persistence, but it's no longer easy, > and when I repeat what I think just made it break, it'll > fail to break again. Hmmm, if it's reproduceable with the test/input program, it's something in FLTK2. If test/input doesn't show the bug, a good test would be to make the location an fltk::Input (instead of CustInput) and try it. If there's no bug, it may be CustInput::handle(). If the bug shows then I'd blame fltk2, but who knows? :-) -- Cheers Jorge.- From jcid at dillo.org Sun Sep 27 22:14:29 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Sun Sep 27 22:15:04 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090927155238.GG13919@local.gobigwest.com> References: <20090922162111.GA986@blob.baaderstrasse.com> <20090922163528.GA13919@local.gobigwest.com> <20090922182547.GA8800@dillo.org> <20090924050415.GA14706@omphalos.singularity> <20090925111612.GA3848@dillo.org> <20090925133741.GF3848@dillo.org> <20090925181505.GE13919@local.gobigwest.com> <20090925211135.GG3848@dillo.org> <20090927134332.GD1021@blob.baaderstrasse.com> <20090927155238.GG13919@local.gobigwest.com> Message-ID: <20090927201429.GB20431@dillo.org> On Sun, Sep 27, 2009 at 03:52:38PM +0000, corvid wrote: > Johannes wrote: > > On Fri, Sep 25, 2009 at 05:11:35PM -0400, Jorge Arellano Cid wrote: > > > On Fri, Sep 25, 2009 at 06:15:05PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote: > > > > > > On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > > > > > > > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > > > > > > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > > > > > > > > > > > > > Would it be less trouble to have this widget as a child of the UI > > > > > > > > > instead of in the rendering area? (I sort of had the impression > > > > > > > > > that was the plan... > > > > > > > > > > > > > > > > That's exactly the plan. > > > > > > > > > > > > > > > > A simple fltk widget that hides/shows (as the findext bar) and > > > > > > > > that gives a text message. It should also support a fake HTML link > > > > > > > > (underlined word that reacts to left click). > > > > > > > > > > > > > > Ah, I think I misunderstood the reference to "custom widget" in the TO > > > > > > > DO note. I was fixated on the Dillo Widget system and didn't realise > > > > > > > it was talking about a new FLTK widget. Maybe my patch isn't the way > > > > > > > to go. Still, it would be nice for the custom widget to be properly > > > > > > > CSS-styled. Maybe it be could another FltkViewport? > > > > > > > > > > > > As this is part of the UI, I'd suggest to use Xdefaults as > > > > > > Johannes suggested for colors some time ago. > > > > > > > > > > Ehmmm, by "Xdefaults", I mean the default X resource files. > > > > > > > > ISTR that the latest was that Johannes was trying > > > > to get the FLTKers to enable the relevant code that > > > > had been commented out (rather than having dillo > > > > do it directly), but nothing happened on the fltk side. > > > > > > FLTK2 is dead (that's almost official). > > > > > > Progress will happen in 1.3.x branch (or whatever they chose to > > > call a new branch merging FLTK2 and 1.3.x [1]). > > > > > > In the meanwhile, I'd be OK with a non-themeable warning widget > > > with the same colors it used to have. ;-) > > > > > > FWIW: the patch should implement an fltk widget as described in > > > a previous email. So, no further work on the proposed patch is > > > necessary. > > > > You proposed a popup bar similar to the search bar, right? > > Do we really need to create a completly new mechansim for user > > notifications? Currently we have: > > > > * window title > > * status bar > > * popup Windows (from dpi's) > > > > I think we should try to keep the UI simple and consistent by > > reducing the number of concepts. I agree on consistency, and hopefully a reduced number of concepts. * window title Most probably unnoticed and no way to put a link there. * status bar Too ephemeral and no link too. * popup Window IMHO: Too intrusive for the user. The popup bar is the same concept as for findtext and the control panel. In this case we're reducing the number of concepts by taking out one UI element (injected HTML) and replacing it with a popup bar. > Maybe it would be nice if popup windows turned into something like > a popup bar. This could reduce the number of concepts even further, but not for "Open file", "save page", "save page as...", and downloads. It requires some thought (on the possible gain/loss/effort)... -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Mon Sep 28 18:12:35 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Mon Sep 28 18:14:58 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090927155238.GG13919@local.gobigwest.com> References: <20090922162111.GA986@blob.baaderstrasse.com> <20090922163528.GA13919@local.gobigwest.com> <20090922182547.GA8800@dillo.org> <20090924050415.GA14706@omphalos.singularity> <20090925111612.GA3848@dillo.org> <20090925133741.GF3848@dillo.org> <20090925181505.GE13919@local.gobigwest.com> <20090925211135.GG3848@dillo.org> <20090927134332.GD1021@blob.baaderstrasse.com> <20090927155238.GG13919@local.gobigwest.com> Message-ID: <20090928161235.GA936@blob.baaderstrasse.com> On Sun, Sep 27, 2009 at 03:52:38PM +0000, corvid wrote: > Johannes wrote: > > You proposed a popup bar similar to the search bar, right? > > Do we really need to create a completly new mechansim for user > > notifications? Currently we have: > > > > * window title > > * status bar > > * popup Windows (from dpi's) > > > > I think we should try to keep the UI simple and consistent by > > reducing the number of concepts. > > Maybe it would be nice if popup windows turned into something like > a popup bar. Sounds good to me. So we would just have alternative implementations for a_Dialog_msg a_Dialog_choice3 a_Dialog_choice5 a_Dialog_user_password a_Dialog_input a_Dialog_passwd > > > > PS: I recently tried http://surf.suckless.org/ and I'm rather > > impressed by the minimal UI. > > I read a little about surf and uzbl recently, but then webkit > was too big for me to want to download. Yes, it's quite large. > > (Surprised a person would intentionally name a browser 'surf' > nowadays. I had thought of web "surfing" as a term as thankfully > dead and buried as "information superhighway" or "cyberspace".) good point :-) From Johannes.Hofmann at gmx.de Mon Sep 28 18:18:00 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Mon Sep 28 18:20:22 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090927201429.GB20431@dillo.org> References: <20090922163528.GA13919@local.gobigwest.com> <20090922182547.GA8800@dillo.org> <20090924050415.GA14706@omphalos.singularity> <20090925111612.GA3848@dillo.org> <20090925133741.GF3848@dillo.org> <20090925181505.GE13919@local.gobigwest.com> <20090925211135.GG3848@dillo.org> <20090927134332.GD1021@blob.baaderstrasse.com> <20090927155238.GG13919@local.gobigwest.com> <20090927201429.GB20431@dillo.org> Message-ID: <20090928161800.GB936@blob.baaderstrasse.com> On Sun, Sep 27, 2009 at 04:14:29PM -0400, Jorge Arellano Cid wrote: > > I agree on consistency, and hopefully a reduced number of concepts. > > > * window title > Most probably unnoticed and no way to put a link there. > * status bar > Too ephemeral and no link too. > * popup Window > IMHO: Too intrusive for the user. > > The popup bar is the same concept as for findtext and the > control panel. > > In this case we're reducing the number of concepts by taking > out one UI element (injected HTML) and replacing it with a popup > bar. > > > > Maybe it would be nice if popup windows turned into something like > > a popup bar. > > This could reduce the number of concepts even further, but not > for "Open file", "save page", "save page as...", and downloads. I fully agree, but a_Dialog_msg a_Dialog_choice3 a_Dialog_choice5 a_Dialog_user_password a_Dialog_input a_Dialog_passwd should all use the same look and feel (and code) either popup window or popup bar based. BTW. How could we handle multiple popupbars? > > It requires some thought (on the possible gain/loss/effort)... One drawback of the popup bar is the additional resize / redraw of the rendering area. Cheers, Johannes From corvid at lavabit.com Mon Sep 28 18:58:40 2009 From: corvid at lavabit.com (corvid) Date: Mon Sep 28 19:02:27 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090928161800.GB936@blob.baaderstrasse.com> References: <20090922182547.GA8800@dillo.org> <20090924050415.GA14706@omphalos.singularity> <20090925111612.GA3848@dillo.org> <20090925133741.GF3848@dillo.org> <20090925181505.GE13919@local.gobigwest.com> <20090925211135.GG3848@dillo.org> <20090927134332.GD1021@blob.baaderstrasse.com> <20090927155238.GG13919@local.gobigwest.com> <20090927201429.GB20431@dillo.org> <20090928161800.GB936@blob.baaderstrasse.com> Message-ID: <20090928165839.GD26113@local.gobigwest.com> Johannes wrote: > a_Dialog_msg > a_Dialog_choice3 > a_Dialog_choice5 > a_Dialog_user_password > a_Dialog_input > a_Dialog_passwd > > should all use the same look and feel (and code) either popup window > or popup bar based. > BTW. How could we handle multiple popupbars? Yeah, that might require a little more cleverness than we would really prefer to implement -- although when I was playing with same_domain with image loading on, I did get one of those ssl warning bombings, and boy are they definitely no fun at all as separate windows. From onepoint at starurchin.org Mon Sep 28 20:22:29 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Mon Sep 28 20:23:25 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090928161800.GB936@blob.baaderstrasse.com> References: <20090922182547.GA8800@dillo.org> <20090924050415.GA14706@omphalos.singularity> <20090925111612.GA3848@dillo.org> <20090925133741.GF3848@dillo.org> <20090925181505.GE13919@local.gobigwest.com> <20090925211135.GG3848@dillo.org> <20090927134332.GD1021@blob.baaderstrasse.com> <20090927155238.GG13919@local.gobigwest.com> <20090927201429.GB20431@dillo.org> <20090928161800.GB936@blob.baaderstrasse.com> Message-ID: <20090928182229.GB6839@omphalos.singularity> On Mon, Sep 28, 2009 at 06:18:00PM +0200, Johannes Hofmann wrote: > I fully agree, but > > a_Dialog_msg > a_Dialog_choice3 > a_Dialog_choice5 > a_Dialog_user_password > a_Dialog_input > a_Dialog_passwd > > should all use the same look and feel (and code) either popup window > or popup bar based. BTW. How could we handle multiple popupbars? Don't forget that one page can pop up multiple simultaneous dialogs (because although the modal dialog locks the GUI, it doesn't stop the IO callbacks from running). That's not a problem when each call to a_Dialog_*() pops up its own dialog, but what happens when several of them want to use the same popup bar? I guess each popup bar will have to manage a list of concurrent requests instead of just one. Regards, Jeremy Henty From jcid at dillo.org Mon Sep 28 20:29:51 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Mon Sep 28 20:30:28 2009 Subject: [Dillo-dev] [patch]: fix the meta-refresh warning code In-Reply-To: <20090928182229.GB6839@omphalos.singularity> References: <20090924050415.GA14706@omphalos.singularity> <20090925111612.GA3848@dillo.org> <20090925133741.GF3848@dillo.org> <20090925181505.GE13919@local.gobigwest.com> <20090925211135.GG3848@dillo.org> <20090927134332.GD1021@blob.baaderstrasse.com> <20090927155238.GG13919@local.gobigwest.com> <20090927201429.GB20431@dillo.org> <20090928161800.GB936@blob.baaderstrasse.com> <20090928182229.GB6839@omphalos.singularity> Message-ID: <20090928182951.GC4505@dillo.org> On Mon, Sep 28, 2009 at 07:22:29PM +0100, Jeremy Henty wrote: > On Mon, Sep 28, 2009 at 06:18:00PM +0200, Johannes Hofmann wrote: > > > I fully agree, but > > > > a_Dialog_msg > > a_Dialog_choice3 > > a_Dialog_choice5 > > a_Dialog_user_password > > a_Dialog_input > > a_Dialog_passwd > > > > should all use the same look and feel (and code) either popup window > > or popup bar based. BTW. How could we handle multiple popupbars? > > Don't forget that one page can pop up multiple simultaneous dialogs > (because although the modal dialog locks the GUI, it doesn't stop the > IO callbacks from running). That's not a problem when each call to > a_Dialog_*() pops up its own dialog, but what happens when several of > them want to use the same popup bar? I guess each popup bar will have > to manage a list of concurrent requests instead of just one. Yes, it comes with effort. I'd say let's have the popup bar for META refresh (and faulty XHTML) and keep the popup dialogs. Now, if someone ;), comes with a better idea, with implementation, it'd be good to look into. BTW, I'm working on the dpi/dpip part (lots of things). Hopefully I'll come up with a solution for the dialog bombing among the bunch of patches/code-changes in my queue. -- Cheers Jorge.- From onepoint at starurchin.org Mon Sep 28 21:01:19 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Mon Sep 28 21:02:12 2009 Subject: [Dillo-dev] What's the status of USE_TABLES? Message-ID: <20090928190119.GD6839@omphalos.singularity> This came up as an aside to the meta refresh discussion in another thread: is USE_TABLES obsolete or not? If it is, we should remove it, if not, it should be hooked to a configure flag. I'll submit a patch as soon as someone tells me which way to go. Regards, Jeremy Henty From higuita7 at yahoo.co.uk Mon Sep 28 22:49:20 2009 From: higuita7 at yahoo.co.uk (higuita) Date: Mon Sep 28 22:50:25 2009 Subject: [Dillo-dev] Typing Bug when moving Dillo on DWM's Virtual Desktops In-Reply-To: <20090927173945.GA4680@urvas> References: <1253947931.32559.5.camel@localhost2.local> <20090926124638.GA3594@dillo.org> <20090927133112.GB1021@blob.baaderstrasse.com> <20090927173945.GA4680@urvas> Message-ID: <20090928214920.1bf97dcc@Couracado.homelinux.net> hi all On Sun, 27 Sep 2009 20:39:45 +0300, Rogut?s Sparnuotos wrote: > Whenever this bug is triggered, the keyboard behaves as if a modifier > was stuck: seens like the numlock problem i had... try to play with it and other modifiers, like scrool-lock, meta, shifts, etc good luck higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available Url : /pipermail/attachments/20090928/5a11ba1b/signature.pgp From rogutes at googlemail.com Mon Sep 28 23:54:33 2009 From: rogutes at googlemail.com (=?utf-8?Q?Rogut=C4=97s?= Sparnuotos) Date: Mon Sep 28 23:55:24 2009 Subject: [Dillo-dev] Bug: ScrollLock modifier messes up mouse input [was: Typing Bug ...] In-Reply-To: <20090928214920.1bf97dcc@Couracado.homelinux.net> References: <1253947931.32559.5.camel@localhost2.local> <20090926124638.GA3594@dillo.org> <20090927133112.GB1021@blob.baaderstrasse.com> <20090927173945.GA4680@urvas> <20090928214920.1bf97dcc@Couracado.homelinux.net> Message-ID: <20090928215433.GA11870@urvas> higuita (2009-09-28 21:49): > hi all > > On Sun, 27 Sep 2009 20:39:45 +0300, Rogut?s Sparnuotos wrote: > > Whenever this bug is triggered, the keyboard behaves as if a modifier > > was stuck: > > seens like the numlock problem i had... try to play with it > and other modifiers, like scrool-lock, meta, shifts, etc Thanks for the hint, but I wasn't able to trigger the bug with stuck modifiers while trying out various combinations of them. But I have found a different problem with ScrollLock: whenever the ScrollLock LED is switched on, mouse input behaves as if the first mouse button was pressed (i.e. the mouse becomes unusable). I use ScrollLock with XKB: it is lit when I switch keyboard layouts, and it is configured with this line in xorg.conf: Option "XkbOptions" "grp_led:scroll" -- -- Rogut?s Sparnuotos From corvid at lavabit.com Tue Sep 29 10:03:53 2009 From: corvid at lavabit.com (corvid) Date: Tue Sep 29 10:07:44 2009 Subject: [Dillo-dev] experimental patch: zero width space (Thai, Lao, Cambodian...) Message-ID: <20090929080353.GE26113@local.gobigwest.com> I just learned that some languages don't use spaces but can only break in certain places, and that they tend to insert Zero Width Space to make life easier for software that doesn't know the complex rules. So here's a quick little patch for them: http://www.dillo.org/test/zero_width_space.patch PS I did just start trying to move the ideographic test to dw, but I got stuck when I realized that I can't exactly call fltk's utf8decode() directly in Textblock, and am not excited by the idea of calling it through Layout. From jcid at dillo.org Tue Sep 29 18:53:44 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Sep 29 18:54:20 2009 Subject: [Dillo-dev] What's the status of USE_TABLES? In-Reply-To: <20090928190119.GD6839@omphalos.singularity> References: <20090928190119.GD6839@omphalos.singularity> Message-ID: <20090929165344.GA4104@dillo.org> On Mon, Sep 28, 2009 at 08:01:19PM +0100, Jeremy Henty wrote: > > This came up as an aside to the meta refresh discussion in another > thread: is USE_TABLES obsolete or not? If it is, we should remove it, > if not, it should be hooked to a configure flag. I'll submit a patch > as soon as someone tells me which way to go. OK remove it. I hesitated because it was useful long ago. OTOH it's broken and a custom CSS template seems a better solution for the problem it tried to solve. -- Cheers Jorge.- From Johannes.Hofmann at gmx.de Tue Sep 29 19:52:57 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Sep 29 19:55:20 2009 Subject: [Dillo-dev] experimental patch: zero width space (Thai, Lao, Cambodian...) In-Reply-To: <20090929080353.GE26113@local.gobigwest.com> References: <20090929080353.GE26113@local.gobigwest.com> Message-ID: <20090929175257.GA1262@blob.baaderstrasse.com> On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote: > I just learned that some languages don't use spaces but can only > break in certain places, and that they tend to insert > Zero Width Space to make life easier for software that > doesn't know the complex rules. > > So here's a quick little patch for them: > http://www.dillo.org/test/zero_width_space.patch Looks good to me, but do we really need to add a space? Wouldn't it be enough to just start a new word? At least dw-example seems to wrap words with textblock->addSpace(wordStyle); commented out. > > > PS I did just start trying to move the ideographic test to dw, > but I got stuck when I realized that I can't exactly call fltk's > utf8decode() directly in Textblock, and am not excited by the > idea of calling it through Layout. > I think we could make the utf8 methods in fltkplatform.cc static members. Cheers, Johannes From onepoint at starurchin.org Tue Sep 29 20:30:47 2009 From: onepoint at starurchin.org (Jeremy Henty) Date: Tue Sep 29 20:31:42 2009 Subject: [Dillo-dev] What's the status of USE_TABLES? In-Reply-To: <20090929165344.GA4104@dillo.org> References: <20090928190119.GD6839@omphalos.singularity> <20090929165344.GA4104@dillo.org> Message-ID: <20090929183047.GJ6839@omphalos.singularity> On Tue, Sep 29, 2009 at 12:53:44PM -0400, Jorge Arellano Cid wrote: > On Mon, Sep 28, 2009 at 08:01:19PM +0100, Jeremy Henty wrote: > > > > ... is USE_TABLES obsolete or not? ... > > OK remove it. Patch attached. Jeremy Henty -------------- next part -------------- # HG changeset patch # User Jeremy Henty # Date 1254248768 -3600 # Node ID aa08f6648d4486eb8c8b4d6e04a7e0aa5e9413de # Parent 8f8b7397f30ebddfe17adf763ea76627b8bfe23e imported patch remove_use_tables diff -r 8f8b7397f30e -r aa08f6648d44 src/table.cc --- a/src/table.cc Sun Sep 27 18:07:30 2009 +0000 +++ b/src/table.cc Tue Sep 29 19:26:08 2009 +0100 @@ -20,9 +20,6 @@ #include "msg.h" #include "css.hh" -/* Undefine if you want to unroll tables. For instance for PDAs */ -#define USE_TABLES - using namespace dw; using namespace dw::core; using namespace dw::core::style; @@ -40,16 +37,12 @@ */ void Html_tag_open_table(DilloHtml *html, const char *tag, int tagsize) { -#ifdef USE_TABLES dw::core::Widget *table; CssPropertyList props, *table_cell_props; const char *attrbuf; int32_t border = -1, cellspacing = -1, cellpadding = -1, bgcolor = -1; CssLength cssLength; -#endif - -#ifdef USE_TABLES if ((attrbuf = a_Html_get_attr(html, tag, tagsize, "border"))) border = isdigit(attrbuf[0]) ? strtol (attrbuf, NULL, 10) : 1; if ((attrbuf = a_Html_get_attr(html, tag, tagsize, "cellspacing"))) @@ -136,7 +129,6 @@ S_TOP(html)->table_mode = DILLO_HTML_TABLE_MODE_TOP; S_TOP(html)->cell_text_align_set = FALSE; S_TOP(html)->table = table; -#endif } /* @@ -149,7 +141,6 @@ bool new_style = false; CssPropertyList props, *table_cell_props; -#ifdef USE_TABLES switch (S_TOP(html)->table_mode) { case DILLO_HTML_TABLE_MODE_NONE: _MSG("Invalid HTML syntax: outside \n"); @@ -196,9 +187,6 @@ } S_TOP(html)->table_mode = DILLO_HTML_TABLE_MODE_TR; -#else - HT2TB(html)->addParbreak (0, html->styleEngine->wordStyle ()); -#endif } /* @@ -230,7 +218,6 @@ const char *tag, int tagsize, dw::core::style::TextAlignType text_align) { -#ifdef USE_TABLES Widget *col_tb; int colspan = 1, rowspan = 1; const char *attrbuf; @@ -317,5 +304,4 @@ } S_TOP(html)->table_mode = DILLO_HTML_TABLE_MODE_TD; -#endif } From jcid at dillo.org Tue Sep 29 20:59:41 2009 From: jcid at dillo.org (Jorge Arellano Cid) Date: Tue Sep 29 21:00:17 2009 Subject: [Dillo-dev] What's the status of USE_TABLES? In-Reply-To: <20090929183047.GJ6839@omphalos.singularity> References: <20090928190119.GD6839@omphalos.singularity> <20090929165344.GA4104@dillo.org> <20090929183047.GJ6839@omphalos.singularity> Message-ID: <20090929185941.GA8104@dillo.org> On Tue, Sep 29, 2009 at 07:30:47PM +0100, Jeremy Henty wrote: > On Tue, Sep 29, 2009 at 12:53:44PM -0400, Jorge Arellano Cid wrote: > > On Mon, Sep 28, 2009 at 08:01:19PM +0100, Jeremy Henty wrote: > > > > > > ... is USE_TABLES obsolete or not? ... > > > > OK remove it. > > Patch attached. Committed. -- Cheers Jorge.- From corvid at lavabit.com Tue Sep 29 21:30:22 2009 From: corvid at lavabit.com (corvid) Date: Tue Sep 29 21:34:37 2009 Subject: [Dillo-dev] experimental patch: zero width space (Thai, Lao, Cambodian...) In-Reply-To: <20090929175257.GA1262@blob.baaderstrasse.com> References: <20090929080353.GE26113@local.gobigwest.com> <20090929175257.GA1262@blob.baaderstrasse.com> Message-ID: <20090929193022.GF26113@local.gobigwest.com> Johannes wrote: > On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote: > > I just learned that some languages don't use spaces but can only > > break in certain places, and that they tend to insert > > Zero Width Space to make life easier for software that > > doesn't know the complex rules. > > > > So here's a quick little patch for them: > > http://www.dillo.org/test/zero_width_space.patch > > Looks good to me, but do we really need to add a space? > Wouldn't it be enough to just start a new word? > At least dw-example seems to wrap words with > textblock->addSpace(wordStyle); commented out. I was thinking that it would be good to remember that it's there so that the iterator could be made to do the right thing for copying and pasting text, but maybe that's too much of a picky corner case akin to soft hyphens. (And maybe stripping them out would make life simpler for findtext anyway.) > > > > > > PS I did just start trying to move the ideographic test to dw, > > but I got stuck when I realized that I can't exactly call fltk's > > utf8decode() directly in Textblock, and am not excited by the > > idea of calling it through Layout. > > > > I think we could make the utf8 methods in fltkplatform.cc static > members. In this case, that would save us... carrying along a this pointer that we weren't using? Does it save an indirection? (in any case, maybe I should static-ize all of our current fltkplatform functions that just call fltk functions) From Johannes.Hofmann at gmx.de Tue Sep 29 21:48:41 2009 From: Johannes.Hofmann at gmx.de (Johannes Hofmann) Date: Tue Sep 29 21:57:44 2009 Subject: [Dillo-dev] experimental patch: zero width space (Thai, Lao, Cambodian...) In-Reply-To: <20090929193022.GF26113@local.gobigwest.com> References: <20090929080353.GE26113@local.gobigwest.com> <20090929175257.GA1262@blob.baaderstrasse.com> <20090929193022.GF26113@local.gobigwest.com> Message-ID: <20090929194840.GA922@blob.baaderstrasse.com> On Tue, Sep 29, 2009 at 07:30:22PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote: > > > I just learned that some languages don't use spaces but can only > > > break in certain places, and that they tend to insert > > > Zero Width Space to make life easier for software that > > > doesn't know the complex rules. > > > > > > So here's a quick little patch for them: > > > http://www.dillo.org/test/zero_width_space.patch > > > > Looks good to me, but do we really need to add a space? > > Wouldn't it be enough to just start a new word? > > At least dw-example seems to wrap words with > > textblock->addSpace(wordStyle); commented out. > > I was thinking that it would be good to remember that it's > there so that the iterator could be made to do the right > thing for copying and pasting text, but maybe that's too > much of a picky corner case akin to soft hyphens. > (And maybe stripping them out would make life simpler for > findtext anyway.) Hm, don't know what's better... > > > > > > > > > > PS I did just start trying to move the ideographic test to dw, > > > but I got stuck when I realized that I can't exactly call fltk's > > > utf8decode() directly in Textblock, and am not excited by the > > > idea of calling it through Layout. > > > > > > > I think we could make the utf8 methods in fltkplatform.cc static > > members. > > In this case, that would save us... carrying along a this > pointer that we weren't using? Does it save an indirection? > > (in any case, maybe I should static-ize all of our current > fltkplatform functions that just call fltk functions) Wait. Making them static is not a good idea. Currently we could have different platforms in a single process and the right methods would be called. Are you concerned about speed or readability? Cheers, Johannes From corvid at lavabit.com Wed Sep 30 00:44:33 2009 From: corvid at lavabit.com (corvid) Date: Wed Sep 30 00:48:22 2009 Subject: [Dillo-dev] experimental patch: zero width space (Thai, Lao, Cambodian...) In-Reply-To: <20090929194840.GA922@blob.baaderstrasse.com> References: <20090929080353.GE26113@local.gobigwest.com> <20090929175257.GA1262@blob.baaderstrasse.com> <20090929193022.GF26113@local.gobigwest.com> <20090929194840.GA922@blob.baaderstrasse.com> Message-ID: <20090929224433.GG26113@local.gobigwest.com> Johannes wrote: > On Tue, Sep 29, 2009 at 07:30:22PM +0000, corvid wrote: > > Johannes wrote: > > > On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote: > > > > PS I did just start trying to move the ideographic test to dw, > > > > but I got stuck when I realized that I can't exactly call fltk's > > > > utf8decode() directly in Textblock, and am not excited by the > > > > idea of calling it through Layout. > > > > > > > > > > I think we could make the utf8 methods in fltkplatform.cc static > > > members. > > > > In this case, that would save us... carrying along a this > > pointer that we weren't using? Does it save an indirection? > > > > (in any case, maybe I should static-ize all of our current > > fltkplatform functions that just call fltk functions) > > Wait. Making them static is not a good idea. Currently we could > have different platforms in a single process and the right methods > would be called. > Are you concerned about speed or readability? It sounded slow to go through layout, but then we do our share of nextGlyph, textWidth, etc, and haven't died from it. Maybe it's time to get gprof out again anyway.