|author||Michael Drake <email@example.com>||2018-11-03 10:26:55 +0000|
|committer||Michael Drake <firstname.lastname@example.org>||2018-11-03 10:26:55 +0000|
Nov 2018 dev weekend: Corewindow / browser window plans.
Diffstat (limited to 'developer-weekend')
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
@@ -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
* 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.
+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
+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.)