- Dillo-dev - lists.mailman3.com

[PATCH] FLTK Resources should call ::fltk::setfont before ::fltk::getwidth

by onepoint＠starurchin.org

On Sun, Dec 23, 2007 at 12:12:51PM -0300, Jorge Arellano Cid wrote: > With regard to dialog: it'd be nice to set the font size > considering prefs.font_factor. OK, here's a patch but I'm not sure how to test it. What's an easy way to get dillo-fltk to show a dialog? Last time I looked the https dpi dialogs failed to appear. Regards, Jeremy Henty

Dec. 23, 2007

[PATCH] FLTK Resources should call ::fltk::setfont before ::fltk::getwidth

by onepoint＠starurchin.org

On Sun, Dec 23, 2007 at 12:12:51PM -0300, Jorge Arellano Cid wrote: > For fltkpreview.cc, it'd be good to at least add a commented > statement because it clearly is in a state of flux (and ifdefed > out). Heh, I hadn't noticed it was ifdefed! Here's a patch that moves the setfont() call to the top of the function and adds a comment explaining why it must be there. There's no change to the functionality since the interviewing code is commented out. Regards, Jeremy Henty

Dec. 23, 2007

[PATCH] FLTK Resources should call ::fltk::setfont before ::fltk::getwidth

by jcid＠dillo.org

Hi Jeremy, On Sun, Dec 23, 2007 at 02:40:38PM +0000, Jeremy Henty wrote: > > If you point Dillo at > <URL:http://starurchin.org/dillo/bugs/form_setfont.html> you'll see > that the textareas are rendered with different widths despite having > the same number of columns. I see. Good example. > The problem is that FltkResource objects > don't call ::fltk::setfont before calling ::fltk::getwidth to > calculate their width, so they use the font that was set by the > previous header elements, even though those elements were properly > closed in the HTML source. OK. > This patch adds the missing ::fltk::setfont calls to > Fltk{Entry,Button,Multiline}Resource . Committed! > I've looked at all other uses of ::fltk::getwidth. The ones in > dw2-cur/dw/fltkplatform.cc are properly protected by calls to > ::fltk::setfont , but the ones in dw2-cur/dw/fltkpreview.cc and > dillo2-cur/src/dialog.cc are not. I can't tell if they need to be > protected, perhaps the current FLTK font is always correct when they > are called? Thoughts? Yes, they should be protected. AFAIS, every function sets its proper font, but doesn't restore the previous one. With regard to dialog: it'd be nice to set the font size considering prefs.font_factor. For fltkpreview.cc, it'd be good to at least add a commented statement because it clearly is in a state of flux (and ifdefed out). -- Cheers Jorge.-

Dec. 23, 2007

[PATCH] FLTK Resources should call ::fltk::setfont before ::fltk::getwidth

by onepoint＠starurchin.org

If you point Dillo at <URL:http://starurchin.org/dillo/bugs/form_setfont.html> you'll see that the textareas are rendered with different widths despite having the same number of columns. The problem is that FltkResource objects don't call ::fltk::setfont before calling ::fltk::getwidth to calculate their width, so they use the font that was set by the previous header elements, even though those elements were properly closed in the HTML source. This patch adds the missing ::fltk::setfont calls to Fltk{Entry,Button,Multiline}Resource . I've looked at all other uses of ::fltk::getwidth. The ones in dw2-cur/dw/fltkplatform.cc are properly protected by calls to ::fltk::setfont , but the ones in dw2-cur/dw/fltkpreview.cc and dillo2-cur/src/dialog.cc are not. I can't tell if they need to be protected, perhaps the current FLTK font is always correct when they are called? Thoughts? Regards, Jeremy Henty

Dec. 23, 2007

[PATCH] FltkViewport fixes and TextEditor for FltkMultiLineResource

by jcid＠dillo.org

On Sat, Dec 22, 2007 at 12:58:52PM +0000, Jeremy Henty wrote: > > Finally (I hope)! This patch changes FltkMultiLineResource to use the > FLTK TextEditor. It includes fixes for the double free problem in > FltkMultiLineResource that Johannes found, Johannes' fixes for the > Viewport drawing code and the patch for the Viewport scrolling bug > (which was previously posted separately so please ignore that post). Committed! It is soothing to see dillo2 progressing day by day. Thanks a lot, and keep the patches coming! -- Cheers Jorge.-

Dec. 22, 2007

[PATCH] FltkViewport fixes and TextEditor for FltkMultiLineResource

by onepoint＠starurchin.org

Finally (I hope)! This patch changes FltkMultiLineResource to use the FLTK TextEditor. It includes fixes for the double free problem in FltkMultiLineResource that Johannes found, Johannes' fixes for the Viewport drawing code and the patch for the Viewport scrolling bug (which was previously posted separately so please ignore that post). Regards, Jeremy Henty diff -pru -- dw2-ref/dw/fltkui.cc dw2-cur/dw/fltkui.cc --- dw2-ref/dw/fltkui.cc 2007-12-19 12:26:59.000000000 +0000 +++ dw2-cur/dw/fltkui.cc 2007-12-22 12:48:23.000000000 +0000 @@ -30,7 +30,7 @@ #include <fltk/Group.h> #include <fltk/Input.h> #include <fltk/SecretInput.h> -#include <fltk/MultiLineInput.h> +#include <fltk/TextEditor.h> #include <fltk/RadioButton.h> #include <fltk/CheckButton.h> #include <fltk/Choice.h> @@ -533,7 +533,7 @@ FltkMultiLineTextResource::FltkMultiLine FltkSpecificResource <dw::core::ui::MultiLineTextResource> (platform), numCols(cols), numRows(rows) { - initText = NULL; + buffer = new ::fltk::TextBuffer; editable = false; init (platform); @@ -541,27 +541,23 @@ FltkMultiLineTextResource::FltkMultiLine FltkMultiLineTextResource::~FltkMultiLineTextResource () { - if (initText) - delete initText; + for (Iterator <ViewAndWidget> it = viewsAndWidgets->iterator (); + it.hasNext(); ) { + ViewAndWidget *viewAndWidget = it.getNext (); + ((::fltk::TextEditor *) viewAndWidget->widget)->buffer (0); + } + delete buffer; } ::fltk::Widget *FltkMultiLineTextResource::createNewWidget (core::Allocation *allocation) { - ::fltk::MultiLineInput *input = - new ::fltk::MultiLineInput (allocation->x, allocation->y, - allocation->width, - allocation->ascent + allocation->descent); - - if (viewsAndWidgets->isEmpty ()) { - // First widget created, attach the set text. - if (initText) - input->value (initText); - } else - input->value - (((::fltk::MultiLineInput*)viewsAndWidgets->getFirst()->widget)->value ()); - - return input; + ::fltk::TextEditor *text = + new ::fltk::TextEditor (allocation->x, allocation->y, + allocation->width, + allocation->ascent + allocation->descent); + text->buffer (buffer); + return text; } void FltkMultiLineTextResource::sizeRequest (core::Requisition *requisition) @@ -586,23 +582,12 @@ void FltkMultiLineTextResource::sizeRequ const char *FltkMultiLineTextResource::getText () { - if (viewsAndWidgets->isEmpty ()) - return initText; - else - return ((::fltk::MultiLineInput*)viewsAndWidgets->getFirst()->widget)->value (); + return buffer->text (); } void FltkMultiLineTextResource::setText (const char *text) { - if (initText) - delete initText; - initText = strdup (text); - - for (Iterator <ViewAndWidget> it = viewsAndWidgets->iterator (); - it.hasNext(); ) { - ViewAndWidget *viewAndWidget = it.getNext (); - ((::fltk::MultiLineInput*)viewAndWidget->widget)->value (initText); - } + buffer->text (text); } bool FltkMultiLineTextResource::isEditable () diff -pru -- dw2-ref/dw/fltkui.hh dw2-cur/dw/fltkui.hh --- dw2-ref/dw/fltkui.hh 2007-12-19 12:26:59.000000000 +0000 +++ dw2-cur/dw/fltkui.hh 2007-12-22 12:48:23.000000000 +0000 @@ -7,6 +7,7 @@ #include <fltk/Button.h> #include <fltk/Menu.h> +#include <fltk/TextBuffer.h> namespace dw { namespace fltk { @@ -317,7 +318,7 @@ class FltkMultiLineTextResource: public FltkSpecificResource <dw::core::ui::MultiLineTextResource> { private: - const char *initText; + ::fltk::TextBuffer *buffer; bool editable; int numCols, numRows; diff -pru -- dw2-ref/dw/fltkviewbase.cc dw2-cur/dw/fltkviewbase.cc --- dw2-ref/dw/fltkviewbase.cc 2007-12-06 17:29:59.000000000 +0000 +++ dw2-cur/dw/fltkviewbase.cc 2007-12-22 12:48:23.000000000 +0000 @@ -53,9 +53,7 @@ void FltkViewBase::draw () { int d = damage(); - if (d == DAMAGE_CHILD) { - Group::draw (); - } else if (d == DAMAGE_VALUE) { + if (d == DAMAGE_VALUE) { container::typed::Iterator <core::Rectangle> it; ::fltk::Rectangle view (0, 0, w (), h ()); @@ -76,7 +74,16 @@ void FltkViewBase::draw () pop_clip (); } } - } else { + + d &= ~DAMAGE_VALUE; + } + + if (d & DAMAGE_CHILD) { + Group::draw (); + d &= ~DAMAGE_CHILD; + } + + if (d) { ::fltk::Rectangle rect (x(), y(), w(), h()); /* fltk-clipping does not use widget coordinates */ @@ -98,6 +105,7 @@ void FltkViewBase::draw () drawRegion.clear (); } + core::ButtonState getDwButtonState () { int s1 = event_state (); @@ -113,7 +121,6 @@ core::ButtonState getDwButtonState () return (core::ButtonState)s2; } - int FltkViewBase::handle (int event) { bool processed; @@ -349,6 +356,23 @@ FltkWidgetView::~FltkWidgetView () delete canvasWidgets; } +void FltkWidgetView::layout () { + /** + * pass layout to child widgets. This is needed for complex fltk + * widgets as TextEditor. + * We can't use Group::layout() as that would rearrange the widgets. + */ + for(Iterator <TypedPointer < ::fltk::Widget> > it + = canvasWidgets->iterator (); + it.hasNext (); ) { + ::fltk::Widget *widget = it.getNext()->getTypedValue (); + + if (widget->layout_damage ()) { + widget->layout (); + } + } +} + void FltkWidgetView::drawText (core::style::Font *font, core::style::Color *color, core::style::Color::Shading shading, diff -pru -- dw2-ref/dw/fltkviewbase.hh dw2-cur/dw/fltkviewbase.hh --- dw2-ref/dw/fltkviewbase.hh 2007-12-06 17:29:59.000000000 +0000 +++ dw2-cur/dw/fltkviewbase.hh 2007-12-22 12:48:23.000000000 +0000 @@ -74,6 +74,8 @@ public: FltkWidgetView (int x, int y, int w, int h, const char *label = 0); ~FltkWidgetView (); + void layout(); + void drawText (core::style::Font *font, core::style::Color *color, core::style::Color::Shading shading, diff -pru -- dw2-ref/dw/fltkviewport.cc dw2-cur/dw/fltkviewport.cc --- dw2-ref/dw/fltkviewport.cc 2007-11-18 07:36:53.000000000 +0000 +++ dw2-cur/dw/fltkviewport.cc 2007-12-22 12:48:23.000000000 +0000 @@ -46,7 +46,7 @@ FltkViewport::FltkViewport (int x, int y vscrollbar->set_vertical(); vscrollbar->callback (vscrollbarCallback, this); - scrollX = scrollY = 0; + scrollX = scrollY = scrollDX = scrollDY = 0; dragScrolling = 0; gadgetOrientation[0] = GADGET_HORIZONTAL; @@ -154,6 +154,8 @@ void FltkViewport::layout () { theLayout->viewportSizeChanged (this, w(), h()); adjustScrollbarsAndGadgetsAllocation (); + + FltkWidgetView::layout (); } void FltkViewport::draw_area (void *data, const Rectangle& cr )

Dec. 22, 2007

[PATCH] initialise FltkViewport::{scrollDX,scrollDY}

by onepoint＠starurchin.org

On Sat, Dec 22, 2007 at 09:48:30AM +0100, Johannes Hofmann wrote: > I also know now why I could no longer reproduce the problem: To > debug the problem I had used some MALLOC_OPTIONS that cause malloced > data to be initialized with some weird pattern. With this option I > could reproduce the failure. Later I forgot to set the option and > the problem seemed to be gone. Good, that confirms we know the real cause of the problem. > I would still suggest to use my latest patch that calls layout() of > child widgets from FltkWidgetView. > > Can you make a combined patch for Jorge? Yes, I will. Jeremy Henty

Dec. 22, 2007

[PATCH] initialise FltkViewport::{scrollDX,scrollDY}

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Sat, Dec 22, 2007 at 02:10:32AM +0000, Jeremy Henty wrote: > > This patch initialises FltkViewport::{scrollDX,scrollDY}. This > removes a valgrind warning about a conditional jump depending on > uninitialised data. It also fixes the mysterious sporadic > disappearing page bug that was afflicting the development of the > TextEditor patch. This makes me very happy, and confirms yet again > that valgrind is awesome! Excellent! scrollDX, scrollDY were introduced by one of my scrolling patches btw.... I also know now why I could no longer reproduce the problem: To debug the problem I had used some MALLOC_OPTIONS that cause malloced data to be initialized with some weird pattern. With this option I could reproduce the failure. Later I forgot to set the option and the problem seemed to be gone. And I can only agree that valgrind is a awesome tool. It helped a lot with the style reference bug too. I would still suggest to use my latest patch that calls layout() of child widgets from FltkWidgetView. Can you make a combined patch for Jorge? Regards, Johannes > > Regards, > > Jeremy Henty > > > diff -pru -- dw2-ref/dw/fltkviewport.cc dw2-cur/dw/fltkviewport.cc > --- dw2-ref/dw/fltkviewport.cc 2007-12-22 01:23:39.000000000 +0000 > +++ dw2-cur/dw/fltkviewport.cc 2007-12-22 01:46:11.000000000 +0000 > @@ -46,7 +46,7 @@ FltkViewport::FltkViewport (int x, int y > vscrollbar->set_vertical(); > vscrollbar->callback (vscrollbarCallback, this); > > - scrollX = scrollY = 0; > + scrollX = scrollY = scrollDX = scrollDY = 0; > dragScrolling = 0; > > gadgetOrientation[0] = GADGET_HORIZONTAL; > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Dec. 22, 2007

[PATCH] initialise FltkViewport::{scrollDX,scrollDY}

by onepoint＠starurchin.org

This patch initialises FltkViewport::{scrollDX,scrollDY}. This removes a valgrind warning about a conditional jump depending on uninitialised data. It also fixes the mysterious sporadic disappearing page bug that was afflicting the development of the TextEditor patch. This makes me very happy, and confirms yet again that valgrind is awesome! Regards, Jeremy Henty diff -pru -- dw2-ref/dw/fltkviewport.cc dw2-cur/dw/fltkviewport.cc --- dw2-ref/dw/fltkviewport.cc 2007-12-22 01:23:39.000000000 +0000 +++ dw2-cur/dw/fltkviewport.cc 2007-12-22 01:46:11.000000000 +0000 @@ -46,7 +46,7 @@ FltkViewport::FltkViewport (int x, int y vscrollbar->set_vertical(); vscrollbar->callback (vscrollbarCallback, this); - scrollX = scrollY = 0; + scrollX = scrollY = scrollDX = scrollDY = 0; dragScrolling = 0; gadgetOrientation[0] = GADGET_HORIZONTAL;

Dec. 22, 2007

[PATCH] TEXTAREA controls submit their contents

by onepoint＠starurchin.org

On Thu, Dec 20, 2007 at 07:12:56PM +0100, Johannes Hofmann wrote: > On Wed, Dec 19, 2007 at 09:41:20PM +0000, Jeremy Henty wrote: > > > > Not fixed yet. :-( The bug appears to be sporadic now: sometimes > > a middle-click brings up a blank page, sometimes not. I *think* > > that a left-click still always works. NB: the test page includes > > an input widget and it is affected too, so this is not AFAICT > > specific to the FLTK TextEditor. > > > > Can you reproduce this at all? Maybe it's affected by the window > > manager? I'm running Linux 2.6.23 + X windows 7.1 + icewm. > > Yes, I could reproduce it - sporadically. But I no longer can with > my change... I will keep on trying. I believe I have fixed it. FltkViewport::{scrollDX,scrollDY} were not being initialised. This explains why sometimes the form rendered but displaced vertically (which I forgot to mention). I imagine the blank pages were due to the same bug scrolling the form right off the page. I'll post the fix and the complete textarea patch to new threads: this is getting confusing! Johannes, you'll need to tell me which of your viewport patches I should use; it's possible that once this scrolling fix is committed some of your earlier efforts may turn out to be sufficient. Regards, Jeremy Henty

Dec. 22, 2007