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

[patch]: fix the download GUI resize bug

by onepoint＠starurchin.org

On Thu, Oct 30, 2008 at 05:32:58PM -0300, Jorge Arellano Cid wrote: > On Thu, Oct 30, 2008 at 07:17:27PM +0000, Jeremy Henty wrote: > > ... if I write a FLTK2 app with a scrolled list of buttons that > > delete themselves when pressed then I *do* get redisplay problems: > > the deleted buttons don't disappear. And the fix is to tell the > > scroll to redraw itself. > > Committed. Good! I'm glad something useful came out of this. > Yes, the example program showed exactly what I was getting here. > This looks like a bug in FLTK2 (AFAIU, the scroll group should take > care of its background when an item is removed). IIRC I've sometimes had to manually tell a widget to update/redraw itself and I thought this was a deliberate policy from the FLTK devs. I'll send them my example and ask. Regards, Jeremy Henty

Oct. 30, 2008

[patch]: fix the download GUI resize bug

by jcid＠dillo.org

On Thu, Oct 30, 2008 at 07:17:27PM +0000, Jeremy Henty wrote: > On Thu, Oct 30, 2008 at 02:54:57PM -0300, Jorge Arellano Cid wrote: > > > The test that fails here is: > > > > - load the dillo downloads page > > - download a tarball > > - download another > > - resize the window to 1.25 the height of both download panels > > - Once both are done, press done in the lower panel > > > > then I get the panel drawn over the old one (like a shadow). > > I cannot reproduce this at all!!! But if I write a FLTK2 app with a > scrolled list of buttons that delete themselves when pressed then I > *do* get redisplay problems: the deleted buttons don't disappear. And > the fix is to tell the scroll to redraw itself. I guess that's > because the scroll is responsible for the blank space left behind when > the button disappears. It would be interesting to know if this patch > fails the test. (I've also attached the FLTK2 app. If you comment > out the redraw() call in the callback you'll see that the bottom > button does not disappear after clicking any button, even though the > list has actually shrunk.) Committed. Yes, the example program showed exactly what I was getting here. This looks like a bug in FLTK2 (AFAIU, the scroll group should take care of its background when an item is removed). -- Cheers Jorge.-

Oct. 30, 2008

reduce warnings with gcc-4.3 [PATCH]

by jcid＠dillo.org

On Thu, Oct 30, 2008 at 07:10:34PM +0100, Thomas Orgis wrote: > Am Thu, 30 Oct 2008 14:37:37 -0300 > schrieb Jorge Arellano Cid <jcid(a)dillo.org>: > > > Does this produce the same warning? > > > > assert (i >= 0 && this->num - i > 0); > > That seems to be silent with gcc-4.3.1 ... I won't guarantee anything for gcc-4.3.2, though. > But I'll upgrade to that one in the next weeks for sure and will let you know. > For now this looks like a fine fix to make dillo2 compiler warning free! Committed. -- Cheers Jorge.-

Oct. 30, 2008

[patch]: fix the download GUI resize bug

by onepoint＠starurchin.org

On Thu, Oct 30, 2008 at 02:54:57PM -0300, Jorge Arellano Cid wrote: > The test that fails here is: > > - load the dillo downloads page > - download a tarball > - download another > - resize the window to 1.25 the height of both download panels > - Once both are done, press done in the lower panel > > then I get the panel drawn over the old one (like a shadow). I cannot reproduce this at all!!! But if I write a FLTK2 app with a scrolled list of buttons that delete themselves when pressed then I *do* get redisplay problems: the deleted buttons don't disappear. And the fix is to tell the scroll to redraw itself. I guess that's because the scroll is responsible for the blank space left behind when the button disappears. It would be interesting to know if this patch fails the test. (I've also attached the FLTK2 app. If you comment out the redraw() call in the callback you'll see that the bottom button does not disappear after clicking any button, even though the list has actually shrunk.) Regards, Jeremy Henty

Oct. 30, 2008

css

by Johannes.Hofmann＠gmx.de

Hi, On Fri, Oct 24, 2008 at 03:09:53PM -0300, Jorge Arellano Cid wrote: ** snip ** > > I currently think about a class that looks more or less like StyleAttrs > > together with a map indicating which of it's values are actually set. > > One can then start with a basic style and apply any number of > > objects of this new class according to the order of precedence. > > Applying here means overriding those values that are set according > > to the map. > > Where/how would attribute values be stored? We will probabely need a new class that holds the attributes, but after looking at the dillo-0.8.0-css3 code I decided to go with just the "style", "id", and "class" attributes for now. Attached patch implements something between step 2 and 3 of my css proposal. There are a lot of loose ends (e.g. memory management) but it's a start. Check the end of css.cc. Here the user-agent style is filled. In html.cc Html_tag_open_a() shows how StyleEngine is intended to be used. Note that StyleEngine::apply() currently only supports a limited number of attributes. I think html.cc will become a lot simpler. Cheers, Johannes PS: I had attached the patch, but that was blocked by the list. So here is a link instead: http://www.ecademix.com/JohannesHofmann/tmp/css_prototype.dillo2

Oct. 30, 2008

reduce warnings with gcc-4.3 [PATCH]

by thomas-forum＠orgis.org

Am Thu, 30 Oct 2008 14:37:37 -0300 schrieb Jorge Arellano Cid <jcid(a)dillo.org>: > Does this produce the same warning? > > assert (i >= 0 && this->num - i > 0); That seems to be silent with gcc-4.3.1 ... I won't guarantee anything for gcc-4.3.2, though. But I'll upgrade to that one in the next weeks for sure and will let you know. For now this looks like a fine fix to make dillo2 compiler warning free! Alrighty then, Thomas.

Oct. 30, 2008

[patch]: fix the download GUI resize bug

by jcid＠dillo.org

On Thu, Oct 30, 2008 at 05:36:42PM +0000, Jeremy Henty wrote: > On Thu, Oct 30, 2008 at 09:49:23AM -0300, Jorge Arellano Cid wrote: > > > Here, with the unpatched code, the download dpi resizes without > > problems when narrowing the window (fltk-r6403), and labels are > > widened too. > > OK, I am embarrassed. There certainly *used* to be the problem I > described but it has gone. I thought I had checked that but I > obviously didn't. Apologies. We, human beans, make mistakes by definition! :-) > However, it is definitely weird to set the window's resizable to > something that is not a child of the window. Also, to my eye the > resizing seems smoother when the resizable is the scrollgroup. > Without the patch the contents seem to jiggle sideways more as the > width changes. > > > And more, the unpatched code responds to clicking "done" by > > removing the corresponding item (when alone and when in a list). > > The patched code, here, sometimes doesn't remove the widget when > > clicking "done", and others leaves a background with the > > to-be-removed item as a window shadow (partial remove). > > Strange, I deliberately tested clicking "done" (both with one download > and several downloads) before submitting and I saw no problems. What > happens if you call relayout() on the widget instead of resize()? > (patch attached) Same problem... :( The test that fails here is: - load the dillo downloads page - download a tarball - download another - resize the window to 1.25 the height of both download panels - Once both are done, press done in the lower panel then I get the panel drawn over the old one (like a shadow). -- Cheers Jorge.-

Oct. 30, 2008

reduce warnings with gcc-4.3 [PATCH]

by jcid＠dillo.org

On Fri, Oct 24, 2008 at 08:44:14PM +0200, Thomas Orgis wrote: > The build of dillo with gcc-4.3 spills out quite some warning messages. > > I propose attached patch to fix these. Most are about all these loops > without body: gcc suggested to change > > for(i=0; i<42; ++i); > > to > > for(i=0; i<42; ++i) ; > > ...or append "{}", alternatively. > I decided for the subtle space insertion... not sure if I particulary > like it, but it makes the compile more silent. > > Other warnings are about logical and arithmetical expressions with fewer > than recommened parentheses. > I suggest people having a close look at these changes... > I _think_ I got it right;-) > Committed! > Then at last, there's an unresolved warning: > > dillo2-cvs/dw$ LANG=C make textblock.o > g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -march=pentium-m -O3 -Wall -W -Wno-unused-parameter -MT textblock.o -MD -MP -MF .deps/textblock.Tpo -c -o textblock.o textblock.cc > ../lout/misc.hh: In member function 'void dw::Textblock::addLine(int, bool)': > ../lout/misc.hh:161: warning: assuming signed overflow does not occur when assuming that (X - c) > X is always false > mv -f .deps/textblock.Tpo .deps/textblock.Po > > It's about this assert: > > inline T* getRef (int i) { > if (BOUND_CHECKING) > assert (i >= 0 && i < this->num); > return array + i; > } > > Ideas to please gcc with this assert? I am not sure what to think of this. I have gcc-4.2.4 here. Does this produce the same warning? assert (i >= 0 && this->num - i > 0); -- Cheers Jorge.-

Oct. 30, 2008

[patch]: fix the download GUI resize bug

by onepoint＠starurchin.org

On Thu, Oct 30, 2008 at 09:49:23AM -0300, Jorge Arellano Cid wrote: > Here, with the unpatched code, the download dpi resizes without > problems when narrowing the window (fltk-r6403), and labels are > widened too. OK, I am embarrassed. There certainly *used* to be the problem I described but it has gone. I thought I had checked that but I obviously didn't. Apologies. However, it is definitely weird to set the window's resizable to something that is not a child of the window. Also, to my eye the resizing seems smoother when the resizable is the scrollgroup. Without the patch the contents seem to jiggle sideways more as the width changes. > And more, the unpatched code responds to clicking "done" by > removing the corresponding item (when alone and when in a list). > The patched code, here, sometimes doesn't remove the widget when > clicking "done", and others leaves a background with the > to-be-removed item as a window shadow (partial remove). Strange, I deliberately tested clicking "done" (both with one download and several downloads) before submitting and I saw no problems. What happens if you call relayout() on the widget instead of resize()? (patch attached) I'm using fltk2-r6403, gcc-4.1.2 and running on Linux. Regards, Jeremy Henty

Oct. 30, 2008

Q: D_SUN_LEN , dpi programs and socket programming

by onepoint＠starurchin.org

On Thu, Oct 30, 2008 at 09:29:55AM -0300, Jorge Arellano Cid wrote: > On Wed, Oct 29, 2008 at 08:46:28PM +0000, Jeremy Henty wrote: > > On Wed, Oct 29, 2008 at 01:28:20PM -0300, Jorge Arellano Cid wrote: > > > > > > Given that IO/dpi.c uses both without (reported) problems, > > > it'd be good to have everyone use D_SUN_LEN. > > > > So I think the code is correct and we should just remove the > > unused D_SUN_LEN definitions. Patch attached. > > OK, but I was talking about connect(). Patch attached. Also, all uses of bind() already use D_SUN_LEN. Incidentally, does anyone know why there is no analog of D_SUN_LEN for connect()-ing to a struct sockaddr_in? The struct has a sin_path member just as struct sockaddr_un has a sun_path , so what is the difference? (I'm new to the C socket API.) Regards, Jeremy Henty

Oct. 30, 2008