- Dillo-dev - lists.mailman3.com

[patch]: Refactor {FltkListResource,FltkOptionMenuResource}::sizeRequest()

by onepoint＠starurchin.org

> A simple refactoring: FltkListResource and FltkOptionMenuResource > use the same code to determine the maximum string width. And here's the patch! D'oh!

May 6, 2008

[patch]: Refactor {FltkListResource,FltkOptionMenuResource}::sizeRequest()

by onepoint＠starurchin.org

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

May 6, 2008

[bugfix]: FltkSelectionResource leaks memory

by onepoint＠starurchin.org

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

May 6, 2008

Q: should we select option groups

by onepoint＠starurchin.org

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

May 6, 2008

ListResources: version 3

by jcid＠dillo.org

On Mon, May 05, 2008 at 11:40:52PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jorge Arellano Cid wrote: > > [..] > > * Used (long) cast for 64bit compatibility (please somebody test). > > That would be me ;) Gotcha! > I haven't looked into whether the added functionality works (didn't know > where to look), but it compiles cleanly and runs just fine. Please check the attached page. You should be able to select any set from the list, and to confirm it works by pressing the test button and looking at the generated URL. > It's nice that you kept an eye on the platform issue ;) Sure. -- Cheers Jorge.-

May 6, 2008

Dillo freeze

by corvid＠lavabit.com

Jorge wrote: > Dillo freezes on this page: > > http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.6.tar.bz2.sign > > Dillo bug or FLTK2? I ran into this a few months ago with http://p3p.yahoo.com/w3c/p3p.xml (and then eventually forgot about it). They are both tiny and fit in a packet, which might be significant...

May 6, 2008

Dillo freeze

by jcid＠dillo.org

Hi there, Dillo freezes on this page: http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.24.6.tar.bz2.sign Dillo bug or FLTK2? -- Cheers Jorge.-

May 5, 2008

ListResources: version 3

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jorge Arellano Cid wrote: > [..] > * Used (long) cast for 64bit compatibility (please somebody test). That would be me ;) I haven't looked into whether the added functionality works (didn't know where to look), but it compiles cleanly and runs just fine. It's nice that you kept an eye on the platform issue ;) Cheers, Justus - -- gpg key fingerprint: C82D 382A AB38 1A54 5290 19D6 A0F9 B035 686C 6996 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIH37koPmwNWhsaZYRAk+fAJ48XIMCFjaD/TbxOSYjciW1brFG+ACeJGvV qgdJPm591wlzYHgXEJxfG9Y= =xmAr -----END PGP SIGNATURE-----

May 5, 2008

patch: dialog.cc window deletion

by jcid＠dillo.org

On Sat, May 03, 2008 at 04:39:34AM +0000, corvid wrote: > 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. > Committed! Funny how the Escape key started working again as close shortcut. -- Cheers Jorge.-

May 5, 2008

ListResources: version 3

by jcid＠dillo.org

Hi Jeremy, In a nutshell: 00__html_dlist_fix.dillo2 10__html_select_multiple.dillo2 10__listresource.dw2 15__listresource_selection.dw2 16__listresource_sizerequest.dw2 committed with minor changes! Some minor changes: * Used (long) cast for 64bit compatibility (please somebody test). * single return point in FltkListResource::widgetCallback. * added some comments. * Removed: //blindly copied from FltkOptionMenuResource, is it necessary? R: yes, it's necessary. Each new added item may change the Width. 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() . Yes, it looks simple enough. Added a reminding comment anyway. > [...] > 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() ). Added some minor adjustments to fit the new size. Good work! -- Cheers Jorge.-

May 5, 2008

[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

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

by onepoint＠starurchin.org

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. 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

May 2, 2008

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

by jcid＠dillo.org

On Fri, May 02, 2008 at 01:48:43PM +0100, Jeremy Henty wrote: > > 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. Good you found it! I know how hard it gets to fix this kind of bugs sometimes. Committed. BTW, does this mean the last selection patch shows no bugs anymore? -- Cheers Jorge.-

May 2, 2008

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

by corvid＠lavabit.com

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.)

May 2, 2008

dillo-fltk on x86_64

by jcid＠dillo.org

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. -- Cheers Jorge.-

May 2, 2008

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

by onepoint＠starurchin.org

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

May 2, 2008

[patch]: take 2: FtlkListResource

by Johannes.Hofmann＠gmx.de

On Thu, May 01, 2008 at 03:09:41PM +0100, Jeremy Henty wrote: > > Since Johannes' criticisms were (IIRC) mostly about my patch's > complexity I hope he will look at a new patch that sticks to my > original approach but is a lot simpler. > > I realised that if the user_data() of the Menu Widget items stored the > index of the Item instead of the Item itself then FltkListResource > could store the selections by index in a misc::SimpleVector<bool>. > This means there is no need to wrap bools in object::Object pointers > and no need to add instance methods to Items to make them > Hashable. Most of the scaffolding of the previous patch just > disappears (the line count decreases by a third). > > I don't want to dismiss Johannes' alternative suggestion out of hand, > but I still think my approach has a lot going for it and I'd like > people to have a chance to criticise my best shot at it. Very nice. This is really much simpler. I also understand, your point about not to extend Item with members specific for this usecase. Cheers, Johannes > > Comments are welcome! > > Jeremy Henty > diff -pru -- 00_pre/dw/fltkui.cc 01_post/dw/fltkui.cc > --- 00_pre/dw/fltkui.cc 2008-04-26 21:42:58.000000000 +0100 > +++ 01_post/dw/fltkui.cc 2008-05-01 14:00:11.000000000 +0100 > @@ -858,10 +858,11 @@ template <class I> FltkSelectionResource > } > > template <class I> > -::fltk::Item *FltkSelectionResource::Item::createNewWidget () > +::fltk::Item *FltkSelectionResource::Item::createNewWidget (int index) > { > - ::fltk::Item *item = new ::fltk::Item (name); > - item->user_data (this); > + ::fltk::Item *item = > + new ::fltk::Item (name); > + item->user_data ((void *) index); > return item; > } > > @@ -869,7 +870,10 @@ template <class I> > ::fltk::ItemGroup * > FltkSelectionResource::Item::createNewGroupWidget () > { > - return new ::fltk::ItemGroup (name); > + ::fltk::ItemGroup *itemGroup = > + new ::fltk::ItemGroup (name); > + itemGroup->user_data ((void *) -1); > + return itemGroup; > } > > > @@ -922,12 +926,14 @@ FltkSelectionResource::createNewWidge > > ::fltk::Group *currGroup = widgetStack->stack->getTop()->getTypedValue(); > > + int index = 0; > for (Iterator <Item> it = allItems->iterator (); it.hasNext (); ) { > Item *item = it.getNext (); > switch (item->type) { > case Item::ITEM: > - itemWidget = item->createNewWidget (); > + itemWidget = item->createNewWidget (index); > currGroup->add (itemWidget); > + index++; > break; > > case Item::START: > @@ -960,6 +966,7 @@ template <class I> void FltkSelectionRes > bool enabled, > bool selected) > { > + int index = items->size (); > Item *item = createNewItem (Item::ITEM, str, enabled, selected); > items->put (item); > allItems->append (item); > @@ -967,7 +974,7 @@ template <class I> void FltkSelectionRes > for (Iterator <WidgetStack> it = widgetStacks->iterator (); > it.hasNext(); ) { > WidgetStack *widgetStack = it.getNext (); > - ::fltk::Item *itemWidget = item->createNewWidget (); > + ::fltk::Item *itemWidget = item->createNewWidget (index); > widgetStack->stack->getTop()->getTypedValue()->add (itemWidget); > > if (!enabled) > @@ -1031,10 +1038,10 @@ template <class I> const char *FltkSelec > // ---------------------------------------------------------------------- > > FltkOptionMenuResource::FltkOptionMenuResource (FltkPlatform *platform): > - FltkSelectionResource <dw::core::ui::OptionMenuResource> (platform) > + FltkSelectionResource <dw::core::ui::OptionMenuResource> (platform), > + selection(-1) > { > init (platform); > - selection = NULL; > } > > FltkOptionMenuResource::~FltkOptionMenuResource () > @@ -1057,7 +1064,7 @@ void FltkOptionMenuResource::widgetCallb > void *data) > { > ((FltkOptionMenuResource *) data)->selection = > - ((::fltk::Menu *) widget)->item()->user_data(); > + (int) (((::fltk::Menu *) widget)->item()->user_data()); > } > > void FltkOptionMenuResource::sizeRequest (core::Requisition *requisition) > @@ -1092,14 +1099,14 @@ void FltkOptionMenuResource::addItem (co > FltkSelectionResource<dw::core::ui::OptionMenuResource>::addItem > (str,enabled,selected); > if (selected) > - selection = items->get (items->size()-1); > + selection = (items->size ()) - 1; > > queueResize (true); > } > > bool FltkOptionMenuResource::isSelected (int index) > { > - return items->get(index) == selection; > + return index == selection; > } > > // ---------------------------------------------------------------------- > @@ -1107,7 +1114,8 @@ bool FltkOptionMenuResource::isSelected > FltkListResource::FltkListResource (FltkPlatform *platform, > core::ui::ListResource::SelectionMode > selectionMode): > - FltkSelectionResource <dw::core::ui::ListResource> (platform) > + FltkSelectionResource <dw::core::ui::ListResource> (platform), > + itemsSelected(8) > { > init (platform); > } > @@ -1119,10 +1127,34 @@ FltkListResource::~FltkListResource () > > ::fltk::Menu *FltkListResource::createNewMenu (core::Allocation *allocation) > { > - return > + ::fltk::Menu *menu = > new ::fltk::MultiBrowser (allocation->x, allocation->y, > allocation->width, > allocation->ascent + allocation->descent); > + menu->callback(widgetCallback,this); > + menu->when(::fltk::WHEN_CHANGED); > + return menu; > +} > + > +void FltkListResource::widgetCallback (::fltk::Widget *widget, void *data) > +{ > + ::fltk::Widget *fltkItem = ((::fltk::Menu *) widget)->item (); > + int index = (int) (fltkItem->user_data ()); > + if (index == -1) return; > + bool selected = fltkItem->selected (); > + ((FltkListResource *) data)->itemsSelected.set (index, selected); > +} > + > +void FltkListResource::addItem (const char *str, bool enabled, bool selected) > +{ > + FltkSelectionResource<dw::core::ui::ListResource>::addItem > + (str,enabled,selected); > + int index = itemsSelected.size (); > + itemsSelected.increase (); > + itemsSelected.set (index,selected); > + > + // blindly copied from FltkOptionMenuResource, is it necessary? > + queueResize (true); > } > > void FltkListResource::sizeRequest (core::Requisition *requisition) > @@ -1135,8 +1167,7 @@ void FltkListResource::sizeRequest (core > > bool FltkListResource::isSelected (int index) > { > - /** todo Not implemented. */ > - return true; > + return itemsSelected.get (index); > } > > } // namespace ui > diff -pru -- 00_pre/dw/fltkui.hh 01_post/dw/fltkui.hh > --- 00_pre/dw/fltkui.hh 2008-04-26 21:42:58.000000000 +0100 > +++ 01_post/dw/fltkui.hh 2008-05-01 14:00:11.000000000 +0100 > @@ -458,8 +458,8 @@ protected: > bool selected = false); > ~Item (); > > - ::fltk::Item *createNewWidget (); > - ::fltk::ItemGroup *createNewGroupWidget (); > + ::fltk::Item *createNewWidget (int index); > + ::fltk::ItemGroup *createNewGroupWidget (); > }; > > class WidgetStack: public object::Object > @@ -508,7 +508,7 @@ protected: > > private: > static void widgetCallback (::fltk::Widget *widget, void *data); > - void *selection; > + int selection; > > public: > FltkOptionMenuResource (FltkPlatform *platform); > @@ -526,11 +526,17 @@ class FltkListResource: > protected: > ::fltk::Menu *createNewMenu (core::Allocation *allocation); > > +private: > + static void widgetCallback (::fltk::Widget *widget, void *data); > + misc::SimpleVector <bool> itemsSelected; > + > public: > FltkListResource (FltkPlatform *platform, > core::ui::ListResource::SelectionMode selectionMode); > ~FltkListResource (); > > + void addItem (const char *str, bool enabled, bool selected); > + > void sizeRequest (core::Requisition *requisition); > bool isSelected (int index); > }; > diff -pru -- 00_pre/test/dw_ui_test.cc 01_post/test/dw_ui_test.cc > --- 00_pre/test/dw_ui_test.cc 2008-04-26 21:42:59.000000000 +0100 > +++ 01_post/test/dw_ui_test.cc 2008-05-01 14:00:11.000000000 +0100 > @@ -192,7 +192,7 @@ int main(int argc, char **argv) > checklabel->addText (strdup (" check"), cellStyle); > checklabel->flush (); > > - for(int i = 0; i < 1; i++) { > + for(int i = 0; i < 2; i++) { > table->addRow (cellStyle); > > Embed *sel = new Embed (selres[i]); > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

May 1, 2008

[patch]: take 2: FtlkListResource

by onepoint＠starurchin.org

Since Johannes' criticisms were (IIRC) mostly about my patch's complexity I hope he will look at a new patch that sticks to my original approach but is a lot simpler. I realised that if the user_data() of the Menu Widget items stored the index of the Item instead of the Item itself then FltkListResource could store the selections by index in a misc::SimpleVector<bool>. This means there is no need to wrap bools in object::Object pointers and no need to add instance methods to Items to make them Hashable. Most of the scaffolding of the previous patch just disappears (the line count decreases by a third). I don't want to dismiss Johannes' alternative suggestion out of hand, but I still think my approach has a lot going for it and I'd like people to have a chance to criticise my best shot at it. Comments are welcome! Jeremy Henty

May 1, 2008

[patch]: FtlkListResource select callbacks

by onepoint＠starurchin.org

On Wed, Apr 30, 2008 at 10:52:37PM +0200, Johannes Hofmann wrote: > > This is a first cut at making FltkListResource work properly. > > > > The resource maintains a hash of its items' selected status, the > > MultiBrowser widget gets a callback that updates the hash and > > isSelected() looks up the hash for the answer. It's the same > > technique I used for FltkOptionMenuResource , where the FLTK > > widgets are linked to their resources by user_data() and callback > > arguments. > > > > I added equals() and hashValue() methods to Items so they could be > > hash keys, and implemented an object::Object wrapper class for > > boolean values to be the hash values. The wrapper class is inside > > FltkListResource , though it could easily move to lout::object > > IMHO. > > It seems a bit complicated to me. Wouldn't it be easier to just add > a member "selected" to Item that stores whether the item is > currently selected or not? May well be that I'm missing something > though. It's not so much complicated as cumbersome: the logic is pretty straightforward, but using the Hash requires extra scaffolding. I was reluctant to add stuff to Item because that class serves double duty for both FltkListResource and FltkOptionMenuResource and so it's ugly for Item to contain stuff that is specific to one of the resource classes. Of course the resource classes could derive their own Item classes, but that adds scaffolding too. IIRC I experimented with that when I first did FltkOptionMenuResource (before going for a simpler suggestion of yours, I think) and the templating made it particularly messy. Let me think about it a little while I fix the bugs. I think the bug fixes will be orthogonal to the issue of how we store the selection information so it shouldn't impact implementing your suggestions if that's the way to go. Regards, Jeremy Henty

May 1, 2008

[patch]: FtlkListResource select callbacks

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Wed, Apr 30, 2008 at 09:33:36PM +0100, Jeremy Henty wrote: > > This is a first cut at making FltkListResource work properly. > > The resource maintains a hash of its items' selected status, the > MultiBrowser widget gets a callback that updates the hash and > isSelected() looks up the hash for the answer. It's the same > technique I used for FltkOptionMenuResource , where the FLTK widgets > are linked to their resources by user_data() and callback arguments. > > I added equals() and hashValue() methods to Items so they could be > hash keys, and implemented an object::Object wrapper class for boolean > values to be the hash values. The wrapper class is inside > FltkListResource , though it could easily move to lout::object IMHO. It seems a bit complicated to me. Wouldn't it be easier to just add a member "selected" to Item that stores whether the item is currently selected or not? May well be that I'm missing something though. Cheers, Johannes > > The patch also enables the ListResource widget in test/dw-ui-test . > > Unfortunately it's still a little buggy. Specifying multiple selected > items initially doesn't work right: they are all selected in the > resource but only one is selected on the FLTK widget. Things also go > out of sync when you select a group item: any previously selected item > is unselected in the widget but not in the resource. I'll look into > these further. > > Comments are welcome! > > Regards, > > Jeremy Henty > diff -pru -- 00_pre/dw/fltkui.cc 01_post/dw/fltkui.cc > --- 00_pre/dw/fltkui.cc 2008-04-26 21:42:58.000000000 +0100 > +++ 01_post/dw/fltkui.cc 2008-04-30 20:37:40.000000000 +0100 > @@ -858,6 +858,22 @@ template <class I> FltkSelectionResource > } > > template <class I> > +bool FltkSelectionResource::Item::equals (Object *other) > +{ > + return ((void *) this) == ((void *) other); > +} > + > +template <class I> > +int FltkSelectionResource::Item::hashValue () > +{ > +#if SIZEOF_VOID_P == 4 > + return (int)this; > +#else > + return ((int*) this)[0] ^ ((int*) this)[1]; > +#endif > +} > + > +template <class I> > ::fltk::Item *FltkSelectionResource::Item::createNewWidget () > { > ::fltk::Item *item = new ::fltk::Item (name); > @@ -1107,7 +1123,8 @@ bool FltkOptionMenuResource::isSelected > FltkListResource::FltkListResource (FltkPlatform *platform, > core::ui::ListResource::SelectionMode > selectionMode): > - FltkSelectionResource <dw::core::ui::ListResource> (platform) > + FltkSelectionResource <dw::core::ui::ListResource> (platform), > + itemsSelected(false,false) > { > init (platform); > } > @@ -1119,10 +1136,34 @@ FltkListResource::~FltkListResource () > > ::fltk::Menu *FltkListResource::createNewMenu (core::Allocation *allocation) > { > - return > + ::fltk::Menu *menu = > new ::fltk::MultiBrowser (allocation->x, allocation->y, > allocation->width, > allocation->ascent + allocation->descent); > + menu->callback(widgetCallback,this); > + menu->when(::fltk::WHEN_CHANGED); > + return menu; > +} > + > +void FltkListResource::widgetCallback (::fltk::Widget *widget, void *data) > +{ > + ::fltk::Widget *fltkItem = ((::fltk::Menu *) widget)->item (); > + Item *item = (Item *) (fltkItem->user_data ()); > + if (!item) return; > + Selection *selected = Selection::fromBool(fltkItem->selected ()); > + ((FltkListResource *) data)->itemsSelected.put (item, selected); > +} > + > +void FltkListResource::addItem (const char *str, bool enabled, bool selected) > +{ > + FltkSelectionResource<dw::core::ui::ListResource>::addItem > + (str,enabled,selected); > + Item *item = items->get (items->size()-1); > + Selection *is_selected = Selection::fromBool (selected); > + itemsSelected.put(item,is_selected); > + > + // blindly copied from FltkOptionMenuResource, is it necessary? > + queueResize (true); > } > > void FltkListResource::sizeRequest (core::Requisition *requisition) > @@ -1135,8 +1176,15 @@ void FltkListResource::sizeRequest (core > > bool FltkListResource::isSelected (int index) > { > - /** todo Not implemented. */ > - return true; > + return itemsSelected.get(items->get(index))->getValue(); > +} > + > +FltkListResource::Selection FltkListResource::Selection::SELECTED(true); > +FltkListResource::Selection FltkListResource::Selection::UNSELECTED(false); > + > +FltkListResource::Selection *FltkListResource::Selection::fromBool(bool value) > +{ > + return value ? &SELECTED : &UNSELECTED; > } > > } // namespace ui > diff -pru -- 00_pre/dw/fltkui.hh 01_post/dw/fltkui.hh > --- 00_pre/dw/fltkui.hh 2008-04-26 21:42:58.000000000 +0100 > +++ 01_post/dw/fltkui.hh 2008-04-30 20:37:40.000000000 +0100 > @@ -458,6 +458,9 @@ protected: > bool selected = false); > ~Item (); > > + bool equals (Object *other); > + int hashValue (); > + > ::fltk::Item *createNewWidget (); > ::fltk::ItemGroup *createNewGroupWidget (); > }; > @@ -526,11 +529,31 @@ class FltkListResource: > protected: > ::fltk::Menu *createNewMenu (core::Allocation *allocation); > > +private: > + > + class Selection : public Object { > + > + private: > + bool value; > + > + public: > + Selection(bool value) { this->value = value; } > + inline int getValue() { return value; } > + > + static Selection SELECTED, UNSELECTED; > + static Selection *fromBool (bool value); > + }; > + > + static void widgetCallback (::fltk::Widget *widget, void *data); > + container::typed::HashTable <Item, Selection> itemsSelected; > + > public: > FltkListResource (FltkPlatform *platform, > core::ui::ListResource::SelectionMode selectionMode); > ~FltkListResource (); > > + void addItem (const char *str, bool enabled, bool selected); > + > void sizeRequest (core::Requisition *requisition); > bool isSelected (int index); > }; > diff -pru -- 00_pre/test/dw_ui_test.cc 01_post/test/dw_ui_test.cc > --- 00_pre/test/dw_ui_test.cc 2008-04-26 21:42:59.000000000 +0100 > +++ 01_post/test/dw_ui_test.cc 2008-04-30 20:37:40.000000000 +0100 > @@ -192,7 +192,7 @@ int main(int argc, char **argv) > checklabel->addText (strdup (" check"), cellStyle); > checklabel->flush (); > > - for(int i = 0; i < 1; i++) { > + for(int i = 0; i < 2; i++) { > table->addRow (cellStyle); > > Embed *sel = new Embed (selres[i]); > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

April 30, 2008

dillo-fltk on x86_64

by corvid＠lavabit.com

Jorge wrote: > A patch for ~/.dillo creation was just committed. I think dillo should tell the user that it is creating the directory.

April 30, 2008

[patch]: FtlkListResource select callbacks

by onepoint＠starurchin.org

This is a first cut at making FltkListResource work properly. The resource maintains a hash of its items' selected status, the MultiBrowser widget gets a callback that updates the hash and isSelected() looks up the hash for the answer. It's the same technique I used for FltkOptionMenuResource , where the FLTK widgets are linked to their resources by user_data() and callback arguments. I added equals() and hashValue() methods to Items so they could be hash keys, and implemented an object::Object wrapper class for boolean values to be the hash values. The wrapper class is inside FltkListResource , though it could easily move to lout::object IMHO. The patch also enables the ListResource widget in test/dw-ui-test . Unfortunately it's still a little buggy. Specifying multiple selected items initially doesn't work right: they are all selected in the resource but only one is selected on the FLTK widget. Things also go out of sync when you select a group item: any previously selected item is unselected in the widget but not in the resource. I'll look into these further. Comments are welcome! Regards, Jeremy Henty

April 30, 2008

dillo-fltk on x86_64

by jcid＠dillo.org

Hi On Sun, Apr 27, 2008 at 03:46:11AM +0200, Justus Winter wrote: > [...] > >> With my three patches applied dillo compiles and runs fine, however I > >> had to create ~/.dillo and manually start dpid. Did I miss something here? > > No, I forgot porting the creation of ~/.dillo from dillo1 to dillo2! > > (as we all run dillo1 before, ~/.dillo was there :-) A patch for ~/.dillo creation was just committed. -- Cheers Jorge.-

April 30, 2008

[patch] ignore SIGPIPE

by jcid＠dillo.org

On Thu, Apr 24, 2008 at 08:10:04PM +0200, Johannes Hofmann wrote: > Hello, > > this patch avoids exits on SIGPIPE. Currently this is only observed > on DragonFly, but dillo1 had this too. Committed (with comment). -- Cheers Jorge.-

April 30, 2008

[patch] cleanup iterator fix

by jcid＠dillo.org

On Wed, Apr 30, 2008 at 05:21:55PM +0200, Johannes Hofmann wrote: > Hi, > > now I noticed, that there is a more elegant way to create an > iterator that is winded forward until its end. > This restores symmetry between DeepIterator::next() and > DeepIterator::prev(). Committed. -- Cheers Jorge.-

April 30, 2008

[patch] two more tiny memory leaks

by jcid＠dillo.org

On Wed, Apr 30, 2008 at 05:24:00PM +0200, Johannes Hofmann wrote: > Hi, > > two more small leaks in dw2 found by valgrind. Committed. -- Cheers Jorge.-

April 30, 2008

patch: Re: patch: Re: [Dillo-dev] start on image maps (dw-part)

by jcid＠dillo.org

On Wed, Apr 30, 2008 at 02:38:17PM +0000, corvid wrote: > Jorge wrote: > > It'd be good to hook emitMotionNotify() to have URL feedback > > for ISMAP in the status box. > > Attached. Great! Committed. -- Cheers Jorge.-

April 30, 2008

patch: motionNotify and LEAVE

by jcid＠dillo.org

On Tue, Apr 29, 2008 at 09:43:09PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Apr 28, 2008 at 09:21:16PM +0000, corvid wrote: > > > Since findtext has been in the news lately, I might as well > > > at least provide this bit so that my code behaves better with dialogs. > > > > > > > What is this patch for? > > If searching with the findtext dialog caused scrolling, the code > had been showing the url of the link that happened to be under the > cursor underneath the dialog. OK. Committed. -- Cheers Jorge.-

April 30, 2008

FIXED: [PATCH]: call widget->layout_damage() from FltkWidgetView::allocateFltkWidget

by jcid＠dillo.org

On Tue, Apr 29, 2008 at 04:37:08PM +0100, Jeremy Henty wrote: > > D'oh! "||" where I should have used "|"! What a n00b! Here's the > fixed patch. (And this time I have tested by running all the > executables in dw/test/ .) Good. Committed with an extra comment. -- Cheers Jorge.-

April 30, 2008

[patch] two more tiny memory leaks

by Johannes.Hofmann＠gmx.de

Hi, two more small leaks in dw2 found by valgrind. Cheers, Johannes

April 30, 2008

[patch] cleanup iterator fix

by Johannes.Hofmann＠gmx.de

Hi, now I noticed, that there is a more elegant way to create an iterator that is winded forward until its end. This restores symmetry between DeepIterator::next() and DeepIterator::prev(). Cheers, Johannes

April 30, 2008

patch: Re: patch: Re: [Dillo-dev] start on image maps (dw-part)

by corvid＠lavabit.com

Jorge wrote: > It'd be good to hook emitMotionNotify() to have URL feedback > for ISMAP in the status box. Attached.

April 30, 2008

patch: usemap <area shape=default>

by jcid＠dillo.org

On Tue, Apr 29, 2008 at 09:21:56PM +0000, corvid wrote: > shape=default is the background in a client-side image map. > Committed. -- Cheers Jorge.-

April 30, 2008

Q: lout::Object::Bool ?

by onepoint＠starurchin.org

I'm looking at properly implementing dw::fltk::ui::FltkListResource::isSelected() and I need to maintain a hash of Items to boolean values. However, lout::container::typed::HashTable requires the keys and values to inherit lout::object::Object . I could use lout::object::Integer values, but the really appropriate thing would be lout::object::Bool , which doesn't exist. Is it worth implementing lout::object::Bool or should I just use lout::object::Integer ? Regards, Jeremy Henty

April 30, 2008

[patch]: remove redundant #include in fltkflatview.cc

by jcid＠dillo.org

On Tue, Apr 29, 2008 at 07:29:21PM +0100, Jeremy Henty wrote: > > A small cleanup: the "#include <fltk/damage.h>" in fltkflatview.cc is > unnecessary. Committed. -- Cheers Jorge.-

April 30, 2008

[patch] fix table destructor

by jcid＠dillo.org

On Tue, Apr 29, 2008 at 04:09:08PM +0200, Johannes Hofmann wrote: > Hi, > > with memleaks in the news lately.... Here comes another one. Committed. -- Cheers Jorge.-

April 30, 2008

patch: motionNotify and LEAVE

by corvid＠lavabit.com

Jorge wrote: > On Mon, Apr 28, 2008 at 09:21:16PM +0000, corvid wrote: > > Since findtext has been in the news lately, I might as well > > at least provide this bit so that my code behaves better with dialogs. > > > > What is this patch for? If searching with the findtext dialog caused scrolling, the code had been showing the url of the link that happened to be under the cursor underneath the dialog.

April 29, 2008

patch: fltkimgbuf memleak

by jcid＠dillo.org

On Tue, Apr 29, 2008 at 01:24:49AM +0000, corvid wrote: > You should see a significant decrease in memory used. Committed. What a gross leak! -- Cheers Jorge.-

April 29, 2008

patch: usemap <area shape=default>

by corvid＠lavabit.com

shape=default is the background in a client-side image map.

April 29, 2008

patch: motionNotify and LEAVE

by jcid＠dillo.org

On Mon, Apr 28, 2008 at 09:21:16PM +0000, corvid wrote: > Since findtext has been in the news lately, I might as well > at least provide this bit so that my code behaves better with dialogs. > What is this patch for? > diff -pur dw2/dw/fltkviewport.cc dw2-cur/dw/fltkviewport.cc > --- dw2/dw/fltkviewport.cc 2008-04-26 18:21:55.000000000 +0000 > +++ dw2-cur/dw/fltkviewport.cc 2008-04-28 20:40:43.000000000 +0000 > @@ -273,6 +273,10 @@ int FltkViewport::handle (int event) > positionChanged(); > break; > > + case ::fltk::LEAVE: > + mouse_x = mouse_y = -1; > + break; > + > case ::fltk::SHORTCUT: > switch (::fltk::event_key()) { > case PageUpKey: > @@ -324,14 +328,15 @@ void FltkViewport::setCanvasSize (int wi > } > > /* > - * This is needed when a position change is not the result of mouse motion. > + * This is used to simulate mouse motion (e.g., when scrolling). > */ > void FltkViewport::positionChanged () > { > - (void)theLayout->motionNotify (this, > - translateViewXToCanvasX (mouse_x), > - translateViewYToCanvasY (mouse_y), > - (core::ButtonState)0); > + if (mouse_x != -1) > + (void)theLayout->motionNotify (this, > + translateViewXToCanvasX (mouse_x), > + translateViewYToCanvasY (mouse_y), > + (core::ButtonState)0); > } > > /* > diff -pur dw2/dw/textblock.cc dw2-cur/dw/textblock.cc > --- dw2/dw/textblock.cc 2008-04-17 13:30:05.000000000 +0000 > +++ dw2-cur/dw/textblock.cc 2008-04-28 20:52:39.000000000 +0000 > @@ -549,12 +549,12 @@ bool Textblock::motionNotifyImpl (core:: > > void Textblock::enterNotifyImpl (core::EventCrossing *event) > { > - hoverLink = -1; > } > > void Textblock::leaveNotifyImpl (core::EventCrossing *event) > { > - (void) emitLinkEnter (-1, -1, -1, -1); > + hoverLink = -1; > + (void) emitLinkEnter (hoverLink, -1, -1, -1); > } > > /** > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev -- Cheers Jorge.-

April 29, 2008

Cheering some recent improvements in table layout

by jcid＠dillo.org

Hi Jeremy, On Sun, Apr 27, 2008 at 07:22:05AM +0100, Jeremy Henty wrote: > > Just to say that I'm seeing much better table rendering now. I have a > page with a large two-column table. For a while recently this > rendered very strangely in Dillo: it appeared with the two columns at > opposite sides of the page, then the second column would move over to > the left, one item at a time, to sit next to the first. But now the > table immediately appears with both columns in the right place. I > don't know what caused the strange realignment behaviour but I'm glad > it's gone. Great! There were several minor typo-bug fixes and who knows which one of them made it for you. Please send me a compressed version of the test page you use. -- Cheers Jorge.-

April 29, 2008