May 2008 - Dillo-dev - lists.mailman3.com

[patch]: FltkListResource::sizeRequest()

by onepoint＠starurchin.org

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

May 5, 2008

[BUG]: html.cc: broken Dlist iteration

by Johannes.Hofmann＠gmx.de

On Mon, May 05, 2008 at 10:41:00AM +0100, Jeremy Henty wrote: > > 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. Cool, I also tried to hook up your ListResource code in html.cc, but could not find the reason why some of the selected items were missing on submit. Regards, Johannes > > Regards, > > Jeremy Henty > diff -pru -- 00_pre/src/html.cc 01_post/src/html.cc > --- 00_pre/src/html.cc 2008-05-02 18:25:13.000000000 +0100 > +++ 01_post/src/html.cc 2008-05-05 10:10:18.000000000 +0100 > @@ -4191,7 +4191,8 @@ static char *Html_make_multipart_boundar > dStr_free(dstr, 1); > } > } > - for (int i = 0; i < dList_length(values); i++) { > + int length = dList_length(values); > + for (int i = 0; i < length; i++) { > dstr = (Dstr *) dList_nth_data(values, 0); > dList_remove(values, dstr); > if (input->type != DILLO_HTML_INPUT_FILE) > @@ -4283,8 +4284,8 @@ static Dstr *Html_build_query_data(Dillo > Html_urlencode_append(DataStr, val->str); > dStr_free(val, 1); > } else { > - int i; > - for (i = 0; i < dList_length(values); i++) { > + int length = dList_length(values), i; > + for (i = 0; i < length; i++) { > Dstr *val = (Dstr *) dList_nth_data(values, 0); > dList_remove(values, val); > val = Html_encode_text(encoder, &val); > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

May 5, 2008

[patch]: select multiple

by onepoint＠starurchin.org

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

May 5, 2008

[BUG]: html.cc: broken Dlist iteration

by onepoint＠starurchin.org

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

May 5, 2008

ListResources: version 3

by Johannes.Hofmann＠gmx.de

On Fri, May 02, 2008 at 11:42:18PM +0100, Jeremy Henty wrote: > > 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, Very nice! Works great. Now I realized that it already supports submenus... Johannes

May 3, 2008

patch: dialog.cc window deletion

by corvid＠lavabit.com

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.

May 3, 2008

ListResources: version 3

by onepoint＠starurchin.org

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

May 3, 2008

[BUG]: lout::misc::StringBuffer::clear() does not invalidate the string

by onepoint＠starurchin.org

On Fri, May 02, 2008 at 09:51:46PM +0200, Johannes Hofmann wrote: > There seems to be no way to select multiply items in fltk::Menu. If I understand the fltk::Widget docs right, then you just call Widget::set_selected() on as many of the items as you want. That sets the flag that is read by Widget::selected() (which FltkListResource::widgetCallback already calls, so that seems to be the right thing to do). The problem is that the code calls Menu::set_item() to make the selected item the one that the menu displays. This is the right thing for OptionMenus but not for Lists. > Perhaps the easiest way is to comletely overwrite the addItem() > method in FltkListResource? I'm hoping that (a) calling Widget::set_selected() explicitly and (b) adding a hook to decide whether or not to call Menu::set_item() will work. Possibly the *proper* way to it will involve more rewriting as you suggest, but since I don't understand this code very well I am looking for the simplest fix rather than rewriting wholesale stuff I don't understand. Maybe later I'll have the confidence to do a proper revamp. > Does FltkListResource need to provide something like submenus? It already does. If you apply my patch and run test/dw-ui-test you can double-click on the group item in the browser and the sub-items will appear. Regards, Jeremy Henty

May 3, 2008

[BUG]: lout::misc::StringBuffer::clear() does not invalidate the string

by Johannes.Hofmann＠gmx.de

On Fri, May 02, 2008 at 06:15:44PM +0100, Jeremy Henty wrote: > On Fri, May 02, 2008 at 12:08:10PM -0400, Jorge Arellano Cid wrote: > > On Fri, May 02, 2008 at 01:48:43PM +0100, Jeremy Henty wrote: > > > > > > lout::misc::StringBuffer::clear() omits to invalidate the internal > > > cached string, > > > > I know how hard it gets to fix this kind of bugs sometimes. > > It only appears if you don't add anything to the StringBuffer between > clearing it and reading it, so it is hidden in almost all normal use. > > > BTW, does this mean the last selection patch shows no bugs anymore? > > There is one remaining issue with selections but I think it's not to > do with my patch. If several resource items are marked selected then > only the last one is selected on the FLTK menu widget. I think the > problem is that FltkSelectionResource::addItem selects the item widget > by calling set_item() on the menu widget, and that's only the right > thing to do for a fltk::Choice . For a fltk::Browser you just want to > call Widget::set_selected() on the menu item. I guess the fix is to > have a virtual hook in FltkSelectionResource and have each of > FltkListResource and FltkOptionMenuResource override the hook to do > the right thing. *If* I'm right then my selection patch is good as it > stands. I'll have a go at a patch and see if it works. Oh, that's nasty. There seems to be no way to select multiply items in fltk::Menu. As far as I can see one needs a fltk::Browser object for that. Perhaps the easiest way is to comletely overwrite the addItem() method in FltkListResource? Does FltkListResource need to provide something like submenus? Regards, Johannes > > I'd be glad of any tips for doing this. The fltk::Menu internals are > confusing and I'm also not familiar with the WidgetStack machinery in > FltkSelectionResource . > > Regards, > > Jeremy Henty > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

May 2, 2008

patch: Re: [Dillo-dev] dillo-fltk on x86_64

by jcid＠dillo.org

On Fri, May 02, 2008 at 03:52:44PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Apr 30, 2008 at 08:52:06PM +0000, corvid wrote: > > > Jorge wrote: > > > > A patch for ~/.dillo creation was just committed. > > > > > > I think dillo should tell the user that it is creating the directory. > > > > Committed. > > Shouldn't it be something like the following? > > (BTW, I had to set prefs.show_msg to get MSGs out of this and a_Prefs_init(), > but setting it in dillo.cc doesn't feel like a good thing to do.) > Ooops, yes. Looks like I've had to little time lately. A fix was committed. Please check! :-) -- Cheers Jorge.-

May 2, 2008