- Dillo-dev - lists.mailman3.com

patch: conditionally sending Cookie2: Re: [Dillo-dev] Re: patch: cookies string leak

by place＠gobigwest.com

Jorge wrote: > I just noticed that calling current CVS with: > > http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 > > completely blocks the browser. > > It doesn't happen with older dillo2 versions. > > Please give it a look. No problems for me, either with or without cookies.

March 19, 2008

patch: conditionally sending Cookie2: Re: [Dillo-dev] Re: patch: cookies string leak

by jcid＠dillo.org

On Mon, Feb 04, 2008 at 08:10:25PM +0000, place wrote: > Jorge wrote: > > On Fri, Feb 01, 2008 at 06:26:56PM +0000, place wrote: > > > Also, what would you think of me either > > > > > > - stuffing the "Cookie2: $Version=\"1\"\r\n" header into a_Cookies_get(url) > > > > OK. > > attached. > > I renamed it a_Cookies_get_query() in an effort > to suggest that it now returned more than just > the cookies. > > > Everything looks fine when I watch the headers, > but I don't use dillo for anything that _relies_ > on cookies working properly. > > So...anyone who habitually uses cookies might want > to give this a bit of a test. I just noticed that calling current CVS with: http://www.fltk.org/newsgroups.php?gfltk.general+v:24912 completely blocks the browser. It doesn't happen with older dillo2 versions. Please give it a look. -- Cheers Jorge.-

March 19, 2008

[jcid@dillo.org: Re: [Dillo-dev] Re: patch: concatenate Dstrs]

by jcid＠dillo.org

-- Cheers Jorge.-

March 19, 2008

Re: patch: concatenate Dstrs

by jcid＠dillo.org

On Tue, Mar 18, 2008 at 07:48:00PM +0000, place wrote: > Jorge wrote: > > Does anybody else have some experience/theory/article/knowledge on API > > design that can enlighten us? > > > > ;) > > I just meant "okay, never mind". Understood. My point is there're other places in dillo where a more formal API definition is needed, and I'd like to know whether there's some theory or guiding experience that could help. -- Cheers Jorge.-

March 19, 2008

Re: patch: concatenate Dstrs

by place＠gobigwest.com

Jorge wrote: > Does anybody else have some experience/theory/article/knowledge on API > design that can enlighten us? > > ;) I just meant "okay, never mind".

March 18, 2008

Re: patch: concatenate Dstrs

by jcid＠dillo.org

On Tue, Mar 18, 2008 at 02:14:06PM +0000, place wrote: > > On Mon, Mar 17, 2008 at 11:35:05PM +0000, place wrote: > > > I made a dStr_dstrcat(). > > > > > > > What's the main advantage of it, over dStr_append_l() ? > > > > I see the convenience and clarity of passing two parameters instead > > of three, but on the other hand, keeping APIs reduced to a functional > > minimum, helps to remember and to choose the right function call. > > > > There may be a point I don't yet see... > > Nope, that's all there was to it. > And I don't have a strong opinion about it, so that's fine. Does anybody else have some experience/theory/article/knowledge on API design that can enlighten us? ;) -- Cheers Jorge.-

March 18, 2008

[patch] further reduce redraws from resizing tables

by jcid＠dillo.org

Hi, On Sat, Mar 15, 2008 at 07:58:34PM +0100, Johannes Hofmann wrote: > Hi Jorge, > > On Fri, Mar 14, 2008 at 06:53:08PM -0400, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Tue, Mar 11, 2008 at 07:27:01PM +0100, Johannes Hofmann wrote: > > > Hi, > > > > > > below is another patch to reduce the redraws caused by resizing > > > tables. A new method Layout::queueDrawExcept(), that requests the > > > drawing of a rectangle except another rectangle is added. > > > It is then used in widget.cc to redraw the area that was previously > > > occupied by a widget, but is no longer occupied after a resize or move. > > > This makes it possible to redraw less when a table resizes. > > > All in all it should reduce the flicker a bit when loading table > > > based pages. > > > > On the topic of reducing the flicker, I'm far of an expert and > > please correct me if I'm wrong. AFAIU, the current design draws > > the background color before the widget content. > > > > This is: if you have an html page as big table, in dillo, it > > will become a table inside a textblock. When the textblock is > > asked to redraw, it will _erase_ the table with its background > > color and ask its child (the table) to redraw. Causing flicker. > > Yes, that's true. > In addition, before anything is drawn, the rectangle to be drawn is > already cleared with the background color in FltkViewBase::draw() > (the fillrect () calls). Oh, I haven't noticed those calls. > > > > If this is true, a big gain could come from a different > > approach: just draw the surroundings of the widgets and ask the > > child widgets to redraw. > > > > This way widgets aren't erased beforehand, and can also decide > > not to redraw themselves when nothing has changed. > > > > I have worked a bit on this idea, and the attached patch mocks > > the idea hackishly. It draws the "padding" area of the CSS box > > (see the picture in namespacedw_1_1core_1_1style.html in dw docs) > > > > Please give it a review and share your comments, > > corrections and thoughts. > > I've been thinking about something similar as well, but I don't > think it will work out generally. > The main problem is text drawing and maybe transparent widgets > (don't know whether they exist already). Probably drawing text over a background image qualifies as "transparent text widget". > Anyway, for drawing text, you need to erase the area first. > Just comment out the fillrect () calls in FltkViewBase::draw() to > see what I mean :-) Yes, I did. Quite clear example. > Therefore, we will always have flicker, when drawing text. > > The good news is that all the flicker can be avoided easily with > some double buffering technique. And from dillo1 we even know that > this is not necessarily slow :-) > > So for me the flicker itself is not that much of a problem. > It may be an indicator for unnecessary redraws, which should be > avoided to save CPU power. But I think current cvs is already > pretty good in this regard. That makes me happy, because since the queueDrawExcept() patch, flickering has reduced even more. I'm yet to test on a slow system though. > > So I would propose to start to think about efficient double > buffering similar to what I had posted in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-November/003379.html > but platform independent using fltk2 support. Sure, and we still have the reosurce of tunning the refresh rate as in formerly proposed patches. I agree with your proposal. And if someday (soon I hope) we start working together with the FLTK guys, they will have lots of advice on how to tune things up. -- Cheers Jorge.-

March 18, 2008

[patch] further reduce redraws from resizing tables

by jcid＠dillo.org

On Tue, Mar 11, 2008 at 07:27:01PM +0100, Johannes Hofmann wrote: > Hi, > > below is another patch to reduce the redraws caused by resizing > tables. A new method Layout::queueDrawExcept(), that requests the > drawing of a rectangle except another rectangle is added. > It is then used in widget.cc to redraw the area that was previously > occupied by a widget, but is no longer occupied after a resize or move. > This makes it possible to redraw less when a table resizes. > All in all it should reduce the flicker a bit when loading table > based pages. Committed! -- Cheers Jorge.-

March 18, 2008

saving files under recent fltk snapshots?

by Johannes.Hofmann＠gmx.de

On Mon, Mar 17, 2008 at 06:56:26PM +0000, place wrote: > I moved to snapshot 6066 (I'd been on 5990) the other day, and now I > notice that dillo is unresponsive after I save a file. > > Seen in the 6059 announcement (http://fltk.org/articles.php?L791) > "+ Changed the modal event loop of file_chooser() and dir_chooser() > to use a new exec() method that delegates to Window::exec() internally. > This exec() method should handle unpleasant side effects with other modal > windows when closing the file_chooser dialog window. > > + Updated FileChooser.fl to reflect modifications made in the cxx/h files. > Please do not edit these files directly (except the include header) > Thanks." > > If anybody's tried a recent snapshot: Does it work for you? There seems to be a bug report regarding this already: http://fltk.org/newsgroups.php?s5234+gfltk.bugs+v5241+T0 Cheers, Johannes

March 18, 2008

Re: patch: concatenate Dstrs

by place＠gobigwest.com

> On Mon, Mar 17, 2008 at 11:35:05PM +0000, place wrote: > > I made a dStr_dstrcat(). > > > > What's the main advantage of it, over dStr_append_l() ? > > I see the convenience and clarity of passing two parameters instead > of three, but on the other hand, keeping APIs reduced to a functional > minimum, helps to remember and to choose the right function call. > > There may be a point I don't yet see... Nope, that's all there was to it. And I don't have a strong opinion about it, so that's fine.

March 18, 2008