- Dillo-dev - lists.mailman3.com

[patch]: Refactor {FltkListResource,FltkOptionMenuResource}::sizeRequest()
by onepoint＠starurchin.org May 6, 2008

May 6, 2008

A simple refactoring: FltkListResource and FltkOptionMenuResource use the same code to determine the maximum string width. Jeremy Henty

2 2

[bugfix]: FltkSelectionResource leaks memory
by onepoint＠starurchin.org May 6, 2008

May 6, 2008

corvid pointed this out to me. Patch attached. Jeremy Henty

2 1

Test
by sgeerken＠dillo.org May 6, 2008

May 6, 2008

Hi, this is just a test message. Sebastian

1 0

ListResources: version 3
by onepoint＠starurchin.org May 6, 2008

May 6, 2008

I am attaching two patches that get ListResource selection working properly, ie. you can click items as you wish and FltkListResource::isSelected() will now return the correct value. The first patch is my previous selection patch, unchanged. The second is a small fix that I proposed in the lout::misc::StringBuffer fix thread: it makes FltkListResource::addItem call Widget::set_selected() on fltk::Item widgets, and the call to Menu::set_item() becomes conditional on a virtual boolean hook that defaults to false, but is redefined to true in FltkOptionMenuResource() . The second patch looks bigger than it really is: most of it is just reindenting a block of code that moved inside an "if" statement. (And diff doesn't help by insisting on choosing an unnecessarily complicated set of changes.) It's not a pretty hack, but it's simple and I am wary of making deeper changes until I understand the code better. Please comment, Jeremy Henty

4 5

Q: should we select option groups
by onepoint＠starurchin.org May 6, 2008

May 6, 2008

FLTK allows both Choice and MultiBrowsers to select group items as well as normal leaf items. The Dillo Selection widget currently ignores selected group items, which could be confusing if a user selects a group and expects the application to do something about it. On the other hand the HTML 4 spec[1] reads as though only options and not option groups can be selected, though it does not say so explicitly. What should Dillo do about this? [1] http://www.htmlhelp.com/reference/html40/forms/select.html

1 0

patch: dialog.cc window deletion
by corvid＠lavabit.com May 5, 2008

May 5, 2008

Using the crude tool of top(1), I learned that viewing the source of a 500K file meant losing 500K down the drain. - If I give the text to the TextDisplay's initial buffer, it knows that it owns it. - Window::destroy() doesn't delete. The header comment in fltk/src/Window.cxx says it's some sort of 'hide' function: "Hides the window and also deletes all window system information about the window, and thus returns it back to the state it was in before the first show(). It is harmless to call this if the window is already destroyed." - And while I was in there, I threw in some callback(window_close_cb, ...)s for closing windows using the window mgr instead of a button.

2 1

[patch]: FltkListResource::sizeRequest()
by onepoint＠starurchin.org May 5, 2008

May 5, 2008

Currently FltkListResource::sizeRequest() is a stub with some hardwired values that are not very useful. This patch replaces it with something more appropriate (closely following the existing implementation of FltkOptionMenuResource::sizeRequest() ). Comments are welcome, Jeremy Henty

1 0

[BUG]: html.cc: broken Dlist iteration
by onepoint＠starurchin.org May 5, 2008

May 5, 2008

Html_build_query_data() and Html_make_multipart_boundary() iterate over a Dlist while destructively modifying it *and* recalculating the list length each time, so the iteration terminates prematurely. This makes Html_build_query_data() mangle the result when an input returns multiple values: half of the values get attached to the next input! This patch fixes the problem by caching the length of the list before modifying it so that the entire list is processed. Regards, Jeremy Henty

2 1

[patch]: select multiple
by onepoint＠starurchin.org May 5, 2008

May 5, 2008

This patch implements the MULTIPLE attribute for SELECT elements. It's small but it depends on the various patches and bugfixes I have already posted. Please comment. Regards, Jeremy Henty

1 0

[BUG]: lout::misc::StringBuffer::clear() does not invalidate the string
by onepoint＠starurchin.org May 3, 2008

May 3, 2008

Well, *that* was a bit of a wild goose chase! Remember I complained of selection problems in ListResources? It was nothing of the kind. Instead test/dw-ui-test was spuriously reporting that things were still selected when everything was in fact unselected. And the cause was a bug in lout::misc::Stringbuffer ! lout::misc::StringBuffer::clear() omits to invalidate the internal cached string, so if you call lout::misc::StringBuffer::getChars() (which updates the cached string and marks it as valid), then lout::misc::StringBuffer::clear() and then *immediately* call lout::misc::StringBuffer::getChars() again, you get the contents of the StringBuffer before you cleared it (because the cached value has not been invalidated), instead of the empty string. D'oh! One-liner patch attached. Regards, Jeremy Henty

3 4