Notes from download discussion, and slight cleanups

1 files 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