diff options
Diffstat (limited to 'developer-weekend')
| -rw-r--r-- | developer-weekend/sep-2017.mdwn | 144 |
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 ========= |