Re: [Vimprobable-users] [PATCH] Move apply_settings to webview_load_committed_cb.

[Daniel C. <dan...@gm...>]

Hi!
Hannes Schüller <ha...@yl...> wrote:
> Shorthand definitions:
> - state S1: default settings (as defined at compile time plus rc file)
> - state S2: site-specific settings for site X as defined in rc file
> - setting T1: a custom setting manually set by the user at runtime
>   which is not covered by the difference between S1 and S2 (i.e. the
>   site specific settings don't change this)
> - setting T2: a custom setting manually set by the user at runtime
>   which is covered by the difference between S1 and S2 (i.e. the
>   site specific settings change this)
>
> Case A:
> - start with S1
> - go to X -> get S2
> - go to another site -> get S1 back
>
> Case B:
> - start with S1
> - set T1 -> S1+T1
> - go to X -> S2+T1
> - go to another site -> S1+T1
>
> Case C:
> - start with S1
> - set T2 -> S1+T2
> - go to X -> S2 (T2 overwritten)
> - go to another site -> S1+T2 (T2 restored)
>
> Case D:
> - start with S1
> - go to X -> S2
> - set T1 -> S2+T1
> - go to another site -> S1+T1 (T1 survives)
>
> Case E:
> - start with S1
> - go to X -> S2
> - set T2 -> S2+T2
> - go to another site -> S1 (T2 overridden with respective setting from
>   S1)
>
> So if we're talking about user expectations, the only case I believe we
> could have a problem is E. Do you agree so far?

Thank you for structuring the issue.

For now it's only the case E we have to deal with, but there is at least a
possible behaviour that requires also a rethinking about the other cases.

I see two way to deal with the per-site-settings:

Thoungh in paradigm of object orientation we have the possibility to use
runtime settings as an third object in hirarchie 1. or as changes on setting
objects 2.


   default settings                   default settings
          ^                                  ^
          |                                  |
          |                                  |
   per-site-settings                  per-site-settings
          ^
          |
          |
   runtime settings



1. Like in current state. That means (case E), runtime settings done by the
   user may be overwritten by respective settings from S1. But we should not
   apply the settings S2 multiple times when the user navigates only on pages
   of X. I think we should change the current behaviour case E1 into case E2.

   Case E1 (current behaviour):
   - start with S1
   - go to X -> S2
   - set T2 -> S2+T2
   - go to another page on X -> S2
   - go to another site -> S1

   Case E2:
   - start with S1
   - go to X -> S2
   - set T2 -> S2+T2
   - go to another page on X -> S2+T2
   - go to another site -> S1

2. The setting scopes are treated as something like browser sessions. That
   means we have default settings, and per-site-settings that inherits from
   the default settings (overwrites respective settings). All runtime settings
   would be arranged into the current used setting.

   Case B':
   - start with S1
   - set T1 -> S1+T1
   - go to X -> S2+T1
   - go to another site -> S1+T1
   
   Case C':
   - start with S1
   - set T2 -> S1+T2
   - go to X -> S2 (T2 overwritten)
   - go to another site -> S1
   
   Case D':
   - start with S1
   - go to X -> S2
   - set T1 -> S2+T1
   - go to another site -> S1+T1 (T1 survives)
   
   Case E':
   - start with S1
   - go to X -> S2
   - set T2 -> S2+T2
   - go to another site -> S1
   - go to X -> S2+T2 (T2 was changed for the current window for site X)

I can live with both ways, but 2. would be more intuitive for me to
understand.

Daniel