Nov 2018 dev weekend: Corewindow / browser window plans.

1 files changed, 31 insertions, 1 deletions

diff --git a/developer-weekend/nov-2018.mdwn b/developer-weekend/nov-2018.mdwn
index ebb0250..2cda3a2 100644
--- a/developer-weekend/nov-2018.mdwn
+++ b/developer-weekend/nov-2018.mdwn
@@ -22,7 +22,7 @@ Topics
 
 * Make monkey actually run functional tests
 * Discuss ick CI system
-* corewindow for browser window chnage requirements
+* corewindow for browser window change requirements
 * javascript console logging
 * gtk download window
 
@@ -61,6 +61,36 @@ kinnison described five things that needed to be done:
 * test plan language/definitions
 * events from the core browser window to frontends
 
+
+### Corewindow for browser window change requirements
+
+Everything except browser window has been moved over to corewindow.
+
+The API is OK, but a little cumbersome to use, but it needs to flexible enough
+for lots of use cases.
+
+The main outstanding feature is that the browser window needs the front end
+to handle scaling at render time.  This isn't supported by core window.
+
+The reason for this is mostly due to HTML layout engine currently doing
+scale by resizing viewport available width according to scale, reflowing,
+and redrawing with the scale applied.  This was an optimisation to avoid
+needing to redo layout (measuring text) on scale changes.  But it doesn't
+really work except on the RISC OS font manager, where text size scales
+linearly with pt size.
+
+Plan:
+
+1. Sink scale into browser window, so gui_windows can only set and get scale.
+2. Restructure front ends to have correct separation of gui, browser and core
+   window.
+3. Move browser windows over to core window.
+
+So front ends will only know about scale for e.g. saying scale in the title
+bar.  All the complexity will move to browser_window.  (For now; we should
+be able to improve matters with the new layout engine.)
+
+
 Activity
 ========