- Dillo-dev - lists.mailman3.com

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