Quantcast

Configuration dialogs redesign idea

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Configuration dialogs redesign idea

Leonard de Ruijter-4
Hello People,

In the light of the work which Reef put into guiHelper, I've been thinking about an additional way to improve the support for adding and modifying settings dialogs. This would also make it easier to come up with a nice solution for [#4892](4892), for example.

In the first place, this suggestion doesn't change anything visually or noticeable, it's just a matter of change of the underlying code. Therefore, I think this subject is one in the line of subjects Joseph started last week about source code restructuring. It is a nice way how the community can contribute to the NVDA project.

The basic idea is to create a new SettingsHelper class which particularly helps with associating a WX control with the underlying parameter in the configuration system. In the current situation, every setting involves at least two lines of code which facilitates retrieving and applying settings in the configuration system. Here is a short example:

        autoLanguageSwitchingText = _("Automatic language switching (when supported)")
        self.autoLanguageSwitchingCheckbox = settingsSizerHelper.addItem(wx.CheckBox(self,label=autoLanguageSwitchingText))
        self.autoLanguageSwitchingCheckbox.SetValue(config.conf["speech"]["autoLanguageSwitching"])

and in the onOk method:
        config.conf["speech"]["autoLanguageSwitching"]=self.autoLanguageSwitchingCheckbox.IsChecked()

When we have a settingsHelper style of approach, code would look like

autoLanguageSwitchingText = _("Automatic language switching (when supported)")
self.autoLanguageSwitching = settingsHelper(category="speech", parameter="autoLanguageSwitching", type="bool", label=autoLanguageSwitchingText, )

The settingsHelper should account for the way a control is displayed. For example, a bool setting should usually be a check box, a string type should be a combobox with predefined choices, integer should either be a check box or combo box. Obviously, this should be overridable. When keeping refferences to the settingsHelper instances, for example in a dictionary, it is or should just enough for the onOk method to loop over them in order to apply the settings.

In the long run, I think such a fundamental type of approach should allow to building at least basic configuration dialogs or setting controls just from the config spec in the config module. Especially for check boxes, the config spec and a label are probably enough information to automatically construct a check box control.
Another advantage would be that it will be much easier to port settings dialogs to another gui toolkit such as WX Phoenix or even QT (I heard that being mentioned somewhere).

Any thoughts on this? Please also let me know when you consider these ideas a big waste of time.

Kind regards,
Leonard

------------------------------------------------------------------------------

_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configuration dialogs redesign idea

derek riemer

you might raise a ticket about this or risk getting it lost in the archives.


On 11/30/2016 2:30 AM, Leonard de Ruijter wrote:
Hello People,

In the light of the work which Reef put into guiHelper, I've been thinking about an additional way to improve the support for adding and modifying settings dialogs. This would also make it easier to come up with a nice solution for [#4892](4892), for example.

In the first place, this suggestion doesn't change anything visually or noticeable, it's just a matter of change of the underlying code. Therefore, I think this subject is one in the line of subjects Joseph started last week about source code restructuring. It is a nice way how the community can contribute to the NVDA project.

The basic idea is to create a new SettingsHelper class which particularly helps with associating a WX control with the underlying parameter in the configuration system. In the current situation, every setting involves at least two lines of code which facilitates retrieving and applying settings in the configuration system. Here is a short example:

        autoLanguageSwitchingText = _("Automatic language switching (when supported)")
        self.autoLanguageSwitchingCheckbox = settingsSizerHelper.addItem(wx.CheckBox(self,label=autoLanguageSwitchingText))
        self.autoLanguageSwitchingCheckbox.SetValue(config.conf["speech"]["autoLanguageSwitching"])

and in the onOk method:
        config.conf["speech"]["autoLanguageSwitching"]=self.autoLanguageSwitchingCheckbox.IsChecked()

When we have a settingsHelper style of approach, code would look like

autoLanguageSwitchingText = _("Automatic language switching (when supported)")
self.autoLanguageSwitching = settingsHelper(category="speech", parameter="autoLanguageSwitching", type="bool", label=autoLanguageSwitchingText, )

The settingsHelper should account for the way a control is displayed. For example, a bool setting should usually be a check box, a string type should be a combobox with predefined choices, integer should either be a check box or combo box. Obviously, this should be overridable. When keeping refferences to the settingsHelper instances, for example in a dictionary, it is or should just enough for the onOk method to loop over them in order to apply the settings.

In the long run, I think such a fundamental type of approach should allow to building at least basic configuration dialogs or setting controls just from the config spec in the config module. Especially for check boxes, the config spec and a label are probably enough information to automatically construct a check box control.
Another advantage would be that it will be much easier to port settings dialogs to another gui toolkit such as WX Phoenix or even QT (I heard that being mentioned somewhere).

Any thoughts on this? Please also let me know when you consider these ideas a big waste of time.

Kind regards,
Leonard


------------------------------------------------------------------------------


_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel

--

Derek Riemer

  • Department of computer science, third year undergraduate student.
  • Proud user of the NVDA screen reader.
  • Open source enthusiast.
  • Member of Bridge Cu
  • Avid skiier.

Websites:
Honors portfolio
Awesome little hand built weather app!

[hidden email]
Phone: (303) 906-2194


------------------------------------------------------------------------------

_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configuration dialogs redesign idea

Leonard de Ruijter-4

I'd like to discuss this first on this list before I file a hopefully more complete ticket.


On 30-11-2016 10:43, derek riemer wrote:

you might raise a ticket about this or risk getting it lost in the archives.


On 11/30/2016 2:30 AM, Leonard de Ruijter wrote:
Hello People,

In the light of the work which Reef put into guiHelper, I've been thinking about an additional way to improve the support for adding and modifying settings dialogs. This would also make it easier to come up with a nice solution for [#4892](4892), for example.

In the first place, this suggestion doesn't change anything visually or noticeable, it's just a matter of change of the underlying code. Therefore, I think this subject is one in the line of subjects Joseph started last week about source code restructuring. It is a nice way how the community can contribute to the NVDA project.

The basic idea is to create a new SettingsHelper class which particularly helps with associating a WX control with the underlying parameter in the configuration system. In the current situation, every setting involves at least two lines of code which facilitates retrieving and applying settings in the configuration system. Here is a short example:

        autoLanguageSwitchingText = _("Automatic language switching (when supported)")
        self.autoLanguageSwitchingCheckbox = settingsSizerHelper.addItem(wx.CheckBox(self,label=autoLanguageSwitchingText))
        self.autoLanguageSwitchingCheckbox.SetValue(config.conf["speech"]["autoLanguageSwitching"])

and in the onOk method:
        config.conf["speech"]["autoLanguageSwitching"]=self.autoLanguageSwitchingCheckbox.IsChecked()

When we have a settingsHelper style of approach, code would look like

autoLanguageSwitchingText = _("Automatic language switching (when supported)")
self.autoLanguageSwitching = settingsHelper(category="speech", parameter="autoLanguageSwitching", type="bool", label=autoLanguageSwitchingText, )

The settingsHelper should account for the way a control is displayed. For example, a bool setting should usually be a check box, a string type should be a combobox with predefined choices, integer should either be a check box or combo box. Obviously, this should be overridable. When keeping refferences to the settingsHelper instances, for example in a dictionary, it is or should just enough for the onOk method to loop over them in order to apply the settings.

In the long run, I think such a fundamental type of approach should allow to building at least basic configuration dialogs or setting controls just from the config spec in the config module. Especially for check boxes, the config spec and a label are probably enough information to automatically construct a check box control.
Another advantage would be that it will be much easier to port settings dialogs to another gui toolkit such as WX Phoenix or even QT (I heard that being mentioned somewhere).

Any thoughts on this? Please also let me know when you consider these ideas a big waste of time.

Kind regards,
Leonard


------------------------------------------------------------------------------


_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel

--

Derek Riemer

  • Department of computer science, third year undergraduate student.
  • Proud user of the NVDA screen reader.
  • Open source enthusiast.
  • Member of Bridge Cu
  • Avid skiier.

Websites:
Honors portfolio
Awesome little hand built weather app!

[hidden email]
Phone: (303) 906-2194



------------------------------------------------------------------------------


_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel


------------------------------------------------------------------------------

_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configuration dialogs redesign idea

derek riemer

Sure. Just reminding :-)

I certainly like the idea.


On 11/30/2016 2:50 AM, Leonard de Ruijter wrote:

I'd like to discuss this first on this list before I file a hopefully more complete ticket.


On 30-11-2016 10:43, derek riemer wrote:

you might raise a ticket about this or risk getting it lost in the archives.


On 11/30/2016 2:30 AM, Leonard de Ruijter wrote:
Hello People,

In the light of the work which Reef put into guiHelper, I've been thinking about an additional way to improve the support for adding and modifying settings dialogs. This would also make it easier to come up with a nice solution for [#4892](4892), for example.

In the first place, this suggestion doesn't change anything visually or noticeable, it's just a matter of change of the underlying code. Therefore, I think this subject is one in the line of subjects Joseph started last week about source code restructuring. It is a nice way how the community can contribute to the NVDA project.

The basic idea is to create a new SettingsHelper class which particularly helps with associating a WX control with the underlying parameter in the configuration system. In the current situation, every setting involves at least two lines of code which facilitates retrieving and applying settings in the configuration system. Here is a short example:

        autoLanguageSwitchingText = _("Automatic language switching (when supported)")
        self.autoLanguageSwitchingCheckbox = settingsSizerHelper.addItem(wx.CheckBox(self,label=autoLanguageSwitchingText))
        self.autoLanguageSwitchingCheckbox.SetValue(config.conf["speech"]["autoLanguageSwitching"])

and in the onOk method:
        config.conf["speech"]["autoLanguageSwitching"]=self.autoLanguageSwitchingCheckbox.IsChecked()

When we have a settingsHelper style of approach, code would look like

autoLanguageSwitchingText = _("Automatic language switching (when supported)")
self.autoLanguageSwitching = settingsHelper(category="speech", parameter="autoLanguageSwitching", type="bool", label=autoLanguageSwitchingText, )

The settingsHelper should account for the way a control is displayed. For example, a bool setting should usually be a check box, a string type should be a combobox with predefined choices, integer should either be a check box or combo box. Obviously, this should be overridable. When keeping refferences to the settingsHelper instances, for example in a dictionary, it is or should just enough for the onOk method to loop over them in order to apply the settings.

In the long run, I think such a fundamental type of approach should allow to building at least basic configuration dialogs or setting controls just from the config spec in the config module. Especially for check boxes, the config spec and a label are probably enough information to automatically construct a check box control.
Another advantage would be that it will be much easier to port settings dialogs to another gui toolkit such as WX Phoenix or even QT (I heard that being mentioned somewhere).

Any thoughts on this? Please also let me know when you consider these ideas a big waste of time.

Kind regards,
Leonard


------------------------------------------------------------------------------


_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel

--

Derek Riemer

  • Department of computer science, third year undergraduate student.
  • Proud user of the NVDA screen reader.
  • Open source enthusiast.
  • Member of Bridge Cu
  • Avid skiier.

Websites:
Honors portfolio
Awesome little hand built weather app!

[hidden email]
Phone: (303) 906-2194



------------------------------------------------------------------------------


_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel



------------------------------------------------------------------------------


_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel

--

Derek Riemer

  • Department of computer science, third year undergraduate student.
  • Proud user of the NVDA screen reader.
  • Open source enthusiast.
  • Member of Bridge Cu
  • Avid skiier.

Websites:
Honors portfolio
Awesome little hand built weather app!

[hidden email]
Phone: (303) 906-2194


------------------------------------------------------------------------------

_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configuration dialogs redesign idea

Joseph Lee
In reply to this post by Leonard de Ruijter-4

Hi,

Not all strings can turn into combo boxes, nor integers to checkboxes. There are add-ons out there that uses text fields for strings, including Clip Contents Designer and others.

Also, specifying categories assumes that it’ll be a multi-level config dictionary, whereas some older add-ons still rely on single-level dictionaries for configuration storage.

Lastly, regarding porting and what not: the best way to port stuff is making the portable code truly portable. In my opinion, it would be best to prepare the back-end to handle toolkits rather than the front-end so NVDA can be portable across GUI libraries, and this will take time (at least a year to implement and adopt).

Regarding my proposal: I didn’t say “source code restructuring” – I said source code cleanup, which is completely different than restructured source code. A cleanup item would be things such as adding headers to modules where it is missing and so on (I’m thinking of hosting a Skype call or something where a group of developers can sit down, go through the source code and plan our work).

Sorry if I sounded harsh.

Cheers,

Joseph

 

From: Leonard de Ruijter [mailto:[hidden email]]
Sent: Wednesday, November 30, 2016 1:30 AM
To: [hidden email]
Subject: [Nvda-devel] Configuration dialogs redesign idea

 

Hello People,

In the light of the work which Reef put into guiHelper, I've been thinking about an additional way to improve the support for adding and modifying settings dialogs. This would also make it easier to come up with a nice solution for [#4892](4892), for example.

In the first place, this suggestion doesn't change anything visually or noticeable, it's just a matter of change of the underlying code. Therefore, I think this subject is one in the line of subjects Joseph started last week about source code restructuring. It is a nice way how the community can contribute to the NVDA project.

The basic idea is to create a new SettingsHelper class which particularly helps with associating a WX control with the underlying parameter in the configuration system. In the current situation, every setting involves at least two lines of code which facilitates retrieving and applying settings in the configuration system. Here is a short example:

        autoLanguageSwitchingText = _("Automatic language switching (when supported)")
        self.autoLanguageSwitchingCheckbox = settingsSizerHelper.addItem(wx.CheckBox(self,label=autoLanguageSwitchingText))
        self.autoLanguageSwitchingCheckbox.SetValue(config.conf["speech"]["autoLanguageSwitching"])

and in the onOk method:
        config.conf["speech"]["autoLanguageSwitching"]=self.autoLanguageSwitchingCheckbox.IsChecked()

When we have a settingsHelper style of approach, code would look like

autoLanguageSwitchingText = _("Automatic language switching (when supported)")
self.autoLanguageSwitching = settingsHelper(category="speech", parameter="autoLanguageSwitching", type="bool", label=autoLanguageSwitchingText, )

The settingsHelper should account for the way a control is displayed. For example, a bool setting should usually be a check box, a string type should be a combobox with predefined choices, integer should either be a check box or combo box. Obviously, this should be overridable. When keeping refferences to the settingsHelper instances, for example in a dictionary, it is or should just enough for the onOk method to loop over them in order to apply the settings.

In the long run, I think such a fundamental type of approach should allow to building at least basic configuration dialogs or setting controls just from the config spec in the config module. Especially for check boxes, the config spec and a label are probably enough information to automatically construct a check box control.
Another advantage would be that it will be much easier to port settings dialogs to another gui toolkit such as WX Phoenix or even QT (I heard that being mentioned somewhere).

Any thoughts on this? Please also let me know when you consider these ideas a big waste of time.

Kind regards,
Leonard


------------------------------------------------------------------------------

_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configuration dialogs redesign idea

corentin
In reply to this post by Leonard de Ruijter-4
Bonjour,

j'ai changé d'adresse mail, merci de me contacter sur :
[hidden email]

Corentin.



------------------------------------------------------------------------------
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configuration dialogs redesign idea

derek riemer
In reply to this post by Joseph Lee


Hi:
On 11/30/2016 7:37 AM, Joseph Lee wrote:

Hi,

Not all strings can turn into combo boxes, nor integers to checkboxes. There are add-ons out there that uses text fields for strings, including Clip Contents Designer and others.

While not all strings can, many, many can. Killing 599 birds with one stone when there are actually 600 birds is highly productive rather than killing 600 individual birds with 600 stones.

Also, specifying categories assumes that it’ll be a multi-level config dictionary, whereas some older add-ons still rely on single-level dictionaries for configuration storage.

They don't have to use this I.E. doing it the old way still will work.

Lastly, regarding porting and what not: the best way to port stuff is making the portable code truly portable. In my opinion, it would be best to prepare the back-end to handle toolkits rather than the front-end so NVDA can be portable across GUI libraries, and this will take time (at least a year to implement and adopt).

Don't follow.
1. How does this make it less portable? It uses an NVDA helper, which will probably work with other GUI libraries.
2. Don't follow. Why so long, and what's the repoint of doing this?

Regarding my proposal: I didn’t say “source code restructuring” – I said source code cleanup, which is completely different than restructured source code. A cleanup item would be things such as adding headers to modules where it is missing and so on (I’m thinking of hosting a Skype call or something where a group of developers can sit down, go through the source code and plan our work).

This isn't productive. This stuff matters little compared to just fixing it when working on the actual things that matter like bug fixes and new features I.E. fix indents or add headers when working on a ticket that has to do with something different. I feel that this is trivial, and really a meeting for this is overkilling overkill.

Sorry if I sounded harsh.

Not at all.

Cheers,

Joseph

 

From: Leonard de Ruijter [[hidden email]]
Sent: Wednesday, November 30, 2016 1:30 AM
To: [hidden email]
Subject: [Nvda-devel] Configuration dialogs redesign idea

 

Hello People,

In the light of the work which Reef put into guiHelper, I've been thinking about an additional way to improve the support for adding and modifying settings dialogs. This would also make it easier to come up with a nice solution for [#4892](4892), for example.

In the first place, this suggestion doesn't change anything visually or noticeable, it's just a matter of change of the underlying code. Therefore, I think this subject is one in the line of subjects Joseph started last week about source code restructuring. It is a nice way how the community can contribute to the NVDA project.

The basic idea is to create a new SettingsHelper class which particularly helps with associating a WX control with the underlying parameter in the configuration system. In the current situation, every setting involves at least two lines of code which facilitates retrieving and applying settings in the configuration system. Here is a short example:

        autoLanguageSwitchingText = _("Automatic language switching (when supported)")
        self.autoLanguageSwitchingCheckbox = settingsSizerHelper.addItem(wx.CheckBox(self,label=autoLanguageSwitchingText))
        self.autoLanguageSwitchingCheckbox.SetValue(config.conf["speech"]["autoLanguageSwitching"])

and in the onOk method:
        config.conf["speech"]["autoLanguageSwitching"]=self.autoLanguageSwitchingCheckbox.IsChecked()

When we have a settingsHelper style of approach, code would look like

autoLanguageSwitchingText = _("Automatic language switching (when supported)")
self.autoLanguageSwitching = settingsHelper(category="speech", parameter="autoLanguageSwitching", type="bool", label=autoLanguageSwitchingText, )

The settingsHelper should account for the way a control is displayed. For example, a bool setting should usually be a check box, a string type should be a combobox with predefined choices, integer should either be a check box or combo box. Obviously, this should be overridable. When keeping refferences to the settingsHelper instances, for example in a dictionary, it is or should just enough for the onOk method to loop over them in order to apply the settings.

In the long run, I think such a fundamental type of approach should allow to building at least basic configuration dialogs or setting controls just from the config spec in the config module. Especially for check boxes, the config spec and a label are probably enough information to automatically construct a check box control.
Another advantage would be that it will be much easier to port settings dialogs to another gui toolkit such as WX Phoenix or even QT (I heard that being mentioned somewhere).

Any thoughts on this? Please also let me know when you consider these ideas a big waste of time.

Kind regards,
Leonard



------------------------------------------------------------------------------


_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel

--

Derek Riemer

  • Department of computer science, third year undergraduate student.
  • Proud user of the NVDA screen reader.
  • Open source enthusiast.
  • Member of Bridge Cu
  • Avid skiier.

Websites:
Honors portfolio
Awesome little hand built weather app!

[hidden email]
Phone: (303) 906-2194


------------------------------------------------------------------------------

_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configuration dialogs redesign idea

Reef Turner
Hi everyone,

Here are my thoughts:

Simplifying the bindings between controls and config could be
beneficial. Keep in mind this might be a more complex problem than you
imagine. There are plenty of edge cases. I'm also not convinced this
brings that much value. One argument might be simplicity for new
developers, however often for new developers explicit is better than
implicit. Having to hunt around in some framework in order to
understand how your UI value will or wont end up in the config is much
more time consuming than having to type out a few lines, especially
when there are plenty of quite consistent examples to look at.

In terms of generating UI from config, I would be cautious about
introducing such direct coupling. There isn't a one to one mapping of
config and UI and I don't think there should be. Having an 'in
between' layer provides a mapping which helps with flexibility of the
design of both the config and the UI. A good example of this is the
MVVM pattern. Generating the UI in this way is also likely to have
many edge cases. Some of these are interdependent config options, and
config value types that are best represented in the UI in different
ways. This could also make it much harder to have intuitive UI. At the
moment different layouts and hierarchies of presentation are
considered. It would be much harder to have this control over the
design. It seems to me that it would be necessary to have quite a few
exceptions to the "generated UI from config" rule. This leads to
inconsistencies in the code, making it harder to understand.

Regards,
Reef Turner

On Wed, Nov 30, 2016 at 10:56 PM, derek riemer <[hidden email]> wrote:

>
> Hi:
> On 11/30/2016 7:37 AM, Joseph Lee wrote:
>
> Hi,
>
> Not all strings can turn into combo boxes, nor integers to checkboxes. There
> are add-ons out there that uses text fields for strings, including Clip
> Contents Designer and others.
>
> While not all strings can, many, many can. Killing 599 birds with one stone
> when there are actually 600 birds is highly productive rather than killing
> 600 individual birds with 600 stones.
>
> Also, specifying categories assumes that it’ll be a multi-level config
> dictionary, whereas some older add-ons still rely on single-level
> dictionaries for configuration storage.
>
> They don't have to use this I.E. doing it the old way still will work.
>
> Lastly, regarding porting and what not: the best way to port stuff is making
> the portable code truly portable. In my opinion, it would be best to prepare
> the back-end to handle toolkits rather than the front-end so NVDA can be
> portable across GUI libraries, and this will take time (at least a year to
> implement and adopt).
>
> Don't follow.
> 1. How does this make it less portable? It uses an NVDA helper, which will
> probably work with other GUI libraries.
> 2. Don't follow. Why so long, and what's the repoint of doing this?
>
> Regarding my proposal: I didn’t say “source code restructuring” – I said
> source code cleanup, which is completely different than restructured source
> code. A cleanup item would be things such as adding headers to modules where
> it is missing and so on (I’m thinking of hosting a Skype call or something
> where a group of developers can sit down, go through the source code and
> plan our work).
>
> This isn't productive. This stuff matters little compared to just fixing it
> when working on the actual things that matter like bug fixes and new
> features I.E. fix indents or add headers when working on a ticket that has
> to do with something different. I feel that this is trivial, and really a
> meeting for this is overkilling overkill.
>
> Sorry if I sounded harsh.
>
> Not at all.
>
> Cheers,
>
> Joseph
>
>
>
> From: Leonard de Ruijter [mailto:[hidden email]]
> Sent: Wednesday, November 30, 2016 1:30 AM
> To: [hidden email]
> Subject: [Nvda-devel] Configuration dialogs redesign idea
>
>
>
> Hello People,
>
> In the light of the work which Reef put into guiHelper, I've been thinking
> about an additional way to improve the support for adding and modifying
> settings dialogs. This would also make it easier to come up with a nice
> solution for [#4892](4892), for example.
>
> In the first place, this suggestion doesn't change anything visually or
> noticeable, it's just a matter of change of the underlying code. Therefore,
> I think this subject is one in the line of subjects Joseph started last week
> about source code restructuring. It is a nice way how the community can
> contribute to the NVDA project.
>
> The basic idea is to create a new SettingsHelper class which particularly
> helps with associating a WX control with the underlying parameter in the
> configuration system. In the current situation, every setting involves at
> least two lines of code which facilitates retrieving and applying settings
> in the configuration system. Here is a short example:
>
>         autoLanguageSwitchingText = _("Automatic language switching (when
> supported)")
>         self.autoLanguageSwitchingCheckbox =
> settingsSizerHelper.addItem(wx.CheckBox(self,label=autoLanguageSwitchingText))
>
> self.autoLanguageSwitchingCheckbox.SetValue(config.conf["speech"]["autoLanguageSwitching"])
>
> and in the onOk method:
>
> config.conf["speech"]["autoLanguageSwitching"]=self.autoLanguageSwitchingCheckbox.IsChecked()
>
> When we have a settingsHelper style of approach, code would look like
>
> autoLanguageSwitchingText = _("Automatic language switching (when
> supported)")
> self.autoLanguageSwitching = settingsHelper(category="speech",
> parameter="autoLanguageSwitching", type="bool",
> label=autoLanguageSwitchingText, )
>
> The settingsHelper should account for the way a control is displayed. For
> example, a bool setting should usually be a check box, a string type should
> be a combobox with predefined choices, integer should either be a check box
> or combo box. Obviously, this should be overridable. When keeping
> refferences to the settingsHelper instances, for example in a dictionary, it
> is or should just enough for the onOk method to loop over them in order to
> apply the settings.
>
> In the long run, I think such a fundamental type of approach should allow to
> building at least basic configuration dialogs or setting controls just from
> the config spec in the config module. Especially for check boxes, the config
> spec and a label are probably enough information to automatically construct
> a check box control.
> Another advantage would be that it will be much easier to port settings
> dialogs to another gui toolkit such as WX Phoenix or even QT (I heard that
> being mentioned somewhere).
>
> Any thoughts on this? Please also let me know when you consider these ideas
> a big waste of time.
>
> Kind regards,
> Leonard
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>
>
> --
> ________________________________
>
> Derek Riemer
>
> Department of computer science, third year undergraduate student.
> Proud user of the NVDA screen reader.
> Open source enthusiast.
> Member of Bridge Cu
> Avid skiier.
>
> Websites:
> Honors portfolio
> Awesome little hand built weather app!
>
> email me at [hidden email]
> Phone: (303) 906-2194
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Nvda-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/nvda-devel
>



--
Regards,
Reef Turner

------------------------------------------------------------------------------
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Configuration dialogs redesign idea

corentin
In reply to this post by Leonard de Ruijter-4
Bonjour,

j'ai changé d'adresse mail, merci de me contacter sur :
[hidden email]

Corentin.



------------------------------------------------------------------------------
_______________________________________________
Nvda-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nvda-devel
Loading...