summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDaniel Silverstone <dsilvers@digital-scurf.org>2017-09-09 17:25:24 (GMT)
committer Daniel Silverstone <dsilvers@digital-scurf.org>2017-09-09 17:25:24 (GMT)
commit9a2ca4abf4aab7e74b8cba27675e0df387ab49c7 (patch)
tree8f8e4229e1322132fa270f7b564e85bfd187961b
parente7c307f78a74b7d8360ff5a5302a5de91a20d047 (diff)
downloadnetsurf-wiki-9a2ca4abf4aab7e74b8cba27675e0df387ab49c7.tar.gz
netsurf-wiki-9a2ca4abf4aab7e74b8cba27675e0df387ab49c7.tar.bz2
So many notes
-rw-r--r--developer-weekend/sep-2017.mdwn144
1 files changed, 144 insertions, 0 deletions
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
=========