Gitweb links:
...log
http://git.netsurf-browser.org/netsurf-wiki.git/shortlog/9a2ca4abf4aab7e74b8cba27675e0df387ab49c7
...commit
http://git.netsurf-browser.org/netsurf-wiki.git/commit/9a2ca4abf4aab7e74b8cba27675e0df387ab49c7
...tree
http://git.netsurf-browser.org/netsurf-wiki.git/tree/9a2ca4abf4aab7e74b8cba27675e0df387ab49c7
The branch, master has been updated
via 9a2ca4abf4aab7e74b8cba27675e0df387ab49c7 (commit)
from e7c307f78a74b7d8360ff5a5302a5de91a20d047 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commitdiff
http://git.netsurf-browser.org/netsurf-wiki.git/commit/?id=9a2ca4abf4aab7e74b8cba27675e0df387ab49c7
commit 9a2ca4abf4aab7e74b8cba27675e0df387ab49c7
Author: Daniel Silverstone <[email protected]>
Commit: Daniel Silverstone <[email protected]>
So many notes
diff --git a/developer-weekend/sep-2017.mdwn b/developer-weekend/sep-2017.mdwn
index 29c5d24..61403c0 100644
--- a/developer-weekend/sep-2017.mdwn
+++ b/developer-weekend/sep-2017.mdwn
@@ -62,11 +62,155 @@ Topics
*
[`#1879`](http://bugs.netsurf-browser.org/mantis/view.php?id=1879) (Resolved)
* [`#485`](http://bugs.netsurf-browser.org/mantis/view.php?id=485)
+* What frontends do we demote?
+ * See below
+
+* Administrivia - Phoenix's disks are tired (even SMART said so)
+ * We'd like to know where the society bank account stands, for general
+ resources.
+ * We'd like to buy a pair of WD Gold 1TB drives (rough cost 140 UKP total)
+ so that Phoenix isn't running on pre-fail age drives.
+ * Decision was: Michael, Vince, and Daniel will share the cost if the
+ society lacks the funds. Vince will buy drives and begin the replacement
+ process. Ideally ASAP.
+
* Discussion around forms, removing gadgets, etc.
+ * See below
+
+* Auto-scroll to last position during history navigation
+ * See below
+
+* The "What's Next?" of Javascript
+* URLdb/Cookies
+* Breaking changes and 4.x
Frontends
=========
+Amiga
+-----
+
+Chris Young still maintaining it. Do we want to add OS3 to the CI?
+
+> Keep '1st class'
+
+Atari
+-----
+
+No maintainer, toolchain is awkward, blobby, unpleasant for CI. Needs a
+scrub and refactor. We're not sure our builds are valid for Coldfire.
+
+> Demote '2nd class' (no CI builds) after 3.7
+
+BeOS
+----
+
+Intermittent maintenance. Haiku builder is a pain in the arse, is the only
+blocker for Java 8.
+
+> Keep `1st class` for now, consult with Pulkomandy and mmu_man about JDK-8
+
+Cocoa
+-----
+
+Currently 2nd class, Libraries only. Sven came back, but made a messy branch
+which was too hard to review/merge. Then he vanished once more. Is also a JDK
+8 limiting blocker, as it is 2nd class, we'd just drop from CI entirely if it
+was the only blocker.
+
+> Keep `2nd class` for now.
+
+Framebuffer
+-----------
+
+Currently 1st class, boring, needs keyboard shortcuts etc. Hotlist support,
+blahblahblah but frankly "just works™" for the most part (Raw linux framebuffer
+doesn't work, but that's `libnsfb` really)
+
+> Keep `1st class` for now.
+
+GTK
+---
+
+Currently 1st class, basically works, lacks keyboard shortcuts and polish in
+general.
+
+> Keep `1st class` for now.
+
+Monkey
+------
+
+Currently 1st class, doesn't tend to cause problems, needs further work for
+a test driver etc. No proper maintainer right now.
+
+> Keep `1st class` for now.
+
+RISC OS
+-------
+
+No maintainer, none of the core devs actually understand it any more, it's a
+pain in the arse. Sadly most of our feedback comes from RISC OS users. For
+now we do a best-effort on keeping it first class.
+
+> Keep `1st class` for now.
+
+Windows
+-------
+
+Minimally usable, but there are problems with XP (though do we care?) some
+issues around certificate bundles, storing of userdata, etc. Needs better
+configuration, translations, etc.
+
+> Keep `1st class` for now.
+
+Forms and gadgets
+=================
+
+The issues as we see them are that basically it's impossible to make small
+fixes because whenever something is changed, it goes horribly wrong somewhere
+else. Usually manifesting in double-frees or similar given the particularly
+baroque ownership semantics (or lack thereof).
+
+Rather than hacking it all out and starting from scratch, we propose:
+
+1. Making sure the gadgets update the DOM
+ * Gadget types: `HIDDEN`, `TEXTBOX`, `RADIO`, `CHECKBOX`, `SELECT`,
+ `TEXTAREA`, `IMAGE`, `PASSWORD`, `SUBMIT`, `RESET`, `FILE`, `BUTTON`
+ * It's likely `HIDDEN` can go away as soon as 2 is done.
+ * Validate that all these input kinds are supported in the libdom binding
+ * **TODO** Need to work out how to handle the reset event
+2. Making the form submission read from the DOM
+ * Turns out Daniel wrote that in 2014. Oops. Nothing to do here.
+3. Make the DOM trigger the submission (may need onclick or other event stuff)
+ * **TODO** First up read
+ <https://www.w3.org/TR/html5/forms.html#concept-fs-action> and implement
+ the form action, method, etc attributes onto the input element etc.
+ This may need libdom tweaks for the attributes and the novalidate stuff.
+ * **TODO** Rework the libdom submit stuff to use an internal event name
+ because the `submit` event is for non-`form.submit()` stuff:
+ <https://www.w3.org/TR/html5/forms.html#concept-form-submit>
+ * **TODO** Now determine how to implement the above bits neatly so that
+ we trigger submission properly.
+4. Make any reader of the gadgets use the DOM
+5. Work out how to remove more of this...
+
+History navigation scroll
+=========================
+
+Daniel suggests:
+
+1. Update `struct history_entry` to contain a `last_offset` as a float
+ which is the proportion of the page scrolled (initialised to zero during
+ `browser_window_history_add`
+2. On navigation, if current is not NULL, store the `last_offset` into it
+ (note in `browser_window_navigate`)
+3. On page completion, if the current history entry's `last_offset` is non-zero
+ then jump to that scroll location.
+
+Since we have fragment handling already (and navigating to a fragment will mean
+that the `last_offset` is zero) we will continue to function with fragments.
+
+
Next time
=========
-----------------------------------------------------------------------
Summary of changes:
developer-weekend/sep-2017.mdwn | 144 +++++++++++++++++++++++++++++++++++++++
1 file changed, 144 insertions(+)
diff --git a/developer-weekend/sep-2017.mdwn b/developer-weekend/sep-2017.mdwn
index 29c5d24..61403c0 100644
--- a/developer-weekend/sep-2017.mdwn
+++ b/developer-weekend/sep-2017.mdwn
@@ -62,11 +62,155 @@ Topics
*
[`#1879`](http://bugs.netsurf-browser.org/mantis/view.php?id=1879) (Resolved)
* [`#485`](http://bugs.netsurf-browser.org/mantis/view.php?id=485)
+* What frontends do we demote?
+ * See below
+
+* Administrivia - Phoenix's disks are tired (even SMART said so)
+ * We'd like to know where the society bank account stands, for general
+ resources.
+ * We'd like to buy a pair of WD Gold 1TB drives (rough cost 140 UKP total)
+ so that Phoenix isn't running on pre-fail age drives.
+ * Decision was: Michael, Vince, and Daniel will share the cost if the
+ society lacks the funds. Vince will buy drives and begin the replacement
+ process. Ideally ASAP.
+
* Discussion around forms, removing gadgets, etc.
+ * See below
+
+* Auto-scroll to last position during history navigation
+ * See below
+
+* The "What's Next?" of Javascript
+* URLdb/Cookies
+* Breaking changes and 4.x
Frontends
=========
+Amiga
+-----
+
+Chris Young still maintaining it. Do we want to add OS3 to the CI?
+
+> Keep '1st class'
+
+Atari
+-----
+
+No maintainer, toolchain is awkward, blobby, unpleasant for CI. Needs a
+scrub and refactor. We're not sure our builds are valid for Coldfire.
+
+> Demote '2nd class' (no CI builds) after 3.7
+
+BeOS
+----
+
+Intermittent maintenance. Haiku builder is a pain in the arse, is the only
+blocker for Java 8.
+
+> Keep `1st class` for now, consult with Pulkomandy and mmu_man about JDK-8
+
+Cocoa
+-----
+
+Currently 2nd class, Libraries only. Sven came back, but made a messy branch
+which was too hard to review/merge. Then he vanished once more. Is also a JDK
+8 limiting blocker, as it is 2nd class, we'd just drop from CI entirely if it
+was the only blocker.
+
+> Keep `2nd class` for now.
+
+Framebuffer
+-----------
+
+Currently 1st class, boring, needs keyboard shortcuts etc. Hotlist support,
+blahblahblah but frankly "just works™" for the most part (Raw linux framebuffer
+doesn't work, but that's `libnsfb` really)
+
+> Keep `1st class` for now.
+
+GTK
+---
+
+Currently 1st class, basically works, lacks keyboard shortcuts and polish in
+general.
+
+> Keep `1st class` for now.
+
+Monkey
+------
+
+Currently 1st class, doesn't tend to cause problems, needs further work for
+a test driver etc. No proper maintainer right now.
+
+> Keep `1st class` for now.
+
+RISC OS
+-------
+
+No maintainer, none of the core devs actually understand it any more, it's a
+pain in the arse. Sadly most of our feedback comes from RISC OS users. For
+now we do a best-effort on keeping it first class.
+
+> Keep `1st class` for now.
+
+Windows
+-------
+
+Minimally usable, but there are problems with XP (though do we care?) some
+issues around certificate bundles, storing of userdata, etc. Needs better
+configuration, translations, etc.
+
+> Keep `1st class` for now.
+
+Forms and gadgets
+=================
+
+The issues as we see them are that basically it's impossible to make small
+fixes because whenever something is changed, it goes horribly wrong somewhere
+else. Usually manifesting in double-frees or similar given the particularly
+baroque ownership semantics (or lack thereof).
+
+Rather than hacking it all out and starting from scratch, we propose:
+
+1. Making sure the gadgets update the DOM
+ * Gadget types: `HIDDEN`, `TEXTBOX`, `RADIO`, `CHECKBOX`, `SELECT`,
+ `TEXTAREA`, `IMAGE`, `PASSWORD`, `SUBMIT`, `RESET`, `FILE`, `BUTTON`
+ * It's likely `HIDDEN` can go away as soon as 2 is done.
+ * Validate that all these input kinds are supported in the libdom binding
+ * **TODO** Need to work out how to handle the reset event
+2. Making the form submission read from the DOM
+ * Turns out Daniel wrote that in 2014. Oops. Nothing to do here.
+3. Make the DOM trigger the submission (may need onclick or other event stuff)
+ * **TODO** First up read
+ <https://www.w3.org/TR/html5/forms.html#concept-fs-action> and implement
+ the form action, method, etc attributes onto the input element etc.
+ This may need libdom tweaks for the attributes and the novalidate stuff.
+ * **TODO** Rework the libdom submit stuff to use an internal event name
+ because the `submit` event is for non-`form.submit()` stuff:
+ <https://www.w3.org/TR/html5/forms.html#concept-form-submit>
+ * **TODO** Now determine how to implement the above bits neatly so that
+ we trigger submission properly.
+4. Make any reader of the gadgets use the DOM
+5. Work out how to remove more of this...
+
+History navigation scroll
+=========================
+
+Daniel suggests:
+
+1. Update `struct history_entry` to contain a `last_offset` as a float
+ which is the proportion of the page scrolled (initialised to zero during
+ `browser_window_history_add`
+2. On navigation, if current is not NULL, store the `last_offset` into it
+ (note in `browser_window_navigate`)
+3. On page completion, if the current history entry's `last_offset` is non-zero
+ then jump to that scroll location.
+
+Since we have fragment handling already (and navigating to a fragment will mean
+that the `last_offset` is zero) we will continue to function with fragments.
+
+
Next time
=========
--
NetSurf Developer Wiki Backing Store
_______________________________________________
netsurf-commits mailing list
[email protected]
http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/netsurf-commits-netsurf-browser.org
