- Dillo-dev - lists.mailman3.com

fltk1.3 port

by rogerx.oss＠gmail.com

>> > >> Just finally got around to creating a fltk-1.3-r9999.ebuild (SVN version) for >> > >> Gentoo and, pulled/built dillo_fltk-1.3_port. >> > >> >> > >> Tabs look way much nicer now. However, if the bookmarks (dpi:/bm/) rolls-off the >> > >> screen because the user has a long list of bookmarks, scrolling to the next >> > >> page does not work using the scrollbar. >> > >> >> > >> As such, I need to manually resize the window larger then my screen to see & use the >> > >> bookmarks listed off-screen. >> > > >> > > It works perfectly here... >> > >> > Are you using a recently pulled fltk-1.3 svn? >> >> r8514 >> >> but it has worked well since much before r8411 (for months) >> >> > ... I'm betting, this is likely a fltk bug. >> > >> > I should also mention I'm using DWM. :-/ >> >> AFAIR, Johannes uses DWM... > >Right, but it works fine for me. >Roger, do you try to scroll by clicking and dragging the scrollbar >with the mouse or do you use PageDown or Space keys? >For the latter to work I also need to first click the main area to >get focus. Yes, just tried using pgdown/pgup as well as cursor keys and Dillo FLTK-1.3 SVN only scrolls so far to the bottom of the list, while not showing my last bookmark in the list. This looks like a SVN bug to me as this is the first I've seen this too. Also, tabs are not opening in the background as I previously configured. (SVN bug here or current dillo_port-1.3 bug?)... and Dillo > File > Exit displays the "Close all tabs too?" question dialog behind the browser. This later issue sounds more like fltk-1.3 svn. (I just hope the fltk team starts pushing for releases sometime soon vs. never like 2.0!)

March 18, 2011

Test case for a possible fltk1.3 bug

by Johannes.Hofmann＠gmx.de

Hi Jorge, I didn't really dive into this, but the following discussion seems to be related: http://www.mail-archive.com/fltk@easysw.com/msg02113.html Cheers, Johannes On Wed, Mar 16, 2011 at 09:44:00PM -0300, Jorge Arellano Cid wrote: > Hi there, > > Please help me with this one. > > Attached goes a small program that shows what may be a bug in > fltk-1.3: > > * resize the window back and forth and both "Group 1" and > "Group 2" keep their heights. OK here. > * With a small window, hide "Group 2" and resize to a big > window, then show "Group 2". It grew while hidden!? > > > My doubts are: > > Is this intended or a bug? > If not a bug, how is the desired behaviour suppossed to be > implemented? > > > I know an ugly way to workaround it (used with the findbar), > but, if it's a bug, I'd prefer to have it fixed, and to keep > the code clean. > > What do you think? > > > PS: compile with: fltk-config --compile rsz.cc > > -- > Cheers > Jorge.- > #include <stdio.h> > #include <stdlib.h> > > #include <FL/Fl.H> > #include <FL/Fl_Window.H> > #include <FL/Fl_Widget.H> > #include <FL/Fl_Group.H> > #include <FL/Fl_Button.H> > #include <FL/Fl_Pack.H> > > Fl_Pack *p1; > Fl_Group *g1, *g2, *g3; > > //////////////////////////////////////////////////////////////// > > static void b1_cb(Fl_Widget *w, void *data) { > Fl_Group *g2 = (Fl_Group *)data; > > if (g2->visible()) { > g2->hide(); > g3->size(g3->w(),g3->h()+g2->h()); > g2->window()->redraw(); > } > } > > static void b2_cb(Fl_Widget *w, void *data) { > Fl_Group *g2 = (Fl_Group *)data; > > if (!g2->visible()) { > g3->size(g3->w(),g3->h()-g2->h()); > g2->show(); > g2->window()->redraw(); > } > } > > > > int main(int argc, char **argv) { > Fl_Button *b1, *b2, *b3; > > Fl_Window *window = new Fl_Window(400, 400, "Fl_Pack test"); > window->begin(); > p1 = new Fl_Pack(0,0,400,400); > p1->type(Fl_Pack::VERTICAL); > p1->begin(); > // a Pack with a resizable widget inside > g1 = new Fl_Group(0,0,0,30, "Group 1"); > g1->align(FL_ALIGN_CENTER|FL_ALIGN_INSIDE); > g1->box(FL_UP_BOX); > g1->color(FL_CYAN); > g1->end(); > > g2 = new Fl_Group(0,0,0,30, "Group 2"); > g2->align(FL_ALIGN_CENTER|FL_ALIGN_INSIDE); > g2->box(FL_UP_BOX); > g2->color(FL_RED); > g2->end(); > > g3 = new Fl_Group(0,0,0,280, "Group 3 R e s i z a b l e"); > g3->align(FL_ALIGN_CENTER|FL_ALIGN_INSIDE); > g3->box(FL_UP_BOX); > g3->color(FL_GREEN); > g3->end(); > b1 = new Fl_Button(0,340,50,30); > b1->label("Hide G2"); > b1->callback(b1_cb, g2); > b2 = new Fl_Button(0,370,50,30); > b2->label("Show G2"); > b2->callback(b2_cb, g2); > p1->end(); > p1->resizable(g3); > window->end(); > > window->resizable(window); > window->show(); > return Fl::run(); > > return 0; > } > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

March 17, 2011

fltk1.3 port

by Johannes.Hofmann＠gmx.de

On Thu, Mar 17, 2011 at 01:17:31PM -0300, Jorge Arellano Cid wrote: > On Thu, Mar 17, 2011 at 06:27:15AM -0800, Roger wrote: > > > On Thu, Mar 17, 2011 at 10:42:33AM -0300, Jorge Arellano Cid wrote: > > >On Thu, Mar 17, 2011 at 03:41:18AM -0800, Roger wrote: > > >> > On Tue, Mar 15, 2011 at 09:38:03AM -0300, Jorge Arellano Cid wrote: > > >> >Hi, > > >> > > > >> > Just committed some keybindings and operative findbar patches. > > >> >It feels quite operative now. Minor things remain. > > >> > > > >> > BTW, there's a pending bug report to FLTK (see comments in code). > > >> > > > >> > > >> Just finally got around to creating a fltk-1.3-r9999.ebuild (SVN version) for > > >> Gentoo and, pulled/built dillo_fltk-1.3_port. > > >> > > >> Tabs look way much nicer now. However, if the bookmarks (dpi:/bm/) rolls-off the > > >> screen because the user has a long list of bookmarks, scrolling to the next > > >> page does not work using the scrollbar. > > >> > > >> As such, I need to manually resize the window larger then my screen to see & use the > > >> bookmarks listed off-screen. > > > > > > It works perfectly here... > > > > Are you using a recently pulled fltk-1.3 svn? > > r8514 > > but it has worked well since much before r8411 (for months) > > > ... I'm betting, this is likely a fltk bug. > > > > I should also mention I'm using DWM. :-/ > > AFAIR, Johannes uses DWM... Right, but it works fine for me. Roger, do you try to scroll by clicking and dragging the scrollbar with the mouse or do you use PageDown or Space keys? For the latter to work I also need to first click the main area to get focus. Cheers, Johannes

March 17, 2011

fltk1.3 port

by jcid＠dillo.org

On Thu, Mar 17, 2011 at 06:27:15AM -0800, Roger wrote: > > On Thu, Mar 17, 2011 at 10:42:33AM -0300, Jorge Arellano Cid wrote: > >On Thu, Mar 17, 2011 at 03:41:18AM -0800, Roger wrote: > >> > On Tue, Mar 15, 2011 at 09:38:03AM -0300, Jorge Arellano Cid wrote: > >> >Hi, > >> > > >> > Just committed some keybindings and operative findbar patches. > >> >It feels quite operative now. Minor things remain. > >> > > >> > BTW, there's a pending bug report to FLTK (see comments in code). > >> > > >> > >> Just finally got around to creating a fltk-1.3-r9999.ebuild (SVN version) for > >> Gentoo and, pulled/built dillo_fltk-1.3_port. > >> > >> Tabs look way much nicer now. However, if the bookmarks (dpi:/bm/) rolls-off the > >> screen because the user has a long list of bookmarks, scrolling to the next > >> page does not work using the scrollbar. > >> > >> As such, I need to manually resize the window larger then my screen to see & use the > >> bookmarks listed off-screen. > > > > It works perfectly here... > > Are you using a recently pulled fltk-1.3 svn? r8514 but it has worked well since much before r8411 (for months) > ... I'm betting, this is likely a fltk bug. > > I should also mention I'm using DWM. :-/ AFAIR, Johannes uses DWM... -- Cheers Jorge.-

March 17, 2011

fltk1.3 port

by rogerx.oss＠gmail.com

> On Thu, Mar 17, 2011 at 10:42:33AM -0300, Jorge Arellano Cid wrote: >On Thu, Mar 17, 2011 at 03:41:18AM -0800, Roger wrote: >> > On Tue, Mar 15, 2011 at 09:38:03AM -0300, Jorge Arellano Cid wrote: >> >Hi, >> > >> > Just committed some keybindings and operative findbar patches. >> >It feels quite operative now. Minor things remain. >> > >> > BTW, there's a pending bug report to FLTK (see comments in code). >> > >> >> Just finally got around to creating a fltk-1.3-r9999.ebuild (SVN version) for >> Gentoo and, pulled/built dillo_fltk-1.3_port. >> >> Tabs look way much nicer now. However, if the bookmarks (dpi:/bm/) rolls-off the >> screen because the user has a long list of bookmarks, scrolling to the next >> page does not work using the scrollbar. >> >> As such, I need to manually resize the window larger then my screen to see & use the >> bookmarks listed off-screen. > > It works perfectly here... Are you using a recently pulled fltk-1.3 svn? ... I'm betting, this is likely a fltk bug. I should also mention I'm using DWM. :-/ -- Roger http://rogerx.freeshell.org/

March 17, 2011

fltk1.3 port

by jcid＠dillo.org

On Thu, Mar 17, 2011 at 03:41:18AM -0800, Roger wrote: > > On Tue, Mar 15, 2011 at 09:38:03AM -0300, Jorge Arellano Cid wrote: > >Hi, > > > > Just committed some keybindings and operative findbar patches. > >It feels quite operative now. Minor things remain. > > > > BTW, there's a pending bug report to FLTK (see comments in code). > > > > Just finally got around to creating a fltk-1.3-r9999.ebuild (SVN version) for > Gentoo and, pulled/built dillo_fltk-1.3_port. > > Tabs look way much nicer now. However, if the bookmarks (dpi:/bm/) rolls-off the > screen because the user has a long list of bookmarks, scrolling to the next > page does not work using the scrollbar. > > As such, I need to manually resize the window larger then my screen to see & use the > bookmarks listed off-screen. It works perfectly here... -- Cheers Jorge.-

March 17, 2011

fltk1.3 port

by rogerx.oss＠gmail.com

> On Thu, Mar 17, 2011 at 03:41:18AM -0800, Roger wrote: >> On Tue, Mar 15, 2011 at 09:38:03AM -0300, Jorge Arellano Cid wrote: >>Hi, >> >> Just committed some keybindings and operative findbar patches. >>It feels quite operative now. Minor things remain. >> >> BTW, there's a pending bug report to FLTK (see comments in code). >> > >Just finally got around to creating a fltk-1.3-r9999.ebuild (SVN version) for >Gentoo and, pulled/built dillo_fltk-1.3_port. > >Tabs look way much nicer now. However, if the bookmarks (dpi:/bm/) rolls-off the >screen because the user has a long list of bookmarks, scrolling to the next >page does not work using the scrollbar. > >As such, I need to manually resize the window larger then my screen to see & use the >bookmarks listed off-screen. Another temporary method of getting around this, if the user has their bookmarks listed within sub-folders listed at the left of the page, use "left-click, open in new tab" for the sub-folder of bookmarks. -- Roger http://rogerx.freeshell.org/

March 17, 2011

fltk1.3 port

by rogerx.oss＠gmail.com

> On Tue, Mar 15, 2011 at 09:38:03AM -0300, Jorge Arellano Cid wrote: >Hi, > > Just committed some keybindings and operative findbar patches. >It feels quite operative now. Minor things remain. > > BTW, there's a pending bug report to FLTK (see comments in code). > Just finally got around to creating a fltk-1.3-r9999.ebuild (SVN version) for Gentoo and, pulled/built dillo_fltk-1.3_port. Tabs look way much nicer now. However, if the bookmarks (dpi:/bm/) rolls-off the screen because the user has a long list of bookmarks, scrolling to the next page does not work using the scrollbar. As such, I need to manually resize the window larger then my screen to see & use the bookmarks listed off-screen. -- Roger http://rogerx.freeshell.org/

March 17, 2011

dillo_port1.3: error: ‘class Fl_Tree’ has no member named ‘item_labelfont’

by rogerx.oss＠gmail.com

> On Sat, Mar 12, 2011 at 07:04:48PM +0100, Johannes Hofmann wrote: >yOn Fri, Mar 11, 2011 at 01:45:14AM -0900, Roger wrote: >> ++ -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/local/include -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT libDw_fltk_a-fltkpreview.o -MD -MP -MF .deps/libDw_fltk_a-fltkpreview.Tpo -c -o libDw_fltk_a-fltkpreview.o `test -f 'fltkpreview.cc' || echo './'`fltkpreview.cc >> mv -f .deps/libDw_fltk_a-fltkpreview.Tpo .deps/libDw_fltk_a-fltkpreview.Po >> g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/local/include -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT libDw_fltk_a-fltkui.o -MD -MP -MF .deps/libDw_fltk_a-fltkui.Tpo -c -o libDw_fltk_a-fltkui.o `test -f 'fltkui.cc' || echo './'`fltkui.cc >> fltkui.cc: In member function ?virtual void dw::fltk::ui::FltkListResource::setWidgetStyle(Fl_Widget*, dw::core::style::Style*)?: >> fltkui.cc:1075: error: ?class Fl_Tree? has no member named ?item_labelfont? >> fltkui.cc:1076: error: ?class Fl_Tree? has no member named ?item_labelsize? >> fltkui.cc:1077: error: ?class Fl_Tree? has no member named ?item_labelfgcolor? >> fltkui.cc:1078: error: ?class Fl_Tree? has no member named ?item_labelbgcolor? >> make[2]: *** [libDw_fltk_a-fltkui.o] Error 1 >> make[2]: Leaving directory `/home/roger/src/dillo/dillo_port1.3/dw' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/home/roger/src/dillo/dillo_port1.3' >> make: *** [all] Error 2 > >Looks like the same problem you already reported here: >http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-February/008064.html Yup. You are correct. I've just pulled & compiled against fltk-1.3 SVN. -- Roger http://rogerx.freeshell.org/

March 17, 2011

Test case for a possible fltk1.3 bug

by jcid＠dillo.org

Hi there, Please help me with this one. Attached goes a small program that shows what may be a bug in fltk-1.3: * resize the window back and forth and both "Group 1" and "Group 2" keep their heights. OK here. * With a small window, hide "Group 2" and resize to a big window, then show "Group 2". It grew while hidden!? My doubts are: Is this intended or a bug? If not a bug, how is the desired behaviour suppossed to be implemented? I know an ugly way to workaround it (used with the findbar), but, if it's a bug, I'd prefer to have it fixed, and to keep the code clean. What do you think? PS: compile with: fltk-config --compile rsz.cc -- Cheers Jorge.-

March 17, 2011

fltk1.3 port

by jcid＠dillo.org

Hi, Just committed some keybindings and operative findbar patches. It feels quite operative now. Minor things remain. BTW, there's a pending bug report to FLTK (see comments in code). -- Cheers Jorge.-

March 15, 2011

dillo_port1.3 tabs

by corvid＠lavabit.com

Jorge wrote: > On Sun, Mar 13, 2011 at 03:59:19PM +0000, corvid wrote: > > Jorge wrote: > > > Just committed a working status bar... > > > > I don't see it on hg.dillo.org. > > Can you see it now? yes

March 13, 2011

dillo_port1.3 tabs

by jcid＠dillo.org

On Sun, Mar 13, 2011 at 03:59:19PM +0000, corvid wrote: > Jorge wrote: > > Just committed a working status bar... > > I don't see it on hg.dillo.org. Can you see it now? TIA -- Cheers Jorge.-

March 13, 2011

dillo_port1.3 tabs

by jcid＠dillo.org

On Sun, Mar 13, 2011 at 03:59:19PM +0000, corvid wrote: > Jorge wrote: > > Just committed a working status bar... > > I don't see it on hg.dillo.org. Oh, I forgot to update before the commit, and made the same mistake of pushing to dillo and not dillo_port1.3. My problem was making "sure" which repo with "hg in", but the default push location being the fltk2 repo. Andreas: would you mind fixing my mistake again? I'll trying to clear the mess now... -- Cheers Jorge.-

March 13, 2011

dillo_port1.3 tabs

by corvid＠lavabit.com

Jorge wrote: > Just committed a working status bar... I don't see it on hg.dillo.org.

March 13, 2011

dillo_port1.3 tabs

by jcid＠dillo.org

On Fri, Mar 04, 2011 at 09:13:06AM -0300, Jorge Arellano Cid wrote: > [...] > I'm working on the UI, and decided to implement a new, custom > tab mechanism for 1.3 (it is in my HD now). After all the old one > had some problems we couldn't fix. Just committed a working status bar... -- Cheers Jorge.-

March 13, 2011

dillo_port1.3: error: ‘class Fl_Tree’ has no member named ‘item_labelfont’

by Johannes.Hofmann＠gmx.de

yOn Fri, Mar 11, 2011 at 01:45:14AM -0900, Roger wrote: > ++ -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/local/include -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT libDw_fltk_a-fltkpreview.o -MD -MP -MF .deps/libDw_fltk_a-fltkpreview.Tpo -c -o libDw_fltk_a-fltkpreview.o `test -f 'fltkpreview.cc' || echo './'`fltkpreview.cc > mv -f .deps/libDw_fltk_a-fltkpreview.Tpo .deps/libDw_fltk_a-fltkpreview.Po > g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/local/include -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT libDw_fltk_a-fltkui.o -MD -MP -MF .deps/libDw_fltk_a-fltkui.Tpo -c -o libDw_fltk_a-fltkui.o `test -f 'fltkui.cc' || echo './'`fltkui.cc > fltkui.cc: In member function ?virtual void dw::fltk::ui::FltkListResource::setWidgetStyle(Fl_Widget*, dw::core::style::Style*)?: > fltkui.cc:1075: error: ?class Fl_Tree? has no member named ?item_labelfont? > fltkui.cc:1076: error: ?class Fl_Tree? has no member named ?item_labelsize? > fltkui.cc:1077: error: ?class Fl_Tree? has no member named ?item_labelfgcolor? > fltkui.cc:1078: error: ?class Fl_Tree? has no member named ?item_labelbgcolor? > make[2]: *** [libDw_fltk_a-fltkui.o] Error 1 > make[2]: Leaving directory `/home/roger/src/dillo/dillo_port1.3/dw' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/roger/src/dillo/dillo_port1.3' > make: *** [all] Error 2 Looks like the same problem you already reported here: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-February/008064.html Cheers, Johannes

March 12, 2011

big mistake with hg

by jcid＠dillo.org

On Thu, Mar 10, 2011 at 06:46:54PM +0100, Johannes Hofmann wrote: > On Thu, Mar 10, 2011 at 12:18:38PM -0500, Benjamin Johnson wrote: > > Try 'hg strip': http://mercurial.selenic.com/wiki/Strip > > That would also work, but in all cases you need access to the master > repo on hg.dillo.org. Can you log in there? Nope. > Otherwise Andreas would have to help. Please contact him, and please also fix the repo. I don't have the newest tip just in case things go wrong again. -- Cheers Jorge.-

March 11, 2011

dillo_port1.3: error: ‘class Fl_Tree’ has no member named ‘item_labelfont’

by rogerx.oss＠gmail.com

++ -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/local/include -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT libDw_fltk_a-fltkpreview.o -MD -MP -MF .deps/libDw_fltk_a-fltkpreview.Tpo -c -o libDw_fltk_a-fltkpreview.o `test -f 'fltkpreview.cc' || echo './'`fltkpreview.cc mv -f .deps/libDw_fltk_a-fltkpreview.Tpo .deps/libDw_fltk_a-fltkpreview.Po g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/local/include -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT libDw_fltk_a-fltkui.o -MD -MP -MF .deps/libDw_fltk_a-fltkui.Tpo -c -o libDw_fltk_a-fltkui.o `test -f 'fltkui.cc' || echo './'`fltkui.cc fltkui.cc: In member function ?virtual void dw::fltk::ui::FltkListResource::setWidgetStyle(Fl_Widget*, dw::core::style::Style*)?: fltkui.cc:1075: error: ?class Fl_Tree? has no member named ?item_labelfont? fltkui.cc:1076: error: ?class Fl_Tree? has no member named ?item_labelsize? fltkui.cc:1077: error: ?class Fl_Tree? has no member named ?item_labelfgcolor? fltkui.cc:1078: error: ?class Fl_Tree? has no member named ?item_labelbgcolor? make[2]: *** [libDw_fltk_a-fltkui.o] Error 1 make[2]: Leaving directory `/home/roger/src/dillo/dillo_port1.3/dw' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/roger/src/dillo/dillo_port1.3' make: *** [all] Error 2 -- Roger http://rogerx.freeshell.org/

March 11, 2011

big mistake with hg

by Johannes.Hofmann＠gmx.de

On Thu, Mar 10, 2011 at 02:45:32PM -0300, Jorge Arellano Cid wrote: > On Thu, Mar 10, 2011 at 05:59:21PM +0100, Johannes Hofmann wrote: > > On Thu, Mar 10, 2011 at 04:46:32PM +0000, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > I just pushed 120 changesets to hg "dillo" instead of "dillo_port1.3" > > > by mistake (wrong default). > > > > > > Is there a simple way to clean the mess by purging the changes? > > > > If it's the last push to the "dillo" repo, you can run > > hg rollback > > on the master repo. > > Where's the master repo? (I can't find it in auriga). I also just looked around and it seems to be on a different machine (hg.dillo.org) where I can't log in. > > > Alternatively you can do > > hg clone -r <last good revision> dillo dillo_purged > > to create a new purged clone and then replace the master repo with > > that. > > I don't have the last revision (haven't worked on 2.x for a while) > > Sorry for the troubles... Once we have access to the main repo it's no problem to fix that. Cheers, Johannes

March 10, 2011

big mistake with hg

by Johannes.Hofmann＠gmx.de

On Thu, Mar 10, 2011 at 12:18:38PM -0500, Benjamin Johnson wrote: > Try 'hg strip': http://mercurial.selenic.com/wiki/Strip That would also work, but in all cases you need access to the master repo on hg.dillo.org. Can you log in there? Otherwise Andreas would have to help. Cheers, Johannes

March 10, 2011

big mistake with hg

by jcid＠dillo.org

On Thu, Mar 10, 2011 at 05:59:21PM +0100, Johannes Hofmann wrote: > On Thu, Mar 10, 2011 at 04:46:32PM +0000, Jorge Arellano Cid wrote: > > Hi there, > > > > I just pushed 120 changesets to hg "dillo" instead of "dillo_port1.3" > > by mistake (wrong default). > > > > Is there a simple way to clean the mess by purging the changes? > > If it's the last push to the "dillo" repo, you can run > hg rollback > on the master repo. Where's the master repo? (I can't find it in auriga). > Alternatively you can do > hg clone -r <last good revision> dillo dillo_purged > to create a new purged clone and then replace the master repo with > that. I don't have the last revision (haven't worked on 2.x for a while) Sorry for the troubles... -- Cheers Jorge.-

March 10, 2011

big mistake with hg

by obeythepenguin＠gmail.com

Try 'hg strip': http://mercurial.selenic.com/wiki/Strip Cheers, ~Benjamin On 3/10/11, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Hi there, > > I just pushed 120 changesets to hg "dillo" instead of "dillo_port1.3" > by mistake (wrong default). > > Is there a simple way to clean the mess by purging the changes? > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

March 10, 2011

big mistake with hg

by johannes.hofmann＠gmx.de

On Thu, Mar 10, 2011 at 04:46:32PM +0000, Jorge Arellano Cid wrote: > Hi there, > > I just pushed 120 changesets to hg "dillo" instead of "dillo_port1.3" > by mistake (wrong default). > > Is there a simple way to clean the mess by purging the changes? If it's the last push to the "dillo" repo, you can run hg rollback on the master repo. Alternatively you can do hg clone -r <last good revision> dillo dillo_purged to create a new purged clone and then replace the master repo with that. Cheers, Johannes

March 10, 2011

big mistake with hg

by jcid＠dillo.org

On Thu, Mar 10, 2011 at 01:46:32PM -0300, Jorge Arellano Cid wrote: > Hi there, > > I just pushed 120 changesets to hg "dillo" instead of "dillo_port1.3" > by mistake (wrong default). > > Is there a simple way to clean the mess by purging the changes? BTW, I just also pushed them correctly to "dillo_port1.3", so now there's a new UI and no need to apply any patch on top. This is not finished, I'm working on the details (minor stuff) but decided to commit early so everybody can try the code. The missing parts already work in my prototype so it's more merging work than anything. BTW, tabs are completely new (custom which gives more control over them), and part of a major simplification of the code. For instance I hooked right-click to close-tab just for testing and it feels handy! :) Please enjoy. -- Cheers Jorge.-

March 10, 2011

big mistake with hg

by jcid＠dillo.org

Hi there, I just pushed 120 changesets to hg "dillo" instead of "dillo_port1.3" by mistake (wrong default). Is there a simple way to clean the mess by purging the changes? -- Cheers Jorge.-

March 10, 2011

dillo_port1.3: ctrl-q randomly kills dillo and all tabs

by jcid＠dillo.org

On Thu, Mar 03, 2011 at 04:40:28PM -0900, Roger wrote: > > On Tue, Mar 01, 2011 at 01:02:30PM +0000, corvid wrote: > >Roger wrote: > >> I took a snapshot of dillo_port1.3 a week or so ago and have been finding on > >> CTRL+Q randomly acts like ALT+Q (or kills the Dillo session with all open > >> tabs). > >> > >> One way I've been able to reproduce this, loading several websites and letting > >> them to load completely and then do CTRL+Q. (This bug doesn't present itself > >> on simpler web pages such as google.com or a simple weather forecasting > >> website. Need something with some junk in it. :-/) > > > >How does it behave with more recent code? > > Looks good now. Just pulled a snapshot this morning & built. > > This bug hasn't occurred yet. > > Side note -- the tabs don't refresh as being closed. I'm working on the UI, and decided to implement a new, custom tab mechanism for 1.3 (it is in my HD now). After all the old one had some problems we couldn't fix. When I have it working more or less stable I'll commit. -- Cheers Jorge.-

March 4, 2011

dillo_port1.3: ctrl-q randomly kills dillo and all tabs

by rogerx.oss＠gmail.com

> On Tue, Mar 01, 2011 at 01:02:30PM +0000, corvid wrote: >Roger wrote: >> I took a snapshot of dillo_port1.3 a week or so ago and have been finding on >> CTRL+Q randomly acts like ALT+Q (or kills the Dillo session with all open >> tabs). >> >> One way I've been able to reproduce this, loading several websites and letting >> them to load completely and then do CTRL+Q. (This bug doesn't present itself >> on simpler web pages such as google.com or a simple weather forecasting >> website. Need something with some junk in it. :-/) > >How does it behave with more recent code? Looks good now. Just pulled a snapshot this morning & built. This bug hasn't occurred yet. Side note -- the tabs don't refresh as being closed. -- Roger http://rogerx.freeshell.org/

March 4, 2011

Resizing a window changes the reading location

by Johannes.Hofmann＠gmx.de

On Thu, Mar 03, 2011 at 03:11:59PM -0500, Dennis Nezic wrote: > When windows (with wrapping lines) are resized, the page position > changes, and users have to manually find where they left off. It looks > like a rounding error, since the % in the page is roughly the same -- > but not exactly. I think the absolute offset in pixels - not the percentage is remembered. Simply switching to a percentage based scheme is problematic as the overall height of the page changes while loading.

March 3, 2011

Resizing a window changes the reading location

by dennisn＠dennisn.dyndns.org

When windows (with wrapping lines) are resized, the page position changes, and users have to manually find where they left off. It looks like a rounding error, since the % in the page is roughly the same -- but not exactly.

March 3, 2011

Bug: dillo fails to follow the redirects and reach the webpage

by Johannes.Hofmann＠gmx.de

On Tue, Mar 01, 2011 at 08:14:01AM +0000, Jeremy Henty wrote: > Benjamin Johnson wrote: > > > The default is not to allow automatic requests (such as redirects) > > unless they're from the same domain. Frankly I think this is a > > stupid default, because even though it's a little more secure, it > > also breaks most real world sites. > > I agree. The default even breaks Google. No doubt the security > concerns are real but we need a solution that is not so bad for > usability. Does anyone know if other browsers take similar > precautions, and what their algorithm is? I think the security concern is real - see e.g. here: http://www.owasp.org/index.php/CSRF But I would be happy if someone would come up with some more sophisticated security measures that would allow us be more compatible with common websites by default. Maybe something as described in http://www.owasp.org/index.php/File:RequestRodeo-MartinJohns.pdf Not sure whether this is still state of the art, but it sounds at least reasonable. Cheers, Johannes

March 1, 2011

Bug: dillo fails to follow the redirects and reach the webpage

by obeythepenguin＠gmail.com

On Tue, 01 Mar 2011 03:14:01 -0500, Jeremy Henty <onepoint(a)starurchin.org> wrote: > Benjamin Johnson wrote: > >> The default is not to allow automatic requests (such as redirects) >> unless they're from the same domain. Frankly I think this is a >> stupid default, because even though it's a little more secure, it >> also breaks most real world sites. > > I agree. The default even breaks Google. No doubt the security > concerns are real but we need a solution that is not so bad for > usability. Does anyone know if other browsers take similar > precautions, and what their algorithm is? > > Regards, > > Jeremy Henty Opera has Tools -> Preferences -> Advanced -> Network -> Enable automatic redirection, which looks to be the same as the dillorc option, but enabled by default. There's no special algorithm, as far as I know. Regards, ~Benjamin

March 1, 2011

dillo_port1.3: ctrl-q randomly kills dillo and all tabs

by corvid＠lavabit.com

Roger wrote: > I took a snapshot of dillo_port1.3 a week or so ago and have been finding on > CTRL+Q randomly acts like ALT+Q (or kills the Dillo session with all open > tabs). > > One way I've been able to reproduce this, loading several websites and letting > them to load completely and then do CTRL+Q. (This bug doesn't present itself > on simpler web pages such as google.com or a simple weather forecasting > website. Need something with some junk in it. :-/) How does it behave with more recent code?

March 1, 2011

Bug: dillo fails to follow the redirects and reach the webpage

by onepoint＠starurchin.org

Benjamin Johnson wrote: > The default is not to allow automatic requests (such as redirects) > unless they're from the same domain. Frankly I think this is a > stupid default, because even though it's a little more secure, it > also breaks most real world sites. I agree. The default even breaks Google. No doubt the security concerns are real but we need a solution that is not so bad for usability. Does anyone know if other browsers take similar precautions, and what their algorithm is? Regards, Jeremy Henty

March 1, 2011

dillo_port1.3: ctrl-q randomly kills dillo and all tabs

by rogerx.oss＠gmail.com

I took a snapshot of dillo_port1.3 a week or so ago and have been finding on CTRL+Q randomly acts like ALT+Q (or kills the Dillo session with all open tabs). One way I've been able to reproduce this, loading several websites and letting them to load completely and then do CTRL+Q. (This bug doesn't present itself on simpler web pages such as google.com or a simple weather forecasting website. Need something with some junk in it. :-/)

March 1, 2011

Bug: dillo fails to follow the redirects and reach the webpage

by obeythepenguin＠gmail.com

Try adding this to your dillorc: filter_auto_requests=allow_all The default is not to allow automatic requests (such as redirects) unless they're from the same domain. Frankly I think this is a stupid default, because even though it's a little more secure, it also breaks most real world sites. Then again, there's probably a reason I'm not a Dillo dev... Cheers, ~Benjamin On Mon, 28 Feb 2011 20:53:57 -0500, higuita <higuita7(a)yahoo.co.uk> wrote: > Hi > i setup my RSS feeder to use dillo, but i found that dillo > cant open the request pages for many feeds... example: > > http://feedproxy.google.com/~r/Phoronix/~3/TPVKpXMovJ8/vr.php > > Looks like dillo sees the first redirect, but dont really > follow it to see the next redirect... yet i see it follow other > redirects just fine... > > If i pick the redirect url and give it to dillo, it opens > the page just fine. So i would say that dillo fails to follow 2 or > more redirects. > > Thanks for dillo and for the help > higuita

March 1, 2011

Bug: dillo fails to follow the redirects and reach the webpage

by higuita7＠yahoo.co.uk

Hi i setup my RSS feeder to use dillo, but i found that dillo cant open the request pages for many feeds... example: http://feedproxy.google.com/~r/Phoronix/~3/TPVKpXMovJ8/vr.php Looks like dillo sees the first redirect, but dont really follow it to see the next redirect... yet i see it follow other redirects just fine... If i pick the redirect url and give it to dillo, it opens the page just fine. So i would say that dillo fails to follow 2 or more redirects. Thanks for dillo and for the help higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

March 1, 2011

Mouse Wheel 80-90% slower then Seamonkey?

by jcid＠dillo.org

On Wed, Feb 16, 2011 at 04:07:01AM -0900, Roger wrote: > > On Sat, Feb 12, 2011 at 01:13:13AM -0300, Jorge Arellano Cid wrote: > >On Thu, Feb 03, 2011 at 04:01:03PM -0900, Roger wrote: > >> Anybody else notice the mouse wheel is slow within Dillo? > >> > >> Comparing dillo_port1.3 to Seamonkey, dillo_port1.3 is almost 80-90% slower > >> compared to Seamonkey. > >> > >> Comparing dillo_port1.3 to dillo, dillo_port1.3 is slower by approx. 50%. > > > > Yes, this is controlled by: > > > > FltkViewport::setScrollStep(int step) > > > > which calls the scrollbar's linesize() function. > > > > using (3 * current value) is similar to dillo2.2 > > I've played with this a little and found setting to 84 was OK, but 168 was > best. I haven't tried any faster, nor do I think I want to. One scroll on my > mouse wheel will scroll approximately one page height. Think I'm using a > 1680x1050 wide screen LCD monitor here. > > Respectively; 14*6=84, 14*12=168 > > I haven't tried my other boxes monitor resolutions of 1280x1024 & 1400x1050 yet. > > I know the previous scrollsteps were EXTREMELY slow here! It looks like a "scroll_step" dillorc option would be handy. -- Cheers Jorge.-

Feb. 16, 2011

Mouse Wheel 80-90% slower then Seamonkey?

by rogerx.oss＠gmail.com

> On Sat, Feb 12, 2011 at 01:13:13AM -0300, Jorge Arellano Cid wrote: >On Thu, Feb 03, 2011 at 04:01:03PM -0900, Roger wrote: >> Anybody else notice the mouse wheel is slow within Dillo? >> >> Comparing dillo_port1.3 to Seamonkey, dillo_port1.3 is almost 80-90% slower >> compared to Seamonkey. >> >> Comparing dillo_port1.3 to dillo, dillo_port1.3 is slower by approx. 50%. > > Yes, this is controlled by: > > FltkViewport::setScrollStep(int step) > > which calls the scrollbar's linesize() function. > > using (3 * current value) is similar to dillo2.2 I've played with this a little and found setting to 84 was OK, but 168 was best. I haven't tried any faster, nor do I think I want to. One scroll on my mouse wheel will scroll approximately one page height. Think I'm using a 1680x1050 wide screen LCD monitor here. Respectively; 14*6=84, 14*12=168 I haven't tried my other boxes monitor resolutions of 1280x1024 & 1400x1050 yet. I know the previous scrollsteps were EXTREMELY slow here!

Feb. 16, 2011

dillo_port1.3: ‘class Fl_Tree’ has no member named ‘item_labelfont’

by rogerx.oss＠gmail.com

> On Sat, Feb 12, 2011 at 09:44:27AM +0100, Johannes Hofmann wrote: >On Fri, Feb 11, 2011 at 08:33:00PM -0900, Roger wrote: >> After doing hg pull && hg update, and then make clean && ./configure && make: >> >> mv -f .deps/libDw_fltk_a-fltkpreview.Tpo .deps/libDw_fltk_a-fltkpreview.Po >> g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT libDw_fltk_a-fltkui.o -MD -MP -MF .deps/libDw_fltk_a-fltkui.Tpo -c -o libDw_fltk_a-fltkui.o `test -f 'fltkui.cc' || echo './'`fltkui.cc >> fltkui.cc: In member function ?virtual void dw::fltk::ui::FltkListResource::setWidgetStyle(Fl_Widget*, dw::core::style::Style*)?: >> fltkui.cc:1075: error: ?class Fl_Tree? has no member named ?item_labelfont? >> fltkui.cc:1076: error: ?class Fl_Tree? has no member named ?item_labelsize? >> fltkui.cc:1077: error: ?class Fl_Tree? has no member named ?item_labelfgcolor? >> fltkui.cc:1078: error: ?class Fl_Tree? has no member named ?item_labelbgcolor? >> make[2]: *** [libDw_fltk_a-fltkui.o] Error 1 >> make[2]: Leaving directory `/home/roger/src/dillo/dillo_port1.3/dw' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/home/roger/src/dillo/dillo_port1.3' >> make: *** [all] Error 2 > >See >http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-February/008055.html Ah. I see this has been "Fixed in r8340" of fltk-1.3 (CVS/SVN) sources. As such, my snapshot of fltk-1.3 is now considered out-dated on Gentoo! :-( (I've put in a suggestion to fltk-1.3 snapshot ebuild on bugs.gentoo.org for him to just create a SVN/CVS ebuild instead of spending time on routinely creating each snapshot ebuild. This would also avoid such situations like this in the future.)

Feb. 13, 2011

for 1.3 port, latest fltk snapshot is required

by jcid＠dillo.org

On Fri, Feb 04, 2011 at 05:18:08PM +0000, corvid wrote: > ..because we're using some new stuff that they added for us > http://fltk.org/newsgroups.php?s23204+gfltk.general+v23210+T0 BTW, I'm working on the GUI, so expect a big commit these days... -- Cheers Jorge.-

Feb. 12, 2011

dillo_port1.3: ‘class Fl_Tree’ has no member named ‘item_labelfont’

by Johannes.Hofmann＠gmx.de

On Fri, Feb 11, 2011 at 08:33:00PM -0900, Roger wrote: > After doing hg pull && hg update, and then make clean && ./configure && make: > > mv -f .deps/libDw_fltk_a-fltkpreview.Tpo .deps/libDw_fltk_a-fltkpreview.Po > g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT libDw_fltk_a-fltkui.o -MD -MP -MF .deps/libDw_fltk_a-fltkui.Tpo -c -o libDw_fltk_a-fltkui.o `test -f 'fltkui.cc' || echo './'`fltkui.cc > fltkui.cc: In member function ?virtual void dw::fltk::ui::FltkListResource::setWidgetStyle(Fl_Widget*, dw::core::style::Style*)?: > fltkui.cc:1075: error: ?class Fl_Tree? has no member named ?item_labelfont? > fltkui.cc:1076: error: ?class Fl_Tree? has no member named ?item_labelsize? > fltkui.cc:1077: error: ?class Fl_Tree? has no member named ?item_labelfgcolor? > fltkui.cc:1078: error: ?class Fl_Tree? has no member named ?item_labelbgcolor? > make[2]: *** [libDw_fltk_a-fltkui.o] Error 1 > make[2]: Leaving directory `/home/roger/src/dillo/dillo_port1.3/dw' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/roger/src/dillo/dillo_port1.3' > make: *** [all] Error 2 See http://lists.auriga.wearlab.de/pipermail/dillo-dev/2011-February/008055.html Cheers, Johannes

Feb. 12, 2011

dillo_port1.3: ‘class Fl_Tree’ has no member named ‘item_labelfont’

by rogerx.oss＠gmail.com

After doing hg pull && hg update, and then make clean && ./configure && make: mv -f .deps/libDw_fltk_a-fltkpreview.Tpo .deps/libDw_fltk_a-fltkpreview.Po g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -I/usr/include/fltk-1.1 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT libDw_fltk_a-fltkui.o -MD -MP -MF .deps/libDw_fltk_a-fltkui.Tpo -c -o libDw_fltk_a-fltkui.o `test -f 'fltkui.cc' || echo './'`fltkui.cc fltkui.cc: In member function ?virtual void dw::fltk::ui::FltkListResource::setWidgetStyle(Fl_Widget*, dw::core::style::Style*)?: fltkui.cc:1075: error: ?class Fl_Tree? has no member named ?item_labelfont? fltkui.cc:1076: error: ?class Fl_Tree? has no member named ?item_labelsize? fltkui.cc:1077: error: ?class Fl_Tree? has no member named ?item_labelfgcolor? fltkui.cc:1078: error: ?class Fl_Tree? has no member named ?item_labelbgcolor? make[2]: *** [libDw_fltk_a-fltkui.o] Error 1 make[2]: Leaving directory `/home/roger/src/dillo/dillo_port1.3/dw' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/roger/src/dillo/dillo_port1.3' make: *** [all] Error 2

Feb. 12, 2011

Mouse Wheel 80-90% slower then Seamonkey?

by jcid＠dillo.org

On Thu, Feb 03, 2011 at 04:01:03PM -0900, Roger wrote: > Anybody else notice the mouse wheel is slow within Dillo? > > Comparing dillo_port1.3 to Seamonkey, dillo_port1.3 is almost 80-90% slower > compared to Seamonkey. > > Comparing dillo_port1.3 to dillo, dillo_port1.3 is slower by approx. 50%. Yes, this is controlled by: FltkViewport::setScrollStep(int step) which calls the scrollbar's linesize() function. using (3 * current value) is similar to dillo2.2 HTH. -- Cheers Jorge.-

Feb. 12, 2011

Recent problems with remote css and youtube

by bf2006a＠yahoo.com

--- On Wed, 2/9/11, corvid <corvid(a)lavabit.com> wrote: > From: corvid <corvid(a)lavabit.com> > Subject: Re: [Dillo-dev] Recent problems with remote css and youtube > To: dillo-dev(a)dillo.org > Date: Wednesday, February 9, 2011, 9:35 PM > I wrote: > > bf wrote: > > > Using snapshots of dillo from the last several > months, with both fltk 2.0 r7513 and r7525 on FreeBSD > 9-CURRENT amd64, I'm able to consistently crash dillo with a > segfault by scrolling to the bottom of many pages at > www.youtube.com with the mouse or keyboard.? The same > problem does not occur if I disable the use of remote > CSS.? Has anyone else noticed this problem? > > > > I can reproduce this. It probably has something to do > with the > > transparent borders change that I made in December... > > My transparent borders code and Jorge's border code were > fighting > with each other. Does the attached fix it for you? > Yes, it seems to fix it: with the patch applied, I have not been able to reproduce the problem. Thanks, b.

Feb. 10, 2011

Recent problems with remote css and youtube

by corvid＠lavabit.com

I wrote: > bf wrote: > > Using snapshots of dillo from the last several months, with both fltk 2.0 r7513 and r7525 on FreeBSD 9-CURRENT amd64, I'm able to consistently crash dillo with a segfault by scrolling to the bottom of many pages at www.youtube.com with the mouse or keyboard. The same problem does not occur if I disable the use of remote CSS. Has anyone else noticed this problem? > > I can reproduce this. It probably has something to do with the > transparent borders change that I made in December... My transparent borders code and Jorge's border code were fighting with each other. Does the attached fix it for you? Jorge: Were any of those borderColor.top for a reason, or just oversights? If the latter, I can think of a simple change that would be less error-prone :)

Feb. 10, 2011

Recent problems with remote css and youtube

by corvid＠lavabit.com

bf wrote: > Using snapshots of dillo from the last several months, with both fltk 2.0 r7513 and r7525 on FreeBSD 9-CURRENT amd64, I'm able to consistently crash dillo with a segfault by scrolling to the bottom of many pages at www.youtube.com with the mouse or keyboard. The same problem does not occur if I disable the use of remote CSS. Has anyone else noticed this problem? I can reproduce this. It probably has something to do with the transparent borders change that I made in December...

Feb. 10, 2011

Recent problems with remote css and youtube

by bf2006a＠yahoo.com

Using snapshots of dillo from the last several months, with both fltk 2.0 r7513 and r7525 on FreeBSD 9-CURRENT amd64, I'm able to consistently crash dillo with a segfault by scrolling to the bottom of many pages at www.youtube.com with the mouse or keyboard. The same problem does not occur if I disable the use of remote CSS. Has anyone else noticed this problem? Regards, b. ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/

Feb. 10, 2011

Valgrind errors from downloads.cc

by jcid＠dillo.org

On Wed, Feb 09, 2011 at 05:14:21PM +0000, corvid wrote: > Jeremy wrote: > > Valgrind is reporting uninitialised data in DLItem::update() in > > downloads.cc[1]. Here's the code with the offending lines (705, 706) > > marked. > > > > /* Rate */ > > if (csec >= 2) { > > tsec = (float) (curr_time - twosec_time); > > ! rate = ((float)(curr_bytesize-twosec_bytesize) / 1024) / tsec; > > ! snprintf(str, 64, (rate < 100) ? "%.1fK/s" : "%.0fK/s", rate); > > prRate->copy_label(str); > > prRate->redraw_label(); > > } > > > > I'm wondering what is happening here. DLItem::update() is scheduled > > to be run every second. I think that twosec_time is only set to an > > initialised value when the function has been run at least twice > > before. Also, csec is calculated from the difference between the > > current time and the initial time. Is it possible that the "csec >= > > 2" could be true even when the function has been run only once before? > > After all, the timing of callbacks is never exact. Perhaps the > > callback should explicitly count how many times it has been called > > rather than attempt to work it out from the timing? > > (The list software never did send me a copy of your msg...) Strange. Although I remember the wearlab was down a few days ago... > Would something like the following work? > > --- a/dpi/downloads.cc Tue Jan 11 01:18:28 2011 +0000 > +++ b/dpi/downloads.cc Sun Feb 06 20:40:53 2011 +0000 > @@ -318,6 +318,8 @@ > // Init value. Reset later, upon the first data bytes arrival > init_time = time(NULL); > > + twosec_time = onesec_time = init_time; > + > // BUG:? test a URL with ' inside. > /* escape "'" character for the shell. Is it necessary? */ > esc_url = Escape_uri_str(url, "'"); Most probably. I have a vague memory of noticing the issue when coding it long ago, but not caring much as the following second the display would be updated with correct data. -- Cheers Jorge.-

Feb. 9, 2011

Valgrind errors from downloads.cc

by corvid＠lavabit.com

Jeremy wrote: > Valgrind is reporting uninitialised data in DLItem::update() in > downloads.cc[1]. Here's the code with the offending lines (705, 706) > marked. > > /* Rate */ > if (csec >= 2) { > tsec = (float) (curr_time - twosec_time); > ! rate = ((float)(curr_bytesize-twosec_bytesize) / 1024) / tsec; > ! snprintf(str, 64, (rate < 100) ? "%.1fK/s" : "%.0fK/s", rate); > prRate->copy_label(str); > prRate->redraw_label(); > } > > I'm wondering what is happening here. DLItem::update() is scheduled > to be run every second. I think that twosec_time is only set to an > initialised value when the function has been run at least twice > before. Also, csec is calculated from the difference between the > current time and the initial time. Is it possible that the "csec >= > 2" could be true even when the function has been run only once before? > After all, the timing of callbacks is never exact. Perhaps the > callback should explicitly count how many times it has been called > rather than attempt to work it out from the timing? (The list software never did send me a copy of your msg...) Would something like the following work? --- a/dpi/downloads.cc Tue Jan 11 01:18:28 2011 +0000 +++ b/dpi/downloads.cc Sun Feb 06 20:40:53 2011 +0000 @@ -318,6 +318,8 @@ // Init value. Reset later, upon the first data bytes arrival init_time = time(NULL); + twosec_time = onesec_time = init_time; + // BUG:? test a URL with ' inside. /* escape "'" character for the shell. Is it necessary? */ esc_url = Escape_uri_str(url, "'"); > [1] > http://starurchin.org/dillo/valgrind.html > http://starurchin.org/dillo/valgrind/6444c6ff40e01e517ce6e802f23670c5422c6e… > http://starurchin.org/dillo/valgrind/68bd8732669bbac8e11f1ea5a692db022fc6a6… > http://starurchin.org/dillo/valgrind/6f1d6a4feadf8136cbed37497a1d6dbbfea4a3… > http://starurchin.org/dillo/valgrind/68026e750cc92b08699c26392ecfd92cf370a9… >

Feb. 9, 2011