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
@@ -26,9 +26,10 @@ Topics
* gtk download window
-### 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
kinnison described five things that needed to be done:
@@ -92,16 +96,46 @@ be able to improve matters with the new layout engine.)
-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
-* 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
+* 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.