Gitweb links:
...log
http://git.netsurf-browser.org/netsurf-wiki.git/shortlog/510de7d6d33e8e21c74c54d5aa738e8d932440b1
...commit
http://git.netsurf-browser.org/netsurf-wiki.git/commit/510de7d6d33e8e21c74c54d5aa738e8d932440b1
...tree
http://git.netsurf-browser.org/netsurf-wiki.git/tree/510de7d6d33e8e21c74c54d5aa738e8d932440b1
The branch, master has been updated
via 510de7d6d33e8e21c74c54d5aa738e8d932440b1 (commit)
from 5da68c33af7045d6002df56a8d049f97a7afada5 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commitdiff
http://git.netsurf-browser.org/netsurf-wiki.git/commit/?id=510de7d6d33e8e21c74c54d5aa738e8d932440b1
commit 510de7d6d33e8e21c74c54d5aa738e8d932440b1
Author: Daniel Silverstone <[email protected]>
Commit: Daniel Silverstone <[email protected]>
Notes from download discussion, and slight cleanups
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
-----------------------------------------------------------------------
Summary of changes:
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
--
NetSurf Developer Wiki Backing Store
_______________________________________________
netsurf-commits mailing list
[email protected]
http://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/netsurf-commits-netsurf-browser.org
