- Dillo-dev - lists.mailman3.com

patch: image loading on demand for complex button

by corvid＠lavabit.com

(Jorge: Okay. That gives me an opportunity to put this in the priority queue instead.) I was able to get the menus to work for buttons and image inputs, so image loading can be conditional now. My usual disclaimer applies regarding the dw2 side that I did something that made it work, but it may not be the right way.

April 17, 2008

Good news from fltk!

by jcid＠dillo.org

On Tue, Apr 15, 2008 at 09:18:23PM +0200, Johannes Hofmann wrote: > Hi Jorge, > > On Tue, Apr 15, 2008 at 02:38:35PM -0400, Jorge Arellano Cid wrote: > > Hi Johannes, > > > > On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > > > Hi Jeremy, > > > > > > On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote: > > > > > > > > On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > > > > > > > > > Attached is a patch that enables double buffering for partial screen > > > > > redraws (this is where the flickering is most annoying). You will > > > > > need at least version r6079 of fltk2 to test. > > > > > > > > OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch > > > > (fixed version). Looks OK so far. Any tests I should run? > > > > > > Mostly I would be interested whether it still feels fast. And any > > > regressions you observe, of course... > > > > I found something that looks like a bug in double buffering > > (it doesn't happen with the previous code). > > > > If you: > > > > - ./dillo-fltk about:splash > > - scroll down 1 or 2 inches. > > - browse to another URL. > > - press right mouse button over Back button and return to > > the first page. > > > > You'll end looking to the page through a window artifact in the > > control panel. i.e. The page rendering seems to start from below > > the control PANEL. > > > > Please give it a look. > > Patch 1 should fix the problem. Good! Committed. > > The second patch removes the push_clip() / pop_clip() pair that is no > longer necessary with double buffering (we only copy the needed > rectangle from the backBuffer anyway). > It might result in artifacts when running with > --disable-doublebuffer however. So I'm not sure if you want to > commit that part. I'd commit bracketed as: #ifdef NO_DOUBLEBUFFER push_clip (viewRect); #endif [Drawing code here...] #ifdef NO_DOUBLEBUFFER push_clip (viewRect); #endif Would it be OK? -- Cheers Jorge.-

April 17, 2008

Good news from fltk!

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Tue, Apr 15, 2008 at 02:38:35PM -0400, Jorge Arellano Cid wrote: > Hi Johannes, > > On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > > Hi Jeremy, > > > > On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote: > > > > > > On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > > > > > > > Attached is a patch that enables double buffering for partial screen > > > > redraws (this is where the flickering is most annoying). You will > > > > need at least version r6079 of fltk2 to test. > > > > > > OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch > > > (fixed version). Looks OK so far. Any tests I should run? > > > > Mostly I would be interested whether it still feels fast. And any > > regressions you observe, of course... > > I found something that looks like a bug in double buffering > (it doesn't happen with the previous code). > > If you: > > - ./dillo-fltk about:splash > - scroll down 1 or 2 inches. > - browse to another URL. > - press right mouse button over Back button and return to > the first page. > > You'll end looking to the page through a window artifact in the > control panel. i.e. The page rendering seems to start from below > the control PANEL. > > Please give it a look. Patch 1 should fix the problem. The second patch removes the push_clip() / pop_clip() pair that is no longer necessary with double buffering (we only copy the needed rectangle from the backBuffer anyway). It might result in artifacts when running with --disable-doublebuffer however. So I'm not sure if you want to commit that part. Cheers, Johannes

April 15, 2008

Re: patch: BUTTON

by corvid＠lavabit.com

Jorge wrote: > On Tue, Apr 15, 2008 at 04:16:55AM +0000, corvid wrote: > > section 17.2.1 says: > > > > "The elements used to create controls generally appear inside a FORM element, > > but may also appear outside of a FORM element declaration when they are used > > to build user interfaces. This is discussed in the section on intrinsic > > events. [p.254] Note that controls outside a form cannot be successful > > controls [p.245]." > > > > ..but I'll make a separate patch for controls outside of forms. > > AFAICS this may be useful with client side scripts, but we're > a long way from suporting scripts. It's also useful if you want to look at a page that explains tags. The page put up a button tag outside of a form to show me what button tags look like. (plus I've already written the code)

April 15, 2008

Good news from fltk!

by jcid＠dillo.org

Hi Johannes, On Tue, Apr 08, 2008 at 05:01:41PM +0200, Johannes Hofmann wrote: > Hi Jeremy, > > On Tue, Apr 08, 2008 at 07:35:25AM +0100, Jeremy Henty wrote: > > > > On Sat, Apr 05, 2008 at 05:01:52PM +0200, Johannes Hofmann wrote: > > > > > Attached is a patch that enables double buffering for partial screen > > > redraws (this is where the flickering is most annoying). You will > > > need at least version r6079 of fltk2 to test. > > > > OK, I've upgraded to the latest FLTK2 snapshot (r6087) and your patch > > (fixed version). Looks OK so far. Any tests I should run? > > Mostly I would be interested whether it still feels fast. And any > regressions you observe, of course... I found something that looks like a bug in double buffering (it doesn't happen with the previous code). If you: - ./dillo-fltk about:splash - scroll down 1 or 2 inches. - browse to another URL. - press right mouse button over Back button and return to the first page. You'll end looking to the page through a window artifact in the control panel. i.e. The page rendering seems to start from below the control PANEL. Please give it a look. -- Cheers Jorge.-

April 15, 2008

[patch] fix cookies freezing dillo problem

by jcid＠dillo.org

On Fri, Apr 11, 2008 at 11:49:26PM +0200, Andreas Kemnade wrote: > Hi Jorge, > > On Fri, 11 Apr 2008 15:34:49 -0400 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > Note: What still puzzles me, is why accept() returns when > > there's nothing to read. > > > > Hmm, accept() returns when you call connect() on the other side. > Many TCP server programs send stuff to the client before receiving anything > from the client (like ssh servers, smtp servers) so there is nothing unusual > about that. > > So, normally you have > on cookies.dpi side: > accept() > returns after connect() on dillo side > read() > returns after write() on dillo side > > then on dillo side: > read() returns after write() on cookies.dpi side. > > As far as I understand in the race condition case you have: > > dillo cookies.dpi > connect(sock1,...) sock1=accept(....) > connect(sock2,...) (via a_Dpi_send_blocking_cmd) read(sock1,...) > write(sock2,...) (does not block, contents will be added to the recv queue) > read(sock2,...) > > and now, both sides are waiting for data,.... Thanks a lot for the explanation. -- Cheers Jorge.-

April 15, 2008

Re: patch: BUTTON

by jcid＠dillo.org

On Tue, Apr 15, 2008 at 04:16:55AM +0000, corvid wrote: > The old code showed uncertainty about whether one can interact with the > stuff inside a button. The spec doesn't say. I suspect you aren't > supposed to be able to. Firefox doesn't let you. If FF doesn't allow interaction it will be hardly found in the WEB, unless IE allows. :-P > When trying to look up info on button nesting, I discovered -- by crashing -- > that I needed to test whether I was in a form. However, I learned that > section 17.2.1 says: > > "The elements used to create controls generally appear inside a FORM element, > but may also appear outside of a FORM element declaration when they are used > to build user interfaces. This is discussed in the section on intrinsic > events. [p.254] Note that controls outside a form cannot be successful > controls [p.245]." > > ..but I'll make a separate patch for controls outside of forms. AFAICS this may be useful with client side scripts, but we're a long way from suporting scripts. -- Cheers Jorge.-

April 15, 2008

patch: image inputs

by jcid＠dillo.org

On Tue, Apr 15, 2008 at 01:23:47AM +0000, corvid wrote: > Jorge wrote: > > Committed! (with some changes). > > I just noticed that when you took out the other return, > DEBUG_MSG(10, "Html_input_image: unable to create image submit.\n"); > became unconditional. Ooops... Fixed & committed. -- Cheers Jorge.-

April 15, 2008

Re: patch: file input

by jcid＠dillo.org

On Sat, Apr 12, 2008 at 02:06:42AM +0000, corvid wrote: > Jorge wrote: > > On Fri, Apr 11, 2008 at 09:21:16PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Thu, Apr 10, 2008 at 04:13:56PM +0000, corvid wrote: > > > > > If I read in a file, delete that file, and try to read it in again > > > > > (uses E2EReload), the submit will send the (now empty) file because > > > > > a_Capi_get_buf() finds the (now empty) entry in cache. > > > > > So I'll have to find out where an a_Cache_entry_remove_by_url() should go. > > > > > > > > Yes. > > > > > > It looks like I'd have to figure out CCC for this, which would > > > likely be more trouble than it's worth. > > > > OK, I'll allocate some time to give it a look. > > Cool. Patch committed. After pondering whether to add a URL flag to discriminate a file-input loaded-file (to be able to free it later), the complexities of it being also used/displayed by another Dillo window (and the inherent races), and the necessary handling code, I preferred a local load. The async approach may be done, but the committed approach is simpler, gets the work done, and may be extended to handle multiple files. I also added a handy heuristic for content-type detection of files (it works well with the w3c validator). -- Cheers Jorge.-

April 15, 2008

patch: image inputs

by corvid＠lavabit.com

Jorge wrote: > Committed! (with some changes). I just noticed that when you took out the other return, DEBUG_MSG(10, "Html_input_image: unable to create image submit.\n"); became unconditional.

April 15, 2008