From 510de7d6d33e8e21c74c54d5aa738e8d932440b1 Mon Sep 17 00:00:00 2001 From: Daniel Silverstone Date: Sat, 3 Nov 2018 11:08:27 +0000 Subject: Notes from download discussion, and slight cleanups --- developer-weekend/nov-2018.mdwn | 46 +++++++++++++++++++++++++++++++++++------ 1 file changed, 40 insertions(+), 6 deletions(-) diff --git a/developer-weekend/nov-2018.mdwn b/developer-weekend/nov-2018.mdwn index df96f27..45e4675 100644 --- a/developer-weekend/nov-2018.mdwn +++ b/developer-weekend/nov-2018.mdwn @@ -26,9 +26,10 @@ Topics * javascript console logging * gtk download window -## Monkey +Monkey +====== -### Vincents notes +## Vincents notes It would be useful if monkey could run complete page fetch tests automatically. @@ -51,7 +52,10 @@ Extra credit things * a coverage build * valgrind or similar to spot out of bounds memory accesses and leaks -### Discussion +Discussions +=========== + +## Monkey kinnison described five things that needed to be done: @@ -92,16 +96,46 @@ be able to improve matters with the new layout engine.) ## Javascript console -currently console output gets NSLOG under netsurf context at INFO which is a pile of pants. Daniel thinks js console should be property on browser window +Currently console output gets NSLOG under netsurf context at INFO which is a +both poor and unuseful. Daniel thinks that the JS console should be a property +on `browser_window`. -* window needs to propogate html content pointer into console object +* `Window` needs to propagate `html_content` pointer into `Console` object on + creation in `Window::console()`. * console should fire content message when logging * browser window should consume content message (bubbling as required) * browser window api extended to support reading and clearing console and injecting js commands to run subsequently add interface to frontends, possibly core window - +## GTK Download window + +Many egregious function pointer related issues were found when Michael compiled +with GCC 8. Vince wanted to point out that across all platforms, though GTK+ +especially, our handling of unknown mime types is very bad. + +The prevailing opinion is that behaviour ought to be more similar to firefox's +approach, with a corewindow for handling general UI in order that the effort +put in makes sense across all frontends. + +A possible API rework could be as follows: + +* Core says to frontend "Here, a handle to a fetch, and some metadata about it. + Whaddayouwant to do?" +* Frontend either *returns* "No idea mate. abort." or "Ok, I'll deal with that." +* In the second case, it can then present UI for "save or abort". +* If aborting, frontend hands the handle *and* metadata back to the core for it + to clean up. +* If saving, frontend calls a "OK, let's save this" handing the handle, + metadata and either an FD or filepath (to be decided) under which to save the + result. +* The "download" core window should have UI for "cancel" and "open location" + type things. Progress, etc. All the goodness. + +As an aside, it'd be handy to have a core->frontend call which allows the core +to get hold of a `bitmap` representing a particular mime type. This way the +download core window might display an appropriate icon, or we might be able to +replace empty favicons with an appropriate mime type image. Activity -- cgit v1.2.3