- Dillo-dev - lists.mailman3.com

[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

[patch]: fix the download GUI resize bug

by jcid＠dillo.org

On Wed, Oct 29, 2008 at 09:16:07PM +0000, Jeremy Henty wrote: > On Wed, Oct 29, 2008 at 01:38:14PM -0300, Jorge Arellano Cid wrote: > > On Wed, Oct 29, 2008 at 02:28:48PM +0000, Jeremy Henty wrote: > > > > > > There's a bug in the downloads GUI that stops the download items > > > resizing when the window does. The resizable of the window should > > > be the scrollgroup, not the packedgroup. Fixing this means we > > > don't need to explicitly resize the scrollgroup after removing an > > > item (because the window has already resized it) so I took that > > > out. Patch attached. > > > > Oh, please excuse me not understanding what the bug is and how to > > reproduce it. Please explain with apples and pears! :-) > > OK, fruit 'n' veg coming up! :-) > > Symptom: > > If you change the width of the download GUI window its contents do not > respond. This is annoying because (a) if you narrow the window to > save space then it truncates its contents at the right-hand side > rather than gracefully resizing them, and (b) if you widen the window > hoping that it will make the display more legible by widening the text > labels etc. then nothing happens. It's an easy bug to miss because > the result is not obviously wrong, just poor and inconvenient. Once > you've seen the correct behaviour the improvement is obvious. I still don't get it... Here, with the unpatched code, the download dpi resizes without problems when narrowing the window (fltk-r6403), and labels are widened too. 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). I'm baffled. > Cause: > > FLTK's resize mechanism is controlled by the resizable members of the > Group widgets. This is a pointer to the child of the group widget > which the group should resize when its own size changes. The > downloads GUI is buggy because it sets the resizable widget of the > Window to be the PackedGroup that contains the download items, which > is wrong because the PackedGroup is *not* a child of the Window, it's > a child of the the ScrollGroup (which is in turn a child of the > Window). The result is that the contents of the Window don't resize > at all, except when the code tries to work around the bug by > explicitly calling resize(). > > > Fix: > > The code should make the ScrollGroup the resizable widget of the > Window. (The ScrollGroup then properly resizes the PackedGroup > without any further changes. I think this is because its type is set > to VERTICAL.) This makes the width of the ScrollGroup (and hence the > PackedGroup too) follow the width of the Window in a way that is > beautiful to behold. :-) Now we don't need to explicitly resize the > any of the widgets because FLTK does it all automatically whenever the > width of the Window changes, so the call to resize() should be > deleted. -- Cheers Jorge.-

Oct. 30, 2008