Minor Bugs in PreferenceWizardMorph

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Minor Bugs in PreferenceWizardMorph

Christoph Thiede

Hi all,

as requested, I did some testing with the PreferenceWizardMorph. I did not find any critical bugs, and it really looks stylish, but there are some minor defects I wanted to share with you:

Preferences section:
  • Page 2: Toggling "simple edit indication" does not change the appearance of browser's code pane before you type again into it.
    (Maybe the preference should redraw the full world or so?)
  • Page 3: Toggling "bigger fonts" does not affect the appearance of the PWM (PreferenceWizardMorph) itself.
    (Maybe it should implement #applyUserInterfaceTheme?)
  • In general: If you open another window (e. g. via halo) and close it, the "welcome help browser" is displayed focused, but it does not accept any inputs. Instead, the PWM should be displayed in foreground.
    (I think the problem is that SystemWindow class >> #noteTopWindowIn: only works with SystemWindows. I face similar problems with the WindowAcrobatics exposé.
    This implementation looks not very nice at all, it hard-codes the edge case of project windows ... Maybe we should move this responsibility to RealEstateAgent after the 5.3 release?)

Installation section:
  • Maybe the contents should be centered vertically?


Best,

Christoph



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: Minor Bugs in PreferenceWizardMorph

marcel.taeumel
Toggling "bigger fonts" does not affect the appearance of the PWM (PreferenceWizardMorph) itself.

That's intended. The wizard should be totally decoupled from what UI themes do. It has it's own "meta ui theme"  *__*

Toggling "simple edit indication" does not change the appearance of browser's code pane before you type again into it.

Seems to be a bug in PluggableTextMorph. There is another one with the help text in the world's search bar in the upper right corner.

If you open another window (e. g. via halo) and close it ...

That wizard has no support for extensively working with those preview windows, yet. ;-) No need to hack into the top-window concept just for the wizard. How likely do you think is that new users will trigger that issue?

Maybe the contents should be centered vertically?

No, since new bars can appear and disappear very quickly. So the upper ones would jump up and down and wouldn't be legible anymore. Top-center is more stable.

Best,
Marcel

Am 21.12.2019 15:08:52 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

as requested, I did some testing with the PreferenceWizardMorph. I did not find any critical bugs, and it really looks stylish, but there are some minor defects I wanted to share with you:

Preferences section:
  • Page 2: Toggling "simple edit indication" does not change the appearance of browser's code pane before you type again into it.
    (Maybe the preference should redraw the full world or so?)
  • Page 3: Toggling "bigger fonts" does not affect the appearance of the PWM (PreferenceWizardMorph) itself.
    (Maybe it should implement #applyUserInterfaceTheme?)
  • In general: If you open another window (e. g. via halo) and close it, the "welcome help browser" is displayed focused, but it does not accept any inputs. Instead, the PWM should be displayed in foreground.
    (I think the problem is that SystemWindow class >> #noteTopWindowIn: only works with SystemWindows. I face similar problems with the WindowAcrobatics exposé.
    This implementation looks not very nice at all, it hard-codes the edge case of project windows ... Maybe we should move this responsibility to RealEstateAgent after the 5.3 release?)

Installation section:
  • Maybe the contents should be centered vertically?


Best,

Christoph



Reply | Threaded
Open this post in threaded view
|

Re: Minor Bugs in PreferenceWizardMorph

Christoph Thiede

That's intended. The wizard should be totally decoupled from what UI themes do. It has it's own "meta ui theme"  *__*


I see, but in case of a hi-DPI system, all the text is much too small, anyway :)

No need to hack into the top-window concept just for the wizard. How likely do you think is that new users will trigger that issue?

Of course, don't hack just for the wizard! But with respect to WindowAcrobatics, I think it would not be that bad to extend this concept in order not to force a specific class (SystemWindow). I have already made some changes for this purpose in my working copy, maybe I can commit it soon™ :)

Best,
Christoph


Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Sonntag, 22. Dezember 2019 15:16:22
An: John Pfersich via Squeak-dev
Betreff: Re: [squeak-dev] Minor Bugs in PreferenceWizardMorph
 
Toggling "bigger fonts" does not affect the appearance of the PWM (PreferenceWizardMorph) itself.

That's intended. The wizard should be totally decoupled from what UI themes do. It has it's own "meta ui theme"  *__*

Toggling "simple edit indication" does not change the appearance of browser's code pane before you type again into it.

Seems to be a bug in PluggableTextMorph. There is another one with the help text in the world's search bar in the upper right corner.

If you open another window (e. g. via halo) and close it ...

That wizard has no support for extensively working with those preview windows, yet. ;-) No need to hack into the top-window concept just for the wizard. How likely do you think is that new users will trigger that issue?

Maybe the contents should be centered vertically?

No, since new bars can appear and disappear very quickly. So the upper ones would jump up and down and wouldn't be legible anymore. Top-center is more stable.

Best,
Marcel

Am 21.12.2019 15:08:52 schrieb Thiede, Christoph <[hidden email]>:

Hi all,

as requested, I did some testing with the PreferenceWizardMorph. I did not find any critical bugs, and it really looks stylish, but there are some minor defects I wanted to share with you:

Preferences section:
  • Page 2: Toggling "simple edit indication" does not change the appearance of browser's code pane before you type again into it.
    (Maybe the preference should redraw the full world or so?)
  • Page 3: Toggling "bigger fonts" does not affect the appearance of the PWM (PreferenceWizardMorph) itself.
    (Maybe it should implement #applyUserInterfaceTheme?)
  • In general: If you open another window (e. g. via halo) and close it, the "welcome help browser" is displayed focused, but it does not accept any inputs. Instead, the PWM should be displayed in foreground.
    (I think the problem is that SystemWindow class >> #noteTopWindowIn: only works with SystemWindows. I face similar problems with the WindowAcrobatics exposé.
    This implementation looks not very nice at all, it hard-codes the edge case of project windows ... Maybe we should move this responsibility to RealEstateAgent after the 5.3 release?)

Installation section:
  • Maybe the contents should be centered vertically?


Best,

Christoph



Carpe Squeak!