4 ms·

Following ideas from both erlang and android, each gui screen within the application would be attached to a single process. When a new screen is opened the proc

by jamii 15y ago

Following ideas from both erlang and android, each gui screen within the application would be attached to a single process. When a new screen is opened the process is killed and a new process starts. If new code has been loaded the new process will switch.

masklinn 15y ago
Screenwise is not really a problem, you can just delete and reload the controls the next time the thing becomes visible. To get back to chrome, you could even swap the JS engine and DOM: leave the old one running in existing tabs, switch new or reloaded tabs to the new one, that's pretty much seamless. The issue I have is for the "static" chrome around the mobile parts: title bar, URL bar, that kind of stuff. There isn't much opportunity to switch that to a new process, I think. Especially if there are changes to make to the UI.
- bonzoesc 15y ago
  Fortunately, those don't actually need to be changed very often (no matter what the Chrome team says). As long as the rendering, JavaScript, and other parts that touch untrusted data stay up to date, you're probably fine with a URL bar that hasn't had today's unfashionable components removed.
  - masklinn 15y ago
    I did note that in my original comment, but you need to note the following: if the software never needs to be restarted, you will find somebody who never restarts it. The result is that sections of the code base may get out of sync, resulting in nonsensical behavior. 6 months from now, somebody will push code which does not work anymore with right now's awesomebar (or whatever), and the results may be minor or may lead to significant loss of state and information.
- abraham 15y ago
  Chrome already automatically adds/removes browserAction buttons for syncing on the fly. I don't see any reason Chrome couldn't wait to be inactive for 5 minutes and just change it. Most people would never notice the faint flicker.

by jamii 15y ago

masklinn 15y ago

Screenwise is not really a problem, you can just delete and reload the controls the next time the thing becomes visible. To get back to chrome, you could even swap the JS engine and DOM: leave the old one running in existing tabs, switch new or reloaded tabs to the new one, that's pretty much seamless. The issue I have is for the "static" chrome around the mobile parts: title bar, URL bar, that kind of stuff. There isn't much opportunity to switch that to a new process, I think. Especially if there are changes to make to the UI.

bonzoesc 15y ago
Fortunately, those don't actually need to be changed very often (no matter what the Chrome team says). As long as the rendering, JavaScript, and other parts that touch untrusted data stay up to date, you're probably fine with a URL bar that hasn't had today's unfashionable components removed.
- masklinn 15y ago
  I did note that in my original comment, but you need to note the following: if the software never needs to be restarted, you will find somebody who never restarts it. The result is that sections of the code base may get out of sync, resulting in nonsensical behavior. 6 months from now, somebody will push code which does not work anymore with right now's awesomebar (or whatever), and the results may be minor or may lead to significant loss of state and information.
abraham 15y ago
Chrome already automatically adds/removes browserAction buttons for syncing on the fly. I don't see any reason Chrome couldn't wait to be inactive for 5 minutes and just change it. Most people would never notice the faint flicker.