- Dillo-dev - lists.mailman3.com

Dillo's jealous of Google

by furaisanjin＠gmail.com

Hi. Do you have filter_auto_requests=all in your dillorc? There may be another mechanism to prevent image/style sheet redirection. Regards, furaisanjin 2010/4/14 Jeremy Henty <onepoint(a)starurchin.org>: > > Dillo's *so* jealous ?of Google it won't let me see ?it! ?(So much for > the open relationship thing :-) > > Log attached. ? I assume ?that the ?DENY message is ?from line ?399 of > src/capi.c, is that right? ?This certainly worked only a few days ago. > What ?has changed? ? It's really ?not good ?that Dillo ?is ?by default > silently denying me access to Google. ?How can this be improved? > > Regards, > > Jeremy Henty

April 14, 2010

Dillo's jealous of Google

by onepoint＠starurchin.org

Dillo's *so* jealous of Google it won't let me see it! (So much for the open relationship thing :-) Log attached. I assume that the DENY message is from line 399 of src/capi.c, is that right? This certainly worked only a few days ago. What has changed? It's really not good that Dillo is by default silently denying me access to Google. How can this be improved? Regards, Jeremy Henty

April 14, 2010

new fltk snapshot out

by furaisanjin＠gmail.com

Hi. I tried r7473 on FreeBSD 8.0R and I found that Japanese input method (kinput2) didn't work on "search the web". All other cases like URL bar, HTML input and find text are OK. "Search the web" had the same problem on fltk-2.0-6916 but when I switched virtual screens, input method started working somehow. Regards, furaisanjin 2010/4/10 corvid <corvid(a)lavabit.com>: > Some compose / input method stuff. > http://fltk.org/articles.php?L986 > http://fltk.org/newsgroups.php?s4670+gfltk.commit+v4689+T0 > > If you find it to be an improvement, then we can update > the recommendation...

April 10, 2010

new fltk snapshot out

by corvid＠lavabit.com

Some compose / input method stuff. http://fltk.org/articles.php?L986 http://fltk.org/newsgroups.php?s4670+gfltk.commit+v4689+T0 If you find it to be an improvement, then we can update the recommendation...

April 9, 2010

Problem with fonts.

by andreas＠kemnade.info

Hi, I have faced these problems some time ago while compiling it for my ipaq. Scalable fonts were available but not the correct font libraries in the build environment. There are two possibilities to satisfy fltk's font library dependencies. One of them gives you nice looking fonts and one other not. Just what I remember at the moment. Greetings Andreas Kemnade

April 8, 2010

Problem with fonts.

by corvid＠lavabit.com

Rajesh wrote: > I have loaded Dillo Browser on to my ARM based embedded platform. > Presently, I am facing a problem with fonts. The messages that I get > while the browser comes up are > --------------------------------------------------------------- > bad font: > variable > ** WARNING **: preferred sans-serif font "helvetica Sans" not > found. > ** WARNING **: preferred serif font "helvetica Serif" not > found. > ** WARNING **: preferred monospace font "helvetica Sans Mono" not > found. > ** WARNING **: preferred cursive font "helvetica Sans" not > found. > ** WARNING **: preferred fantasy font "helvetica Sans" not > found. > ------------------------------------------------------------------ > > Also, the size of the text that appears on Dillo (On the ARM based > system) appears very small. > However, the same page if I open with Dillo running on a Linux PC, will > show bigger fonts. So, my questions are: > > 1. How do I get rid of the "bad font" error message on my ARM-based > system ? I have used LTIB as the unix based development platform. > > 2. How to overcome the font size problem ? Playing around with max/min > font_size and scale_factor in dillorc did not help. What fonts do you have? If you don't have scalable fonts, maybe you'll want to --disable-xft in fltk configuration. In any case, if you have helvetica, for instance, you'd just want to say font_sans_serif="helvetica". (Fltk's src/x11/Font_xlfd.cxx suggests that helvetica is relatively safe for sans, courier for monospaced, and times for serif.)

April 8, 2010

Problem with fonts.

by rmarathe＠i-rode.com

Hello, I have loaded Dillo Browser on to my ARM based embedded platform. Presently, I am facing a problem with fonts. The messages that I get while the browser comes up are --------------------------------------------------------------- bad font: variable ** WARNING **: preferred sans-serif font "helvetica Sans" not found. ** WARNING **: preferred serif font "helvetica Serif" not found. ** WARNING **: preferred monospace font "helvetica Sans Mono" not found. ** WARNING **: preferred cursive font "helvetica Sans" not found. ** WARNING **: preferred fantasy font "helvetica Sans" not found. ------------------------------------------------------------------ Also, the size of the text that appears on Dillo (On the ARM based system) appears very small. However, the same page if I open with Dillo running on a Linux PC, will show bigger fonts. So, my questions are: 1. How do I get rid of the "bad font" error message on my ARM-based system ? I have used LTIB as the unix based development platform. 2. How to overcome the font size problem ? Playing around with max/min font_size and scale_factor in dillorc did not help. regards, Rajesh Marathe.

April 8, 2010

web bug save?

by Johannes.Hofmann＠gmx.de

On Tue, Apr 06, 2010 at 02:41:50AM +0000, corvid wrote: > Jorge wrote: > > On Fri, Apr 02, 2010 at 07:07:50PM +0000, corvid wrote: > > > > I'd only suggest considering whether adding a URL flag (e.g. > > > > URL_FilterOut) provides more flexibility/clarity without having > > > > to add the 'requester' parameter to the API. > > > > > > Can you elaborate a bit on how/where the flag would be set, and > > > how it would help? > > > > I haven't looked at it in enough depth to offer a good > > alternative yet. Just noticed of the API changes, made an extra > > couple of passes above the code considering the flag or having > > referer in the DilloUrl struct. > > > > The idea is to commit it and to consider the alternatives > > later. > > All right, then. Committed. > > Everyone: > 1) This will surely require various tweaks. > 2) If it threatens to drive you insane in the meantime, there's a dillorc > option. While testing a bit more I found a problem with redirects: http://nibble.develsec.org doesn't seem to load properly when same_domain is enabled. The problem seems to be a_Nav_push(bw, bw->meta_refresh_url,a_History_get_url(NAV_TOP_UIDX(bw))); in Nav_redirection0_callback(). a_History_get_url(NAV_TOP_UIDX(bw)) is not necessarily the proper requester. Things seem to work in this example with a_Nav_push(bw, bw->meta_refresh_url,bw->nav_expect_url); but I guess bw->nav_expect_url is also not always set properly.

April 8, 2010

web bug save?

by corvid＠lavabit.com

Johannes wrote: > On Tue, Apr 06, 2010 at 02:41:50AM +0000, corvid wrote: > > Do you think we should put image/stylesheet redirection under its control? > > I guess, if we would also restrict redirects, we could guarantee, > that we only load from a domain the user has entered at the loacation bar > or clicked on in a link - which sounds reasonable to me. > OTH do we know how that would affect usability with major sites? In Cache_redirect(), non-root urls never redirect currently.

April 8, 2010

patch: white-space: pre-line as well

by Johannes.Hofmann＠gmx.de

On Wed, Mar 31, 2010 at 03:39:26AM +0000, corvid wrote: > I don't know whether it's of much use, exactly, but while I was > in the conceptual area... Excellent! One step closer to full CSS2.1 compliance. Please commit!

April 7, 2010

web bug save?

by Johannes.Hofmann＠gmx.de

On Tue, Apr 06, 2010 at 02:41:50AM +0000, corvid wrote: > Jorge wrote: > > On Fri, Apr 02, 2010 at 07:07:50PM +0000, corvid wrote: > > > > I'd only suggest considering whether adding a URL flag (e.g. > > > > URL_FilterOut) provides more flexibility/clarity without having > > > > to add the 'requester' parameter to the API. > > > > > > Can you elaborate a bit on how/where the flag would be set, and > > > how it would help? > > > > I haven't looked at it in enough depth to offer a good > > alternative yet. Just noticed of the API changes, made an extra > > couple of passes above the code considering the flag or having > > referer in the DilloUrl struct. > > > > The idea is to commit it and to consider the alternatives > > later. > > All right, then. Committed. Cool! Quite interesting to look at all those DENY's! > > Everyone: > 1) This will surely require various tweaks. > 2) If it threatens to drive you insane in the meantime, there's a dillorc > option. > > > Do you think we should put image/stylesheet redirection under its control? I guess, if we would also restrict redirects, we could guarantee, that we only load from a domain the user has entered at the loacation bar or clicked on in a link - which sounds reasonable to me. OTH do we know how that would affect usability with major sites? Cheers, Johannes BTW. I also updated the display branch accordingly.

April 7, 2010

web bug save?

by corvid＠lavabit.com

Jorge wrote: > On Fri, Apr 02, 2010 at 07:07:50PM +0000, corvid wrote: > > > I'd only suggest considering whether adding a URL flag (e.g. > > > URL_FilterOut) provides more flexibility/clarity without having > > > to add the 'requester' parameter to the API. > > > > Can you elaborate a bit on how/where the flag would be set, and > > how it would help? > > I haven't looked at it in enough depth to offer a good > alternative yet. Just noticed of the API changes, made an extra > couple of passes above the code considering the flag or having > referer in the DilloUrl struct. > > The idea is to commit it and to consider the alternatives > later. All right, then. Committed. Everyone: 1) This will surely require various tweaks. 2) If it threatens to drive you insane in the meantime, there's a dillorc option. Do you think we should put image/stylesheet redirection under its control? [for reference, this thread dates back to http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-December/007118.html ]

April 6, 2010

css :visited and security

by Johannes.Hofmann＠gmx.de

On Mon, Apr 05, 2010 at 07:18:26PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Jan 05, 2010 at 03:36:24PM +0000, corvid wrote: > > > The other day, I saw another of those pages about using :visited and > > > display in order to allow others to learn whether the user has visited > > > a page. (I remember Johannes pointing to a page about this last year, too.) > > > > > > I wonder whether it would be sensible to have a dillorc option defaulting > > > to NO for whether to use :visited. > > > > Yes, that sounds good. We should distinguish between remote / > > embedded CSS and user agent and user stylesheet though. > > For the latter two we don't need any restrictions. > > Does this look right? I'm also currently thinking about this issue - reminded by this article: http://blog.mozilla.com/security/2010/03/31/plugging-the-css-history-leak/ Maybe the fix implemented in your patch is too drastic. I would hope that something like the solution presented in the article above would be enough. If so, I would simply hardcode it and not make an option to disable it. Cheers, Johannes

April 5, 2010

css :visited and security

by corvid＠lavabit.com

Johannes wrote: > On Tue, Jan 05, 2010 at 03:36:24PM +0000, corvid wrote: > > The other day, I saw another of those pages about using :visited and > > display in order to allow others to learn whether the user has visited > > a page. (I remember Johannes pointing to a page about this last year, too.) > > > > I wonder whether it would be sensible to have a dillorc option defaulting > > to NO for whether to use :visited. > > Yes, that sounds good. We should distinguish between remote / > embedded CSS and user agent and user stylesheet though. > For the latter two we don't need any restrictions. Does this look right?

April 5, 2010

line-height

by Johannes.Hofmann＠gmx.de

On Sun, Apr 04, 2010 at 12:34:40AM +0000, corvid wrote: > Just committed some line-height code that Johannes and I wrote. Cool, good to have this in the official repo now. > > When line-height is less than the font's ascent+descent, unhighlighting > gets confused. I think it has to do with using the line dimensions for > 'area' for drawing the background. I'll dig into it a little more later on. > > PS I see that firefox puts more space between its paragraphs than we do. > Their value seems to be related to the font size, or the default font size, > or something. Is there anything deep behind our use of 9? I don't know where our 9 comes from. For firefox i guess it's the p, dl, multicol { display: block; margin: 1em 0; } from the useragent style[1], which would explain, why it scales with the font size. Cheers, Johannes [1] http://hell.meiert.org/core/css/firefox-3.0.1.css

April 4, 2010

line-height

by corvid＠lavabit.com

Just committed some line-height code that Johannes and I wrote. When line-height is less than the font's ascent+descent, unhighlighting gets confused. I think it has to do with using the line dimensions for 'area' for drawing the background. I'll dig into it a little more later on. PS I see that firefox puts more space between its paragraphs than we do. Their value seems to be related to the font size, or the default font size, or something. Is there anything deep behind our use of 9?

April 4, 2010

[matthew.t.craig@gmail.com: dillo question]

by Johannes.Hofmann＠gmx.de

> > hello .. started using dillo on a lemote yeeloong, which runs firefox slowly > dillo works great for me there! nice! > is there a way to use dillo with liferea feed reader, so links open > within dillo on a new tab? currently we don't have that feature, but it would definately be doable. There was a similar discussion some time ago: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-October/006912.html Cheers, Johannes

April 2, 2010

[matthew.t.craig@gmail.com: dillo question]

by jcid＠dillo.org

Hi, -- Cheers Jorge.-

April 1, 2010

[jeffdewe@gmail.com: Dillo]

by jcid＠dillo.org

Hi, In a nutshell: * FLTK2 halves the memory footprint of GTK1 [1]. * GTK2 is bigger and can double GTK1 [2] (4x factor). This means the increased binary size of a FLTK2 dillo static binary is compensated after browsing a couple of pages. I hope FLTK stops being a problem when FLTK-1.3 is released and included in the distros repos. We'll switch to it as soon as the release is available. [1] http://www.dillo.org/memory.html [2] http://lists.auriga.wearlab.de/pipermail/dillo-dev/2006-September/003097.ht… -- Cheers Jorge.-

April 1, 2010

[jeffdewe@gmail.com: Dillo]

by andreas＠kemnade.info

Hi, just one more practical explanation of the advances the more ressource friendly fltk2 has. BTW: fltk2 does not necessarily depend on GL. Imagine you have a device with limited ressources. Running a browser bigger than dillo might be possible. Perhaps even a bigger loading time might be ok in some situations. For example if you hve only gprs to connect to the internet, then loading of many pages takes ages anyway. But in case of multitasking there is really a harder limit. If you have multiple applications running which are a bit bigger, then you really have problems when you start a fat browser. Here is an example: Just some days after I got my freerunner I started a long bicycle trip and had not find time to install dillo. On one of the first evenings I visited one or two pages. That was not so nice but bearable with the default browser really because I was not surfing very much (of course having dillo is much better). Some days later, I was abroad and I found one wifi hotspot. I had more applications open (at least my mapping program (with a hotspot list loaded) Starting the default browser has frozen the system. That is completely unbearable. In that situation having a browser with a lower ressource usage is essential. Greetings Andreas Kemnade

March 31, 2010

[jeffdewe@gmail.com: Dillo]

by jcid＠dillo.org

-- Cheers Jorge.-

March 31, 2010

patch: implement white-space: pre-wrap for vsource

by Johannes.Hofmann＠gmx.de

On Wed, Mar 31, 2010 at 12:02:16AM +0000, corvid wrote: > Jorge wrote: > > On Tue, Mar 30, 2010 at 09:57:08PM +0200, Johannes Hofmann wrote: > > > On Tue, Mar 30, 2010 at 06:00:26AM +0000, corvid wrote: > > > > Just a thought I had. The web is filled with horrible generated html > > > > with lines a thousand characters long. With this (and parse_embedded_css), > > > > those lines become more tolerable. > > > > > > Very nice! > > > > +1 > > > > I really dislike when emails with paragraphs in one line get > > under PRE. If this fixes that, I'm all for it! :) > > > > > > I would commit it in two pieces, of course. > > > > > > Please go ahead - at least for the CSS / dw part. I don't know > > > whether it's ok to use it for source view. > > > > AFAIS, there's no problem for source view. > > Committed the CSS/dw part. > > For vsource, I have no opinion on whether to use my original solution > or to add an id like Johannes mentioned. As Jorge is also ok with it, I'd say make it the default for source view. Additionally I will add the id, for customization in style.css.

March 31, 2010

patch: white-space: pre-line as well

by corvid＠lavabit.com

I don't know whether it's of much use, exactly, but while I was in the conceptual area...

March 31, 2010

patch: implement white-space: pre-wrap for vsource

by corvid＠lavabit.com

Jorge wrote: > On Tue, Mar 30, 2010 at 09:57:08PM +0200, Johannes Hofmann wrote: > > On Tue, Mar 30, 2010 at 06:00:26AM +0000, corvid wrote: > > > Just a thought I had. The web is filled with horrible generated html > > > with lines a thousand characters long. With this (and parse_embedded_css), > > > those lines become more tolerable. > > > > Very nice! > > +1 > > I really dislike when emails with paragraphs in one line get > under PRE. If this fixes that, I'm all for it! :) > > > > I would commit it in two pieces, of course. > > > > Please go ahead - at least for the CSS / dw part. I don't know > > whether it's ok to use it for source view. > > AFAIS, there's no problem for source view. Committed the CSS/dw part. For vsource, I have no opinion on whether to use my original solution or to add an id like Johannes mentioned.

March 31, 2010

HTML 2.0 DTDs

by jcid＠dillo.org

On Tue, Mar 30, 2010 at 08:37:16PM +0000, corvid wrote: > I just mistyped an address on our site, got a 404, and noticed that > I get an HTML bug msg about the DTD. > > The 404 page has: > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> > > Html_parse_doctype has: > > static const char HTML20 [] = "-//IETF//DTD HTML//EN"; > > RFC 1866 has: > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Level 2//EN"> > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Level 1//EN"> > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Strict//EN"> > <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Strict Level 1//EN"> > > So I would rather strncmp for "-//IETF//DTD HTML 2.0". +1 -- Cheers Jorge.-

March 31, 2010

patch: implement white-space: pre-wrap for vsource

by jcid＠dillo.org

On Tue, Mar 30, 2010 at 09:57:08PM +0200, Johannes Hofmann wrote: > On Tue, Mar 30, 2010 at 06:00:26AM +0000, corvid wrote: > > Just a thought I had. The web is filled with horrible generated html > > with lines a thousand characters long. With this (and parse_embedded_css), > > those lines become more tolerable. > > Very nice! +1 I really dislike when emails with paragraphs in one line get under PRE. If this fixes that, I'm all for it! :) > > I would commit it in two pieces, of course. > > Please go ahead - at least for the CSS / dw part. I don't know > whether it's ok to use it for source view. AFAIS, there's no problem for source view. -- Cheers Jorge.-

March 31, 2010

Re: experiment feedback

by spell_gooder_now＠spellingbeewinnars.org

Hi Alan I had actually read quite a bit about seed and I had downloaded some sample code and played with it in the past. However your idea never occurred to me. I think it would be a fantastic idea to make the JavaScript within the layout engine talk to the "enclosing" GUI that is also written in JavaScript. I read through your blog, thanks for the link and your writings. I have been going around in circles for an amount of time I am too ashamed to confess. I have decided to write the back end and post pone the front end till I sort this out in my head. I would however still like to be a part of any project you might start related to this. I hope this won't come across the wrong way, I really like Dillo but I am wondering what is it's main niche it is planning to fill? Certainly it is fast and certainly it is small but is the target audience just people looking for a general purpose browser? Would it's speed and small size not make it ideal for being embedded in another application? Would this not be something that Gecko and Webkit cannot easily offer? I only have limited resources and time but I bet a corporate sponsor might fund this. Alan, I hope your studying goes well, sounds like someone else is sleep deprived too-Patrick

March 31, 2010

patch: implement white-space: pre-wrap for vsource

by Johannes.Hofmann＠gmx.de

On Tue, Mar 30, 2010 at 08:12:34PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Mar 30, 2010 at 06:00:26AM +0000, corvid wrote: > > > Just a thought I had. The web is filled with horrible generated html > > > with lines a thousand characters long. With this (and parse_embedded_css), > > > those lines become more tolerable. > > > > Very nice! > > > > > > > > I would commit it in two pieces, of course. > > > > Please go ahead - at least for the CSS / dw part. I don't know > > whether it's ok to use it for source view. > > I've read that it's in CSS 2.1 and 3, but not 1 or 2. > 2 is a "recommendation", but 2.1 is a "candidate recommendation". > > Are we aiming more in the direction of 2 or 2.1 (or their intersection)? I think we should go with 2.1. 2.1 fixes some shortcomings of 2, and 3 is still experimental - as far as I know.

March 30, 2010

HTML 2.0 DTDs

by corvid＠lavabit.com

I just mistyped an address on our site, got a 404, and noticed that I get an HTML bug msg about the DTD. The 404 page has: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> Html_parse_doctype has: static const char HTML20 [] = "-//IETF//DTD HTML//EN"; RFC 1866 has: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Level 2//EN"> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Level 1//EN"> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Strict//EN"> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Strict Level 1//EN"> So I would rather strncmp for "-//IETF//DTD HTML 2.0".

March 30, 2010

patch: implement white-space: pre-wrap for vsource

by corvid＠lavabit.com

Johannes wrote: > On Tue, Mar 30, 2010 at 06:00:26AM +0000, corvid wrote: > > Just a thought I had. The web is filled with horrible generated html > > with lines a thousand characters long. With this (and parse_embedded_css), > > those lines become more tolerable. > > Very nice! > > > > > I would commit it in two pieces, of course. > > Please go ahead - at least for the CSS / dw part. I don't know > whether it's ok to use it for source view. I've read that it's in CSS 2.1 and 3, but not 1 or 2. 2 is a "recommendation", but 2.1 is a "candidate recommendation". Are we aiming more in the direction of 2 or 2.1 (or their intersection)?

March 30, 2010

patch: implement white-space: pre-wrap for vsource

by Johannes.Hofmann＠gmx.de

On Tue, Mar 30, 2010 at 09:57:08PM +0200, Johannes Hofmann wrote: > On Tue, Mar 30, 2010 at 06:00:26AM +0000, corvid wrote: > > Just a thought I had. The web is filled with horrible generated html > > with lines a thousand characters long. With this (and parse_embedded_css), > > those lines become more tolerable. > > Very nice! > > > > > I would commit it in two pieces, of course. > > Please go ahead - at least for the CSS / dw part. I don't know > whether it's ok to use it for source view. In any case we could add an id like this: <body id="dillo_sv"> to the source view page, so people can adjust it in style.css, e.g: body#dillo_sv pre {white-space: pre-wrap}

March 30, 2010

patch: implement white-space: pre-wrap for vsource

by Johannes.Hofmann＠gmx.de

On Tue, Mar 30, 2010 at 06:00:26AM +0000, corvid wrote: > Just a thought I had. The web is filled with horrible generated html > with lines a thousand characters long. With this (and parse_embedded_css), > those lines become more tolerable. Very nice! > > I would commit it in two pieces, of course. Please go ahead - at least for the CSS / dw part. I don't know whether it's ok to use it for source view. Cheers, Johannes

March 30, 2010

patch: implement white-space: pre-wrap for vsource

by corvid＠lavabit.com

Just a thought I had. The web is filled with horrible generated html with lines a thousand characters long. With this (and parse_embedded_css), those lines become more tolerable. I would commit it in two pieces, of course.

March 30, 2010

Problem using "Textblock" Class.

by Johannes.Hofmann＠gmx.de

On Fri, Mar 26, 2010 at 02:03:08AM +0000, corvid wrote: > Johannes wrote: <snip> > > > > Ok, I made a very rough patch to demonstrate the concept (see > > attachment). > > The main problem - apart from code style - is how to restore the > > original color of the link once anotherone has been selected. This > > is not working properly with this patch, but it's a start. > > Maybe the focused link can use a highlighting layer in Textblock > to show it in inverse video rather than dealing with html and link colors. That would be an easy alternative, but I'm investigating how much effort it would be to properly implement the CSS dynmic pseudo classes (:hover, :active, :focus). :focus basically defines how a selected element should look like. E.g: <html> <head> <style type="text/css"> :focus {border: 1px solid green} </style> </head> <body> <a href="foo">foo</a> <a href="bar">bar</a> </body> works in firefox and shows a green border around the currently selected link. With :active anything in the style can be changed, not just the colors.

March 26, 2010

Problem using "Textblock" Class.

by corvid＠lavabit.com

Johannes wrote: > On Thu, Mar 25, 2010 at 05:28:04PM +0100, Johannes Hofmann wrote: > > On Thu, Mar 25, 2010 at 03:56:31PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Wed, Mar 24, 2010 at 04:49:09PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > On Wed, Mar 24, 2010 at 02:34:13PM +0530, Rajesh Marathe wrote: > > > > > > > Hello Corvid, > > > > > > > > > > > > > > You hit the nail on its head. > > > > > > > I will definitely use iterators to iterate on the words on a page. I do have > > > > > > > the code with me which is based on findtext.cc as mentioned by Johannes. > > > > > > > But, using iterators I can move to a word on a page. But to get its style, I > > > > > > > still need to access the "x_link" variable which is in the class Textblock. > > > > > > > Therefore, my understanding was to use both iterator class and the Textblock > > > > > > > class as well. > > > > > > > > > > > > > > However, after seeing your email I get a feeling that my understanding might > > > > > > > be incorrect. > > > > > > > So, right now, my problem is not in using iterators (Which I intend to do > > > > > > > anyways) but getting the x_link variable which is in Textblock class. Please > > > > > > > let me know where am I wrong. > > > > > > > > > > > > Ah, I think I see your problem now. Iterators have the getContent() > > > > > > method, but Content does not include the style and therefore not the > > > > > > x_link. > > > > > > I'd say we should enhance the Iterator interface to make it possible > > > > > > to get the style somehow. However I don't know yet what would be the > > > > > > best way to do it. > > > > > > corvid, what do you think? > > > > > > > > > > Ah, in my earlier mail, I was imagining there being a getFocusable() in our > > > > > new iterator that gave back a Widget and a linkNo in the same way that the char > > > > > iterator has getChar(), but now I see that the base iterator already has a > > > > > getWidget(), so I guess we would just need a getLinkNo(). > > > > > > > > Right, either that, or a bit more general a getStyle() method, that > > > > would return the style at the current position (including x_link). > > > > > > Maybe. I don't think I have a strong opinion on 'general' vs. > > > 'unnecessary exposure' on this issue yet. > > > > Good point. Let's start with getLinkNo() and switch to getStyle() > > once we actually need another style member. > > Ok, I made a very rough patch to demonstrate the concept (see > attachment). > The main problem - apart from code style - is how to restore the > original color of the link once anotherone has been selected. This > is not working properly with this patch, but it's a start. Maybe the focused link can use a highlighting layer in Textblock to show it in inverse video rather than dealing with html and link colors.

March 26, 2010

Problem using "Textblock" Class.

by Johannes.Hofmann＠gmx.de

On Thu, Mar 25, 2010 at 05:28:04PM +0100, Johannes Hofmann wrote: > On Thu, Mar 25, 2010 at 03:56:31PM +0000, corvid wrote: > > Johannes wrote: > > > On Wed, Mar 24, 2010 at 04:49:09PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Wed, Mar 24, 2010 at 02:34:13PM +0530, Rajesh Marathe wrote: > > > > > > Hello Corvid, > > > > > > > > > > > > You hit the nail on its head. > > > > > > I will definitely use iterators to iterate on the words on a page. I do have > > > > > > the code with me which is based on findtext.cc as mentioned by Johannes. > > > > > > But, using iterators I can move to a word on a page. But to get its style, I > > > > > > still need to access the "x_link" variable which is in the class Textblock. > > > > > > Therefore, my understanding was to use both iterator class and the Textblock > > > > > > class as well. > > > > > > > > > > > > However, after seeing your email I get a feeling that my understanding might > > > > > > be incorrect. > > > > > > So, right now, my problem is not in using iterators (Which I intend to do > > > > > > anyways) but getting the x_link variable which is in Textblock class. Please > > > > > > let me know where am I wrong. > > > > > > > > > > Ah, I think I see your problem now. Iterators have the getContent() > > > > > method, but Content does not include the style and therefore not the > > > > > x_link. > > > > > I'd say we should enhance the Iterator interface to make it possible > > > > > to get the style somehow. However I don't know yet what would be the > > > > > best way to do it. > > > > > corvid, what do you think? > > > > > > > > Ah, in my earlier mail, I was imagining there being a getFocusable() in our > > > > new iterator that gave back a Widget and a linkNo in the same way that the char > > > > iterator has getChar(), but now I see that the base iterator already has a > > > > getWidget(), so I guess we would just need a getLinkNo(). > > > > > > Right, either that, or a bit more general a getStyle() method, that > > > would return the style at the current position (including x_link). > > > > Maybe. I don't think I have a strong opinion on 'general' vs. > > 'unnecessary exposure' on this issue yet. > > Good point. Let's start with getLinkNo() and switch to getStyle() > once we actually need another style member. Ok, I made a very rough patch to demonstrate the concept (see attachment). The main problem - apart from code style - is how to restore the original color of the link once anotherone has been selected. This is not working properly with this patch, but it's a start. You can switch from one link to the next with <Tab>. Cheers, Johannes

March 25, 2010

Problem using "Textblock" Class.

by Johannes.Hofmann＠gmx.de

On Thu, Mar 25, 2010 at 03:56:31PM +0000, corvid wrote: > Johannes wrote: > > On Wed, Mar 24, 2010 at 04:49:09PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Wed, Mar 24, 2010 at 02:34:13PM +0530, Rajesh Marathe wrote: > > > > > Hello Corvid, > > > > > > > > > > You hit the nail on its head. > > > > > I will definitely use iterators to iterate on the words on a page. I do have > > > > > the code with me which is based on findtext.cc as mentioned by Johannes. > > > > > But, using iterators I can move to a word on a page. But to get its style, I > > > > > still need to access the "x_link" variable which is in the class Textblock. > > > > > Therefore, my understanding was to use both iterator class and the Textblock > > > > > class as well. > > > > > > > > > > However, after seeing your email I get a feeling that my understanding might > > > > > be incorrect. > > > > > So, right now, my problem is not in using iterators (Which I intend to do > > > > > anyways) but getting the x_link variable which is in Textblock class. Please > > > > > let me know where am I wrong. > > > > > > > > Ah, I think I see your problem now. Iterators have the getContent() > > > > method, but Content does not include the style and therefore not the > > > > x_link. > > > > I'd say we should enhance the Iterator interface to make it possible > > > > to get the style somehow. However I don't know yet what would be the > > > > best way to do it. > > > > corvid, what do you think? > > > > > > Ah, in my earlier mail, I was imagining there being a getFocusable() in our > > > new iterator that gave back a Widget and a linkNo in the same way that the char > > > iterator has getChar(), but now I see that the base iterator already has a > > > getWidget(), so I guess we would just need a getLinkNo(). > > > > Right, either that, or a bit more general a getStyle() method, that > > would return the style at the current position (including x_link). > > Maybe. I don't think I have a strong opinion on 'general' vs. > 'unnecessary exposure' on this issue yet. Good point. Let's start with getLinkNo() and switch to getStyle() once we actually need another style member.

March 25, 2010

Problem using "Textblock" Class.

by corvid＠lavabit.com

Johannes wrote: > On Wed, Mar 24, 2010 at 04:49:09PM +0000, corvid wrote: > > Johannes wrote: > > > On Wed, Mar 24, 2010 at 02:34:13PM +0530, Rajesh Marathe wrote: > > > > Hello Corvid, > > > > > > > > You hit the nail on its head. > > > > I will definitely use iterators to iterate on the words on a page. I do have > > > > the code with me which is based on findtext.cc as mentioned by Johannes. > > > > But, using iterators I can move to a word on a page. But to get its style, I > > > > still need to access the "x_link" variable which is in the class Textblock. > > > > Therefore, my understanding was to use both iterator class and the Textblock > > > > class as well. > > > > > > > > However, after seeing your email I get a feeling that my understanding might > > > > be incorrect. > > > > So, right now, my problem is not in using iterators (Which I intend to do > > > > anyways) but getting the x_link variable which is in Textblock class. Please > > > > let me know where am I wrong. > > > > > > Ah, I think I see your problem now. Iterators have the getContent() > > > method, but Content does not include the style and therefore not the > > > x_link. > > > I'd say we should enhance the Iterator interface to make it possible > > > to get the style somehow. However I don't know yet what would be the > > > best way to do it. > > > corvid, what do you think? > > > > Ah, in my earlier mail, I was imagining there being a getFocusable() in our > > new iterator that gave back a Widget and a linkNo in the same way that the char > > iterator has getChar(), but now I see that the base iterator already has a > > getWidget(), so I guess we would just need a getLinkNo(). > > Right, either that, or a bit more general a getStyle() method, that > would return the style at the current position (including x_link). Maybe. I don't think I have a strong opinion on 'general' vs. 'unnecessary exposure' on this issue yet. > But then how would we implement visual feedback? We probabely want > to highlight the currently selected link somehow. > We could for now use changeLinkColor(). What do you think? All right.

March 25, 2010

Problem using "Textblock" Class.

by Johannes.Hofmann＠gmx.de

On Wed, Mar 24, 2010 at 04:49:09PM +0000, corvid wrote: > Johannes wrote: > > On Wed, Mar 24, 2010 at 02:34:13PM +0530, Rajesh Marathe wrote: > > > Hello Corvid, > > > > > > You hit the nail on its head. > > > I will definitely use iterators to iterate on the words on a page. I do have > > > the code with me which is based on findtext.cc as mentioned by Johannes. > > > But, using iterators I can move to a word on a page. But to get its style, I > > > still need to access the "x_link" variable which is in the class Textblock. > > > Therefore, my understanding was to use both iterator class and the Textblock > > > class as well. > > > > > > However, after seeing your email I get a feeling that my understanding might > > > be incorrect. > > > So, right now, my problem is not in using iterators (Which I intend to do > > > anyways) but getting the x_link variable which is in Textblock class. Please > > > let me know where am I wrong. > > > > Ah, I think I see your problem now. Iterators have the getContent() > > method, but Content does not include the style and therefore not the > > x_link. > > I'd say we should enhance the Iterator interface to make it possible > > to get the style somehow. However I don't know yet what would be the > > best way to do it. > > corvid, what do you think? > > Ah, in my earlier mail, I was imagining there being a getFocusable() in our > new iterator that gave back a Widget and a linkNo in the same way that the char > iterator has getChar(), but now I see that the base iterator already has a > getWidget(), so I guess we would just need a getLinkNo(). Right, either that, or a bit more general a getStyle() method, that would return the style at the current position (including x_link). But then how would we implement visual feedback? We probabely want to highlight the currently selected link somehow. We could for now use changeLinkColor(). What do you think?

March 25, 2010

Problem using "Textblock" Class.

by corvid＠lavabit.com

Johannes wrote: > On Wed, Mar 24, 2010 at 02:34:13PM +0530, Rajesh Marathe wrote: > > Hello Corvid, > > > > You hit the nail on its head. > > I will definitely use iterators to iterate on the words on a page. I do have > > the code with me which is based on findtext.cc as mentioned by Johannes. > > But, using iterators I can move to a word on a page. But to get its style, I > > still need to access the "x_link" variable which is in the class Textblock. > > Therefore, my understanding was to use both iterator class and the Textblock > > class as well. > > > > However, after seeing your email I get a feeling that my understanding might > > be incorrect. > > So, right now, my problem is not in using iterators (Which I intend to do > > anyways) but getting the x_link variable which is in Textblock class. Please > > let me know where am I wrong. > > Ah, I think I see your problem now. Iterators have the getContent() > method, but Content does not include the style and therefore not the > x_link. > I'd say we should enhance the Iterator interface to make it possible > to get the style somehow. However I don't know yet what would be the > best way to do it. > corvid, what do you think? Ah, in my earlier mail, I was imagining there being a getFocusable() in our new iterator that gave back a Widget and a linkNo in the same way that the char iterator has getChar(), but now I see that the base iterator already has a getWidget(), so I guess we would just need a getLinkNo().

March 24, 2010

Problem using "Textblock" Class.

by Johannes.Hofmann＠gmx.de

On Wed, Mar 24, 2010 at 02:34:13PM +0530, Rajesh Marathe wrote: > Hello Corvid, > > You hit the nail on its head. > I will definitely use iterators to iterate on the words on a page. I do have > the code with me which is based on findtext.cc as mentioned by Johannes. > But, using iterators I can move to a word on a page. But to get its style, I > still need to access the "x_link" variable which is in the class Textblock. > Therefore, my understanding was to use both iterator class and the Textblock > class as well. > > However, after seeing your email I get a feeling that my understanding might > be incorrect. > So, right now, my problem is not in using iterators (Which I intend to do > anyways) but getting the x_link variable which is in Textblock class. Please > let me know where am I wrong. Ah, I think I see your problem now. Iterators have the getContent() method, but Content does not include the style and therefore not the x_link. I'd say we should enhance the Iterator interface to make it possible to get the style somehow. However I don't know yet what would be the best way to do it. corvid, what do you think? Cheers, Johannes

March 24, 2010

Problem using "Textblock" Class.

by rmarathe11＠gmail.com

Hello Corvid, You hit the nail on its head. I will definitely use iterators to iterate on the words on a page. I do have the code with me which is based on findtext.cc as mentioned by Johannes. But, using iterators I can move to a word on a page. But to get its style, I still need to access the "x_link" variable which is in the class Textblock. Therefore, my understanding was to use both iterator class and the Textblock class as well. However, after seeing your email I get a feeling that my understanding might be incorrect. So, right now, my problem is not in using iterators (Which I intend to do anyways) but getting the x_link variable which is in Textblock class. Please let me know where am I wrong. regards, Rajesh Marathe. On Tue, Mar 23, 2010 at 9:20 PM, corvid <corvid(a)lavabit.com> wrote: > Rajesh wrote: > > Johannes wrote: > > > Please let me know the changes that are needed to make the above work. > > ::dw::Textblock may link...but more importantly... > > > > I would expect some code that uses the existing iterator mechanism > > > to walk through a page and find links and buttons, and so on. > > > Maybe you could use findtext.cc as an example. > > As Johannes is saying, and as I detailed in earlier mail > ( > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-March/007396.html) > I would expect the use of iterators. It's not clear to me why you want > a Textblock instead, particularly one of your own that isn't part of the > page. > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

March 24, 2010

Problem using "Textblock" Class.

by corvid＠lavabit.com

Rajesh wrote: > Johannes wrote: > Please let me know the changes that are needed to make the above work. ::dw::Textblock may link...but more importantly... > > I would expect some code that uses the existing iterator mechanism > > to walk through a page and find links and buttons, and so on. > > Maybe you could use findtext.cc as an example. As Johannes is saying, and as I detailed in earlier mail ( http://lists.auriga.wearlab.de/pipermail/dillo-dev/2010-March/007396.html ), I would expect the use of iterators. It's not clear to me why you want a Textblock instead, particularly one of your own that isn't part of the page.

March 23, 2010

Problem using "Textblock" Class.

by rmarathe11＠gmail.com

Hello Johannes, To make things simple, I added a method in the file findtext.cc which is as under: The purpose of this method is to access "Textblock" from the file findtext.cc. ----------------------------------------------------------------------------------------------- /* RMP */ void FindtextState::getLink (void) { MSG("\n RMP: getLink function"); Textblock *textblock = new dw::Textblock (false); textblock->getNextLink (); } /* RMP */ ----------------------------------------------------------------------------------------------- I have included "textblock.hh" in the file 'findtext.cc'. I still get an error like shown below: ============================================================ ../dw/libDw-core.a(findtext.o): In function `dw::core::FindtextState::getLink()': /home/rmarathe/dillo-2.2/dw/findtext.cc:299: undefined reference to `dw::Textblock::Textblock(bool)' /home/rmarathe/dillo-2.2/dw/findtext.cc:301: undefined reference to `dw::Textblock::getNextLink()' collect2: ld returned 1 exit status make[2]: *** [dw-imgbuf-mem-test] Error 1 make[2]: Leaving directory `/home/rmarathe/dillo-2.2/test' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/rmarathe/dillo-2.2' make: *** [all] Error 2 ============================================================ >From the file findtext.cc it seems we are not able to get hold of the constructor or any other methods in TextBlock class. Please let me know the changes that are needed to make the above work. I can do a code clean-up later once the above starts working. regards, Rajesh Marathe. On Fri, Mar 19, 2010 at 10:55 PM, Johannes Hofmann <Johannes.Hofmann(a)gmx.de>wrote: > Hi, > > On Fri, Mar 19, 2010 at 10:26:25AM +0530, Rajesh Marathe wrote: > > Hi, > > > > I am trying to implement the support for using the tab or other keyboard > > keys to set focus on web page links. As part of this, I started out with > > adding a new Class and would like to use some sort of iterator in this > > class. I would also like to use the 'Textblock' object to retrieve the > > style->x_link for a word. However, when I try to initialize the > > Textblock object in my new class, I get a linker error. The details are > > as under: > > > > The basic skeletal code for new class is: > > ======================================== > > findlinks.cc > > > > namespace dw { > > namespace core { > > > > FindLinks::FindLinks () > > { > > widget = NULL; > > iterator = NULL; > > > > } > > > > FindLinks::~FindLinks () > > { > > if (iterator) > > delete iterator; > > } > > > > void FindLinks::getlink (void) > > { > > MSG("\n Hi !! I came to findlinks"); > > Textblock *textblock = new Textblock (false); > > > > } > > > > I have included "dw/textblock.hh" in the above file and also included > > core.hh. > > I guess it's because Textblock is in the dw namespace, not dw::core, > so removing "namespace core {" in the above example should fix it. > Alternatively you could use "new dw::Textblock (false);". > > > > > Compilation goes through but I end up with a linker error as under: > > ===================================================================== > > ../dw/libDw-core.a(findlinks.o): In function > > `dw::core::FindLinks::getlink()': > > /home/rmarathe/dillo-2.2/dw/findlinks.cc:25: undefined reference to > > `dw::Textblock::Textblock(bool)' > > collect2: ld returned 1 exit status > > > > > > > > I believe that I still need to use "iterator" and the Textblock" classes > > to implement this feature. Am I using the Textblock in a right way or am > > I missing something in the above code ? > > Please do let me know, > > Hm, I can't really tell from the code above. > I would expect some code that uses the existing iterator mechanism > to walk through a page and find links and buttons, and so on. > Maybe you could use findtext.cc as an example. > > Regards, > Johannes > > PS: The keyboard navigation feature would be highly appreciated! > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

March 23, 2010

dillo crash when using a <select> field during page load

by corvid＠lavabit.com

Rogut?s wrote: > When I click on a <select><option>option 1</option>...</select> field and > move the mouse through the items while a page is still loading, dillo > segfaults. I can quite reliably reproduce this with the country selection > field at the top center of lenovo.com. I wasn't able to put together a > smaller page which triggers this, but I have attached a full backtrace > from gdb. I think I see the problem. Last April, Johannes added code to disable forms while stylesheets are pending, but the <select> on that page isn't within a form. As for how we want to tell Html_add_input() in form.cc whether (bw->NumPendingStyleSheets == 0), I'm not sure at the moment. I like having those inputs function on HTML tutorial pages, but, given that the likelihood is probably .99999 that someone encounters them instead on javascripty pages and they probably don't understand why it isn't doing anything, maybe always disabling those would be a good idea.

March 21, 2010

dillo crash when using a <select> field during page load

by rogutes＠googlemail.com

G'day, When I click on a <select><option>option 1</option>...</select> field and move the mouse through the items while a page is still loading, dillo segfaults. I can quite reliably reproduce this with the country selection field at the top center of lenovo.com. I wasn't able to put together a smaller page which triggers this, but I have attached a full backtrace from gdb. -- -- Rogut?s Sparnuotos

March 21, 2010

patch: drawing image map areas

by Johannes.Hofmann＠gmx.de

On Sat, Mar 20, 2010 at 03:55:40PM +0000, corvid wrote: > Johannes wrote: > > On Sat, Mar 20, 2010 at 02:49:58AM +0000, corvid wrote: > > > Johannes wrote: > > > > On Mon, Mar 15, 2010 at 10:54:32PM +0000, corvid wrote: > > > > > Johannes wrote: > > > > > > On Sat, Mar 06, 2010 at 12:46:57AM +0000, corvid wrote: > > > > > > > This draws the shapes in image maps, which is quite nice when not > > > > > > > loading images. > > > > > > > > > > > > > > > > > > > > > There are two redrawing problems: > > > > > > > > > > > > > > If I try http://earthquake.usgs.gov/earthquakes/recenteqsww/ > > > > > > > a little bit of the map is visible at the bottom of the viewport > > > > > > > initially (geometry 850x630). The rectangles are visible, but not > > > > > > > the polygons. If I page down or switch to another desktop and back, > > > > > > > all is well. > > > > > > > > > > > > I think I found the cause of the second drawing issue: > > > > > > > > > > > > It's not specific to polygons, it's just that in the example page > > > > > > the polygons are defined last. > > > > > > The problem is that the shapes are defined after the image, so HTML > > > > > > code way below the definition of the actual image can now influence > > > > > > how the image should be drawn. > > > > > > If by accident the image get's drawn before the image map has been > > > > > > parsed, the shapes are not visible. > > > > > > > > > > > > We need to issue a queueDraw() for each affected image when adding > > > > > > a shape to an image map. The problem is that I think there currently > > > > > > is no reference from image maps to images using the map. > > > > > > > > > > Hmm, I sort of wonder whether I should take it back out. > > > > > It's a somewhat frivolous feature that only I would see, > > > > > and I am reluctant to increase the General Entanglement of Things > > > > > in such a case. > > > > > > > > You are right that we should not add too much complexity for this > > > > special case, but we could do it in a brute force way like this (plus > > > > adding some big comments explaining the issue): > > > > > > Gave it a try and crashed after a bit. When we try to load an image, > > > the DilloImage* in the html list is set to NULL because we have given it > > > to the web. > > > > Ah ok, but we can simply add a check for that case: > > Then we wouldn't have shapes drawn when dillo has requested the image, > but maybe that's all right... Yes, there is this gap, but I'd say it's ok.

March 20, 2010

patch: drawing image map areas

by corvid＠lavabit.com

Johannes wrote: > On Sat, Mar 20, 2010 at 02:49:58AM +0000, corvid wrote: > > Johannes wrote: > > > On Mon, Mar 15, 2010 at 10:54:32PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Sat, Mar 06, 2010 at 12:46:57AM +0000, corvid wrote: > > > > > > This draws the shapes in image maps, which is quite nice when not > > > > > > loading images. > > > > > > > > > > > > > > > > > > There are two redrawing problems: > > > > > > > > > > > > If I try http://earthquake.usgs.gov/earthquakes/recenteqsww/ > > > > > > a little bit of the map is visible at the bottom of the viewport > > > > > > initially (geometry 850x630). The rectangles are visible, but not > > > > > > the polygons. If I page down or switch to another desktop and back, > > > > > > all is well. > > > > > > > > > > I think I found the cause of the second drawing issue: > > > > > > > > > > It's not specific to polygons, it's just that in the example page > > > > > the polygons are defined last. > > > > > The problem is that the shapes are defined after the image, so HTML > > > > > code way below the definition of the actual image can now influence > > > > > how the image should be drawn. > > > > > If by accident the image get's drawn before the image map has been > > > > > parsed, the shapes are not visible. > > > > > > > > > > We need to issue a queueDraw() for each affected image when adding > > > > > a shape to an image map. The problem is that I think there currently > > > > > is no reference from image maps to images using the map. > > > > > > > > Hmm, I sort of wonder whether I should take it back out. > > > > It's a somewhat frivolous feature that only I would see, > > > > and I am reluctant to increase the General Entanglement of Things > > > > in such a case. > > > > > > You are right that we should not add too much complexity for this > > > special case, but we could do it in a brute force way like this (plus > > > adding some big comments explaining the issue): > > > > Gave it a try and crashed after a bit. When we try to load an image, > > the DilloImage* in the html list is set to NULL because we have given it > > to the web. > > Ah ok, but we can simply add a check for that case: Then we wouldn't have shapes drawn when dillo has requested the image, but maybe that's all right...

March 20, 2010

patch: drawing image map areas

by Johannes.Hofmann＠gmx.de

On Sat, Mar 20, 2010 at 02:49:58AM +0000, corvid wrote: > Johannes wrote: > > On Mon, Mar 15, 2010 at 10:54:32PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Sat, Mar 06, 2010 at 12:46:57AM +0000, corvid wrote: > > > > > This draws the shapes in image maps, which is quite nice when not > > > > > loading images. > > > > > > > > > > > > > > > There are two redrawing problems: > > > > > > > > > > If I try http://earthquake.usgs.gov/earthquakes/recenteqsww/ > > > > > a little bit of the map is visible at the bottom of the viewport > > > > > initially (geometry 850x630). The rectangles are visible, but not > > > > > the polygons. If I page down or switch to another desktop and back, > > > > > all is well. > > > > > > > > I think I found the cause of the second drawing issue: > > > > > > > > It's not specific to polygons, it's just that in the example page > > > > the polygons are defined last. > > > > The problem is that the shapes are defined after the image, so HTML > > > > code way below the definition of the actual image can now influence > > > > how the image should be drawn. > > > > If by accident the image get's drawn before the image map has been > > > > parsed, the shapes are not visible. > > > > > > > > We need to issue a queueDraw() for each affected image when adding > > > > a shape to an image map. The problem is that I think there currently > > > > is no reference from image maps to images using the map. > > > > > > Hmm, I sort of wonder whether I should take it back out. > > > It's a somewhat frivolous feature that only I would see, > > > and I am reluctant to increase the General Entanglement of Things > > > in such a case. > > > > You are right that we should not add too much complexity for this > > special case, but we could do it in a brute force way like this (plus > > adding some big comments explaining the issue): > > Gave it a try and crashed after a bit. When we try to load an image, > the DilloImage* in the html list is set to NULL because we have given it > to the web. Ah ok, but we can simply add a check for that case: diff -r 5fafc795ebbd dw/image.hh --- a/dw/image.hh Sat Mar 20 01:55:00 2010 +0000 +++ b/dw/image.hh Sat Mar 20 11:26:02 2010 +0100 @@ -159,6 +159,7 @@ void setIsMap (); void setUseMap (ImageMapsList *list, Object *key); + void forceMapRedraw () { if (mapKey && ! buffer) queueDraw (); }; }; } // namespace dw diff -r 5fafc795ebbd src/html.cc --- a/src/html.cc Sat Mar 20 01:55:00 2010 +0000 +++ b/src/html.cc Sat Mar 20 11:26:02 2010 +0100 @@ -2199,6 +2199,12 @@ */ static void Html_tag_close_map(DilloHtml *html, int TagIdx) { + for (int i = 0; i < html->images->size(); i++) { + DilloImage *img = html->images->get(i)->image; + + if (img) + ((dw::Image*) img->dw)->forceMapRedraw(); + } html->InFlags &= ~IN_MAP; } BTW: I found another nice image map example: http://html.cita.uiuc.edu/text/map/map-example.php Cheers, Johannes

March 20, 2010

patch: drawing image map areas

by corvid＠lavabit.com

Johannes wrote: > On Mon, Mar 15, 2010 at 10:54:32PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Mar 06, 2010 at 12:46:57AM +0000, corvid wrote: > > > > This draws the shapes in image maps, which is quite nice when not > > > > loading images. > > > > > > > > > > > > There are two redrawing problems: > > > > > > > > If I try http://earthquake.usgs.gov/earthquakes/recenteqsww/ > > > > a little bit of the map is visible at the bottom of the viewport > > > > initially (geometry 850x630). The rectangles are visible, but not > > > > the polygons. If I page down or switch to another desktop and back, > > > > all is well. > > > > > > I think I found the cause of the second drawing issue: > > > > > > It's not specific to polygons, it's just that in the example page > > > the polygons are defined last. > > > The problem is that the shapes are defined after the image, so HTML > > > code way below the definition of the actual image can now influence > > > how the image should be drawn. > > > If by accident the image get's drawn before the image map has been > > > parsed, the shapes are not visible. > > > > > > We need to issue a queueDraw() for each affected image when adding > > > a shape to an image map. The problem is that I think there currently > > > is no reference from image maps to images using the map. > > > > Hmm, I sort of wonder whether I should take it back out. > > It's a somewhat frivolous feature that only I would see, > > and I am reluctant to increase the General Entanglement of Things > > in such a case. > > You are right that we should not add too much complexity for this > special case, but we could do it in a brute force way like this (plus > adding some big comments explaining the issue): Gave it a try and crashed after a bit. When we try to load an image, the DilloImage* in the html list is set to NULL because we have given it to the web.

March 20, 2010