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

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