December 2007 - Dillo-dev - lists.mailman3.com

[PATCH] dw::fltk::ui::FltkOptionMenuResource::isSelected()

by jcid＠dillo.org

On Thu, Dec 27, 2007 at 05:28:52PM +0000, Jeremy Henty wrote: > > This patch provides a correct implementation of > dw::fltk::ui::FltkOptionMenuResource::isSelected(), > replacing the current stub. It is necessary for dillo2 to support > SELECT controls in forms. > > Notes: > > * We implement Johannes' suggestion of modifying createNewMenu, > using a single callback for each menu and calling item() to get > the selected item. This gives a very clean implementation that > doesn't add any new data members or virtual methods to the base > classes. Good. > * We use FLTK widgets' user_data() to attach dw objects to FLTK > widgets so that the FLTK callback can retrieve those dw objects > from its arguments. This works very nicely and saves code since > we don't have to add new data members to existing classes. Good2. ;) > * To avoid making identical changes everywhere an Item is created we > refactored and created a new Item::createNewWidget() method. > > * For consistency of style we also refactored and created > Item::createNewGroupWidget() and > FltkSelectionResource::createNewItem(). (Despite their simplicity > these refactorings actually account for most of the patch.) Committed! > I should finish polishing the dillo2 SELECT patch soon. Then I'll be > able to set comment thresholds on Slashdot! (These days that's the > thing that most often forces me to quit dillo2 and start another > browser, so this is a big itch to scratch.) I look forward to have SELECT working. -- Cheers Jorge.-

Dec. 28, 2007

patch: just hooking up panel preferences (panel_size, small_icons)

by place＠gobigwest.com

Interestingly, the default was and is Tiny if panel_size is not mentioned in the rc, the default was and is Small in dillorc2, the initial value had been Medium in ui.cc, and the default was and is Large if the panel_size value is not understood.

Dec. 27, 2007

[PATCH] dw::fltk::ui::FltkOptionMenuResource::isSelected()

by onepoint＠starurchin.org

This patch provides a correct implementation of dw::fltk::ui::FltkOptionMenuResource::isSelected(), replacing the current stub. It is necessary for dillo2 to support SELECT controls in forms. Notes: * We implement Johannes' suggestion of modifying createNewMenu, using a single callback for each menu and calling item() to get the selected item. This gives a very clean implementation that doesn't add any new data members or virtual methods to the base classes. * We use FLTK widgets' user_data() to attach dw objects to FLTK widgets so that the FLTK callback can retrieve those dw objects from its arguments. This works very nicely and saves code since we don't have to add new data members to existing classes. * To avoid making identical changes everywhere an Item is created we refactored and created a new Item::createNewWidget() method. * For consistency of style we also refactored and created Item::createNewGroupWidget() and FltkSelectionResource::createNewItem(). (Despite their simplicity these refactorings actually account for most of the patch.) I should finish polishing the dillo2 SELECT patch soon. Then I'll be able to set comment thresholds on Slashdot! (These days that's the thing that most often forces me to quit dillo2 and start another browser, so this is a big itch to scratch.) Regards, Jeremy Henty

Dec. 27, 2007

Q: Form SELECT support: what to do in the DW code?

by onepoint＠starurchin.org

> > The most straightforward thing to do is add a virtual function to > > SelectionResource that returns the callback to attach to the FLTK > > items we create. Is that OK, or do we need something more > > abstract? > > Sounds ok to me, if it is necessary. I'm only starting to understand > the FltkSelectionResource stuff however :-) I've got something working that adds the callback as a virtual function in the FltkListResource::Item class. Unfortunately it requires adding some other virtual functions and some extremely verbose template code (+ use of the typename keyword to get it all through the parser) so I'm keen to simplify things. > Or would it be possible to connect the callback in createNewMenu() > which is virtual already? If you look at the test/menu.cxx from > fltk-2, there they install one callback per menu and get the item > using get_item(). That might be much simpler than what I currently have. I'd much rather reuse the virtual functions we already have than add new ones. Thanks for the tip, I'll give it a go! Jeremy Henty

Dec. 26, 2007

Q: Form SELECT support: what to do in the DW code?

by Johannes.Hofmann＠gmx.de

On Tue, Dec 25, 2007 at 07:20:43PM +0000, Jeremy Henty wrote: > > I'm working on supporting SELECT controls in forms. I've got a > working first draft of the changes to the Dillo parser, but it's of no > use yet because the Dillo menu widgets are incomplete; the menus > report every item as selected and the items don't yet do anything when > you select them (unless I've missed something). So I'm wondering how > to fix this. > > We need a way to connect Items to callbacks. We need some abstraction > because ListResources and OptionMenuResources will do things > differently. The most straightforward thing to do is add a virtual > function to SelectionResource that returns the callback to attach to > the FLTK items we create. Is that OK, or do we need something more > abstract? Sounds ok to me, if it is necessary. I'm only starting to understand the FltkSelectionResource stuff however :-) Or would it be possible to connect the callback in createNewMenu() which is virtual already? If you look at the test/menu.cxx from fltk-2, there they install one callback per menu and get the item using get_item(). Regards, Johannes > > Assuming the Item will be passed to the callback, we really need a way > to get back from the Item to the ListResource. The easiest way is to > simply add a new data member to Itens that points to the ListResource. > Again, is that OK, or should we be more abstract and not hardwire that > implentation into the base class? > > I'm a fan of abstraction (I used to be a mathematician) but I'm > inclined not to go too abstract unless there's good reason, so I think > the suggestions above are good enough. Thoughts? > > If we do the above then fixing OptionMenuResource should be easy; add > a data member to record the last selected Item, connect Items to a > callback that updates that data member and implement isSelected() to > compare the item being queried with the selected item. > > Is it worth submitting a patch along these lines, or should I do it > differently? > > Regards, > > Jeremy Henty > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 26, 2007

Q: Form SELECT support: what to do in the DW code?

by onepoint＠starurchin.org

I'm working on supporting SELECT controls in forms. I've got a working first draft of the changes to the Dillo parser, but it's of no use yet because the Dillo menu widgets are incomplete; the menus report every item as selected and the items don't yet do anything when you select them (unless I've missed something). So I'm wondering how to fix this. We need a way to connect Items to callbacks. We need some abstraction because ListResources and OptionMenuResources will do things differently. The most straightforward thing to do is add a virtual function to SelectionResource that returns the callback to attach to the FLTK items we create. Is that OK, or do we need something more abstract? Assuming the Item will be passed to the callback, we really need a way to get back from the Item to the ListResource. The easiest way is to simply add a new data member to Itens that points to the ListResource. Again, is that OK, or should we be more abstract and not hardwire that implentation into the base class? I'm a fan of abstraction (I used to be a mathematician) but I'm inclined not to go too abstract unless there's good reason, so I think the suggestions above are good enough. Thoughts? If we do the above then fixing OptionMenuResource should be easy; add a data member to record the last selected Item, connect Items to a callback that updates that data member and implement isSelected() to compare the item being queried with the selected item. Is it worth submitting a patch along these lines, or should I do it differently? Regards, Jeremy Henty

Dec. 25, 2007

Re: Colspan and table percentages

by place＠gobigwest.com

I've noticed that sometimes people will make a table with two columns for the purpose of indenting their text, specifying only the width of the first column as some percentage. When they do this, dillo squishes everything to the right. Tiny example: <html><head><title></title></head><body> <table width=500 border=3> <tr> <td width="50%">Is explicitly 50%</td> <td>should be 50%</td> </tr> </table> </body></html>

Dec. 24, 2007

[PATCH] FLTK Resources should call ::fltk::setfont before ::fltk::getwidth

by jcid＠dillo.org

On Sun, Dec 23, 2007 at 06:49:06PM +0000, Jeremy Henty wrote: > On Sun, Dec 23, 2007 at 12:12:51PM -0300, Jorge Arellano Cid wrote: > > > With regard to dialog: it'd be nice to set the font size > > considering prefs.font_factor. > > OK, here's a patch but I'm not sure how to test it. What's an easy > way to get dillo-fltk to show a dialog? Last time I looked the https > dpi dialogs failed to appear. Just use "View source". Committed with a minor tweak. -- Cheers Jorge.-

Dec. 23, 2007

[PATCH] FLTK Resources should call ::fltk::setfont before ::fltk::getwidth

by jcid＠dillo.org

On Sun, Dec 23, 2007 at 05:33:49PM +0000, Jeremy Henty wrote: > On Sun, Dec 23, 2007 at 12:12:51PM -0300, Jorge Arellano Cid wrote: > > > For fltkpreview.cc, it'd be good to at least add a commented > > statement because it clearly is in a state of flux (and ifdefed > > out). > > Heh, I hadn't noticed it was ifdefed! Here's a patch that moves the > setfont() call to the top of the function and adds a comment > explaining why it must be there. There's no change to the > functionality since the interviewing code is commented out. Committed. -- Cheers Jorge.-

Dec. 23, 2007

[PATCH] FLTK Resources should call ::fltk::setfont before ::fltk::getwidth

by onepoint＠starurchin.org

On Sun, Dec 23, 2007 at 12:12:51PM -0300, Jorge Arellano Cid wrote: > With regard to dialog: it'd be nice to set the font size > considering prefs.font_factor. OK, here's a patch but I'm not sure how to test it. What's an easy way to get dillo-fltk to show a dialog? Last time I looked the https dpi dialogs failed to appear. Regards, Jeremy Henty

Dec. 23, 2007