- Dillo-dev - lists.mailman3.com

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

Problem using "Textblock" Class.

by Johannes.Hofmann＠gmx.de

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!

March 19, 2010

Problem using "Textblock" Class.

by rmarathe＠i-rode.com

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. 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, regards, Rajesh Marathe.

March 19, 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): Yeah, I think I'd be willing to commit that with comments. It occurs to me that programmers...we have the ideas of pointing out bugs, workarounds, explaining complexities -- but I don't know whether I've seen a project keeping track of "this is something that you can consider taking out again if it should cause serious headaches someday". Somewhat related, but perhaps very difficult to see at the time is "This is done in this particular way to fit with what we are given by [something, e.g., gtk], and needn't be kept in this form if what we interface with changes."

March 16, 2010

patch: drawing image map areas

by Johannes.Hofmann＠gmx.de

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): diff -r 7aca003dbfca dw/image.hh --- a/dw/image.hh Sun Mar 14 19:09:24 2010 +0000 +++ b/dw/image.hh Tue Mar 16 11:39:25 2010 +0100 @@ -159,6 +159,7 @@ void setIsMap (); void setUseMap (ImageMapsList *list, Object *key); + void forceMapRedraw () { if (mapKey && ! buffer) queueDraw (); }; }; } // namespace dw diff -r 7aca003dbfca src/html.cc --- a/src/html.cc Sun Mar 14 19:09:24 2010 +0000 +++ b/src/html.cc Tue Mar 16 11:39:25 2010 +0100 @@ -2199,6 +2199,11 @@ */ static void Html_tag_close_map(DilloHtml *html, int TagIdx) { + for (int i = 0; i < html->images->size(); i++) { + dw::Image *img = (dw::Image *) html->images->get(i)->image->dw; + + img->forceMapRedraw(); + } html->InFlags &= ~IN_MAP; }

March 16, 2010

patch: drawing image map areas

by corvid＠lavabit.com

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.

March 15, 2010

patch: drawing image map areas

by Johannes.Hofmann＠gmx.de

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. Cheers, Johannes PS: The new viewsource dpi was super handy browsing the sources of the example pages!

March 15, 2010

Re: Using the tab or other keyboard keys to set focus on web page links...

by corvid＠lavabit.com

Rajesh wrote: > My implementation details: > -------------------------- > > I am planning to implement a method in the exiting "FindTextState" > Class. I am planning to use a CharIterator to move iterate through a web > page and find out a link. I'm thinking of Layout having a separate thing for this, a KeyFocusState (or some such name). For an iterator, something like a focusable element iterator instead of a CharIterator. Where I could call nextFocusable() and get back 1) the Widget (the Embed widget for a form control, or the Textblock widget that contains a link), and 2) a linkNo that the iterator found in the word's style. Like if the user pressed the key for the next focusable thing (e.g., tab), the KeyFocusState stuff would do something like iterator->getFocusable() gives back Widget *w and int linkNo if (linkNo == -1) { /* form control */ w->focus(); the dw Widget would have a virtual function, and the Embed implementation would call resource->focus(), which would in turn call take_focus() on its fltk widget. } else { iterator->highlight(); } and when the user pressed the key to follow the link (e.g., enter), we'd be in something similar to a_UIcmd_scroll() calling a new function like layout->activateLink(), which would call something in FocusState (which has Widget and linkNo handy), which would then call layout->emitLinkPress(widget, linkNo, ...) All: Or is that putting too much intelligence into an iterator? (It's easy to wish for magic from the part that's fuzzier to us :) Something smaller and dumber for an iterator to do would be something like styleIterator. Get back style, spaceStyle, style, spaceStyle, (some style from descending into a non-Textblock child), spaceStyle..., but then there's also this need to get back the "BTW, I am an Embed!", which seems like an awkward pairing of things for an iterator to return. Or a sort of Word iterator, but Words are hidden...

March 14, 2010

patch: drawing image map areas

by corvid＠lavabit.com

Johannes wrote: > This should be fixed now. The only place where we currently use > non-filled rectangles is bullet.cc and indeed I could reproduce the > issue with nested <ul>s and drag scrolling. Thanks. > PS: Feel free to commit your patch, we can resolve remaining issues > in-tree. Done.

March 11, 2010

Re: Using the tab or other keyboard keys to set focus on web page links...

by corvid＠lavabit.com

Rajesh wrote: > I am trying to put in a patch to use the tab or other keyboard keys to > set focus on web page links. I started implementing this based on > Corvid's suggestion as mentioned under: > > 1. borrowing from the dw/findtext.cc iteration code. > 2. checking when style->x_link != -1 or you're currently on an embedded form > widget. > > I have implemented the first part but still needs test. > I have a question while implementing the second part. Can you please tell me how to > determine if we are on an embedded form widget currently. Can you please send me code > snippets or guide me to implement this ? Thanks. If you're going through some sort of iterator, and you find yourself in something like Embed::iterator() in dw/ui.cc, then you have a form widget. An Embed is a ::dw::core::Widget that contains a Resource. dw/fltkui.cc has the various FLTK resources that are derived from Resource. These generally contain some sort of ::fltk::Widget used for a form input. A fltk::Widget can be given focus with take_focus().

March 11, 2010