From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 081F978932 for ; Tue, 15 Sep 2015 16:18:15 -0700 (PDT) Received: by wicge5 with SMTP id ge5so50222752wic.0 for ; Tue, 15 Sep 2015 16:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=SiNTYva6vMGchXMO7UiVF0HWVcEuPt3ZHeYQJIoajBY=; b=OSdS8+q6wtMQYir5iQSr/vVvnz3B4+ztCKaCdamIVD7e6nhPljrxJqEQUnsJj6t8BH PZZbcIvZ/5NZMkB5SyF0qPoDohu1m0YyV5/f1M9A3VatQ/x4Zyrglo4IzGP/aa5xVV78 w53iaYSgcbteppr3OaOHIStNrt0COl+UAdkqbM5/2AzOhEovZHtUwQwJsbCHx4Ny7pAi /yPoaOZMI6We3SUVsDhXBufLxVK2spg1W7n2ncBZT008NSxIkX44tc0E1MIESjMgD8EN r2myMtydYP6SFCKCc/fPwjkXX9Iqk5rlqpKFXbnNUexjxWFMk+raaqsUkqRyLq4RZ7EC 7cAQ== X-Received: by 10.194.117.133 with SMTP id ke5mr45355615wjb.116.1442359263652; Tue, 15 Sep 2015 16:21:03 -0700 (PDT) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by smtp.gmail.com with ESMTPSA id r4sm1347180wia.19.2015.09.15.16.21.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Sep 2015 16:21:02 -0700 (PDT) Date: Wed, 16 Sep 2015 00:21:00 +0100 From: Adam Thompson To: Karl Dahlke Cc: Edbrowse-dev@lists.the-brannons.com Message-ID: <20150915232100.GI29720@toaster.adamthompson.me.uk> References: <20150814171732.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HkMjoL2LAeBLhbFV" Content-Disposition: inline In-Reply-To: <20150814171732.eklhad@comcast.net> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [Edbrowse-dev] rerender X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 23:18:15 -0000 --HkMjoL2LAeBLhbFV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 14, 2015 at 05:17:32PM -0400, Karl Dahlke wrote: > So many things are changing, I mean it's a complete redesign, > and I'm trying to keep the ship sailing in the meantime. > If I step back and think about it globally my head spins, > so I keep head down, stay focused, and make one incremental change at a t= ime. >=20 > As we move forward, more things don't work in the old system, > and I can't maintain it forever. > With the latest push, edbrowse runs on the new system by default. > If you really need javascript, and I have badly broken it, > export oldsystem=3D1 > to bring back the old system; but I can't guarantee how long > it will keep working. Yeah, I think we probably need to introduce a deadline on that as otherwise there'll always be a reason to keep the code in the codebase. > The new system has a new 2 letter command, rr, for rerender. > It's a little bit meaningless now, but will make sense when > (someday) we have asynchronous javascript running. Yeah, that's on my todo list. Do we think that should be before or after the duktape investigations? > Perhaps stock prices on the page have changed, which a sighted person > would just look at the screen and see the change; we would type rr for re= render. > When you do this now it just says "no change". > This has no meaning in the old system, or when not in browse mode, > or when js is inactive. Sounds good. > The point here is that rerender is called internally > after each javascript action. > Perhaps you clicked on a button, or changed a field > that has onchange code associated with it, or whatever. > The objects change, the screen is rerendered, and compared > against the old. > Like if you change the state in jsrt to Utah, which changes the color men= u. >=20 > This is really really preliminary. > The comparison is done by strcmp. > If the screen is unchanged, and it almost always is, > that's the high runner case, I don't do anything and don't print anything. > Just move on. > If a single byte of the screen changes, I delete the old contents, > put in the new, and tell you that something has changed. > That's it, for now. > You get to figure out what has changed. > Of course I'll put in some more smarts over the next few days, > some kind of diff algorithm to tell you > "line 12 has been updated", and perhaps just changing that line > so I can retain your dot location and any labels you might have set. > That's coming but for now it's clunky, > just to prove the concept. Can't we do something fancy with our line mappings to do this? It won't be particularly performant but we should be able to isolate the ch= ange to a line? > Yes, we can rerender the tree of nodes again and again, > and reflect any changes that have been made through javascript. Excellent. I guess, once all this is finished, the next step is to get the js to DOM link a bit more automatic such that a= ny attributes set on a tag's js object are reflected in the edbrowse representation. Last time I checked this didn't happen but I've not checked= the new code. The same applies for js objects which represent nodes being automagically incerted into the DOM. Again not checked the new code for this. Cheers, Adam. --HkMjoL2LAeBLhbFV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJV+KfcAAoJELZ22lNQBzHOLzUIAM0rwNIezij/ea1jzHhIEAhl L59L6gLVB+kwjZ67KWg+XdCFZz5SxsC78kGsH2hwoPZaQM3F551PBq+STei40X73 fERl25OHWD5wRaA6nJ3mqrqd4xXwAeuN9egCg+hKxv5zEpyugNVDhaSg4PCyn19f c7MgF8MtZeTTzgxPPOCXnxlyAnwHsRkB6ntc6s6DjMjVL2zwcHsnKbd6XIzOe71K mJjdL9ydXkudvbRmbozNbHhL88vkPQt7v+KWgiuNmIkgnE4JWhZlnE3oRv1DK9NB z/A/VBwTTgcZ1dJUoLFrDzM4Bo5Z2u5+GWJ2nXZGNYZ9tad8kvMUbz3bMOtIpJg= =rr8u -----END PGP SIGNATURE----- --HkMjoL2LAeBLhbFV--