- Dillo-dev - lists.mailman3.com

[patch] make TopGroup a PackedGroup

by place＠gobigwest.com

Johannes wrote: > just noticed that child widgets where not redrawn properly with my > patch. Attached is a fixed version against current cvs. If I switch to another screen and come back, the scrollbars aren't drawn. The viewport has damage 0xc0, and ?scrollbar->damage() is 0.

Dec. 29, 2007

[patch] make TopGroup a PackedGroup

by Johannes.Hofmann＠gmx.de

Hi, just noticed that child widgets where not redrawn properly with my patch. Attached is a fixed version against current cvs. Cheers, Johannes On Fri, Dec 28, 2007 at 05:26:19PM +0100, Johannes Hofmann wrote: > Hello, > > as I didn't get any feedback from Sebastian yet on my proposal > to make the scrollbars part of UI instead of FltkViewport, I > decided to split my initial patch. > Below is a version that still uses a PackedGroup in UI, but leaves > the scrollbars in FltkViewport. > Here comes the details: > > * Make scrollbars really children of FltkViewport, as it was > probabely intended. > * Use widget local coordinates in FltkViewport::adjustScrollbarsAndGadgets. > * Adjust draw() and handle() so that scrollbars work properly. > * As a consequence replace() now works properly, so remove the > workaround. > * Make TopGroup a PackedGroup and let it do the layout. > * Simplify fullscreen mode. > > This also fixes annoying problems with the statusbar when new windows > are created in fullscreen mode. > > Cheers, > Johannes

Dec. 28, 2007

[patch] make TopGroup a PackedGroup

by Johannes.Hofmann＠gmx.de

Hi, just noticed that child widgets where not redrawn properly with my patch. Attached is a fixed version against current cvs. Cheers, Johannes On Fri, Dec 28, 2007 at 05:26:19PM +0100, Johannes Hofmann wrote: > Hello, > > as I didn't get any feedback from Sebastian yet on my proposal > to make the scrollbars part of UI instead of FltkViewport, I > decided to split my initial patch. > Below is a version that still uses a PackedGroup in UI, but leaves > the scrollbars in FltkViewport. > Here comes the details: > > * Make scrollbars really children of FltkViewport, as it was > probabely intended. > * Use widget local coordinates in FltkViewport::adjustScrollbarsAndGadgets. > * Adjust draw() and handle() so that scrollbars work properly. > * As a consequence replace() now works properly, so remove the > workaround. > * Make TopGroup a PackedGroup and let it do the layout. > * Simplify fullscreen mode. > > This also fixes annoying problems with the statusbar when new windows > are created in fullscreen mode. > > Cheers, > Johannes

Dec. 28, 2007

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

by jcid＠dillo.org

Hi, Committed. On Thu, Dec 27, 2007 at 06:09:37PM +0000, place wrote: > 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. Yeah, quite untidy. Large is ok when there's no dillorc2, or panel_size is bad/not-present, dillorc2 in the source tree may vary. -- Cheers Jorge.-

Dec. 28, 2007

[patch] make TopGroup a PackedGroup

by Johannes.Hofmann＠gmx.de

Hello, as I didn't get any feedback from Sebastian yet on my proposal to make the scrollbars part of UI instead of FltkViewport, I decided to split my initial patch. Below is a version that still uses a PackedGroup in UI, but leaves the scrollbars in FltkViewport. Here comes the details: * Make scrollbars really children of FltkViewport, as it was probabely intended. * Use widget local coordinates in FltkViewport::adjustScrollbarsAndGadgets. * Adjust draw() and handle() so that scrollbars work properly. * As a consequence replace() now works properly, so remove the workaround. * Make TopGroup a PackedGroup and let it do the layout. * Simplify fullscreen mode. This also fixes annoying problems with the statusbar when new windows are created in fullscreen mode. Cheers, Johannes

Dec. 28, 2007

[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