make the (Beep for capitals check box) and (Say cap before capitals check boxes) in to a single combo box instead of 2 check boxes

[amirmahdifard]

Is your feature request related to a problem? Please describe.

so these 2 check boxes say cap before capital leters and beep for capital leters, you can check both of them, or you can check one of them, or you can don't check any of them: so in light of this way, please just make a combo box, and the title of that combo box could bee something like, capital leter announcement output combo box or something: and it can have the folowing options in them: say cap before capital leters, beep for capital leters, both say cap and beep for capital leters, off: then in this kace, you can turn these 2 check boxes to a single combo box with out any problem, because the users can do anything as how as they want with this combo box, as they did with those 2 check boxes.

Describe the solution you'd like

please replace these 2 check boxes with a single combo box contaning all these options.

Describe alternatives you've considered

alternatively, we can configger this with those check boxes, but as much as i'm thinking about it, it is bettar to be replaced with a single combo box that contanes all those options in it.

Additional context

i think there will be no problem with doing this, because in the combo box, stil if the users want too, they can set it to both, or set it to any of them, or set it to off, as they did with the check boxes: i feal this kace is more meaningfull to be a single combo box than 2 difrent check boxes since NVDA is moste of the times makes combo boxes in settings for such options where you can configger something in more than one way: hope you can read this and understand my point, and hope that i can manage to submit my first request that has been developed in NVDA project.

[amirmahdifard]

@josephsl hi: i know i mentioned you in my tikits, and answered me and told me if it is not possible to develop something: can you please check this tikit, i thinked so much before opening this tikit to make sure that doing this request is not gonna breake that option, and then finally i opened it: can you please check, and if possible, can you please open a pull request to do this? thank you so much for answering me!

[josephsl]

Hi,

This idea sounds interesting. However, I must caution that this will break add-ons relying on configuration values for these settings (CC @CyrilleB79 for some thoughts).

Thanks.

[CyrilleB79]

Hello

Here is my feedback about this request:

Technically, there is no problem to implement this change. As @josephsl wrote, implementing this would require an upgrade in the config (to avoid bugs such as #14170) with a potential impact on add-ons. Thus, if this is implemented, it should be merged in an API-breaking 20xx.1 release.

But I have not heard of anyone having trouble to understand the GUI with these options separated. @amirmahdifard have you had difficulty understanding all the settings related to caps reporting in the GUI? Or is your proposal just to make the graphical interface nicer?

In NVDA, there are 3 options related to caps reporting:

• Capital pitch change percentage
• Say cap before capitals
• Beep for capitals

If the last two options are combined in a combobox, the first one will remain separated in any case. So the goal to have the graphical interface nicer and to have caps reporting controlled by only one option will not be totally reached.

To conclude, my personal opinion is there is almost no benefit implementing this. However, if the community and NVAccess have a different opinion than I, as written before, there is no difficulty to implement it.

[amirmahdifard]

@josephsl @CyrilleB79 hello, and thank you for your interesting for adding this ability, and thank you for answering and doing the conversation about this idea: i will answer you in the below lines. 1: about the 3 options for capital, and the grafic become nicer: to answer your question, no, i don't have problem to understanding those check boxes, i just like it if we have 2 options in there rather than 3 options: 1 combo box, and 1 edit selection box for capital persentage option: i actually like it this way, because in the combo box, you can configger that how you would like NVDA to announce the capital leters for you: and that edit selection box to select the pich of announcing capital leters, and another point wich you mentioned, that the UI will become nicer, as whell as NVDA would normally make a combo box for those options wich you are able to configger them with more than only one way to avoid making unlimited check boxes LOL: and also, i've considered of a new and useful point to do this too! you can add a toggel shortcut for this combo box, so that people can change it quickly with out opening the NVDA settings: if you don't know wich kind of toggel shortcut i'm talking about, some examples is pressing NVDA + u to configger the progress barr output combo box wich is located in the settings> object presentation, or pressing NVDA + p to configger the simbles level announcements combo box wich is located at settings>speech: so you can add the same kind of shortcuts for this combo box too if you accept my request and make it a combo box: so i rather have 2 options related to capital in settings instead of 3 options. 2: about addons api compatability: first, i don't think many addons are works in light of this option and they are gonna breake if you change this: but even if there is, and you are worryed about that wich is understandable, then, as i know with folowing nvda project in github, i think you will have a api breaking compatability in the next version and all addons needs to be updated as a result, so please inclood this change also to that version, so that the addons developers will consider this change in their addons too while updating their addons: in my appinian, it is now really a good idea to do this change, because of the api breaking thing soon, and because of the things that i explaned in my abuv line. hope it interested for you and hope you can add it, wich will make me really happy, because then nvda will have one idea developed that was suggested by me at first! thanks so much!

[josephsl]

Hi,

I think it would be a bit late to add it to 2023.1 as translators are already translating parts of the user interface and documentation. What is being suggested in this issue amounts to user interface text changes, so it will involve more time to develop and test this suggestion.

It is possible to add this change to say, 2023.2 but with the understanding that two settings keys will be used internally like what we have now (we have a precedent in report indentation with tones setting). If a single settings key is to be used, a settings upgrade step must be provided to migrate old settings to the new setting with the new settings key documented for add-on authors.

Thanks.

[Brian1Gaff]

Could not under the hood these effectively be the same as the old settings, or is that not possible?. If its going to break stuff, then I'd live with the existing situation. Brian

-- @. Sent via blueyonder.(Virgin media) Please address personal E-mail to:- @., putting 'Brian Gaff' in the display name field. ----- Original Message ----- From: "Joseph Lee" @.> To: "nvaccess/nvda" @.> Cc: "Subscribed" @.***> Sent: Monday, January 23, 2023 12:57 PM Subject: Re: [nvaccess/nvda] make the (Beep for capitals check box not checked) and (Say cap before capitals check box not checked) a single combo box instead of 2 check boxes (Issue #14579)

Hi,

This idea sounds interesting. However, I must caution that this will break add-ons relying on configuration values for these settings (CC @CyrilleB79 for some thoughts).

Thanks.

-- Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/14579#issuecomment-1400295582 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

[Brian1Gaff]

I think that I always use the change pitch for caps myself, I see what you mean about it not really being any saving in this case. The snag with doing a combo box is that you can decide, currently what pitch change you want, but to do that in a combo box would mean another control or slider or something to set the pitch. Brian

-- @. Sent via blueyonder.(Virgin media) Please address personal E-mail to:- @., putting 'Brian Gaff' in the display name field. ----- Original Message ----- From: "Cyrille Bougot" @.> To: "nvaccess/nvda" @.> Cc: "Subscribed" @.***> Sent: Monday, January 23, 2023 1:31 PM Subject: Re: [nvaccess/nvda] make the (Beep for capitals check box not checked) and (Say cap before capitals check box not checked) a single combo box instead of 2 check boxes (Issue #14579)

Hello

Here is my feedback about this request:

Technically, there is no problem to implement this change. As @josephsl wrote, implementing this would require an upgrade in the config (to avoid bugs such as #14170) with a potential impact on add-ons. Thus, if this is implemented, it should be merged in an API-breaking 20xx.1 release.

But I have not heard of anyone having trouble to understand the GUI with these options separated. @amirmahdifard have you had difficulty understanding all the settings related to caps reporting in the GUI? Or is your proposal just to make the graphical interface nicer?

In NVDA, there are 3 options related to caps reporting:

• Capital pitch change percentage
• Say cap before capitals
• Beep for capitals

If the last two options are combined in a combobox, the first one will remain separated in any case. So the goal to have the graphical interface nicer and to have caps reporting controlled by only one option will not be totally reached.

To conclude, my personal opinion is there is almost no benefit implementing this. However, if the community and NVAccess have a different opinion than I, as written before, there is no difficulty to implement it.

-- Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/14579#issuecomment-1400346386 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

[amirmahdifard]

@Brian1Gaff hello: don't worry, we are not gonna change that edit selection box for the capital pich, we will only change the combo box for the say cap before capital leters and beep for capitals check boxes: so don't worry.

[amirmahdifard]

@josephsl ok, but can't you please add it in the 2023.1? because only one option is gonna be changed, so i think that translaters can do that since it is only one option: please if it is possible, add it in 2023.1: thanks so much.

[josephsl]

Hi,

The decision about putting this into NVDA 2023.1 is not mine - ultimately, it is NV Access people who would review a potential pull request. Besides, NV Access staff indicated that 2023.1 API would be frozen soon, so it is late for 2023.1 at this time (sorry).

Thanks.

[amirmahdifard]

@josephsl ok then: so can you please open a pull request for this wich can be murged in nvda 2023.2 if the nvda staff wants it too, thank you.

[CyrilleB79]

@josephsl wrote:

It is possible to add this change to say, 2023.2 but with the understanding that two settings keys will be used internally like what we have now (we have a precedent in report indentation with tones setting).

No sorry, it's not a good idea to have internally two config values for only one setting in the GUI. Reporting indentation was actually a combobox controlled internally by two config values, but this was causing bugs in some specific situations (as described in #14170). That's why it was changed in #14233 so that this combobox be now controlled by a single value. Thus, if validated by NVAccess, this change must go in a .1 release.

[josephsl]

Hi,

To address both comments:

Originally, report indentation was a single value until reporting by tones was added and became a combo box and later the overall setting became a single value, and that's the precedent I'm talking about. I'm considering add-ons here in addition to NVDA config internals.

I imagine three scenarios:

• 2023.1: do it now, complete with the new combo box, config upgrade steps, and user guide changes. This may affect beta 1 release plan.
• 2023.2: use two settings for the new combo box to minimize issues for add-ons that might be using these settings.
• 2024.1: define a brand new value for the new combo box with upgrade steps provided. This would be a breaking change for add-ons relying on config keys.

Of these, 2023.1 > 2023.2 > 2024.1 in terms of risks. The next question then: do you want this feature now or willing to wait a while? If you want it now, then this would mean making changes and sending a pull request within the next few days, something I won't be able to invest in for some time (life priorities); if someone were to do it, that's fine but remember that we are running into impending API freeze, carrying increased risk of bugs and regressions. If you are willing to wait a while (up to several months), then this allows folks to think about ways to implement this suggestion with minimal risks (zero risk is impossible for a complex software system such as NVDA). My thinking is that we should schedule this for 2024.1, and even then, I would like to personally give Python upgrade a priority boost for 2024.1.

Thanks.

[CyrilleB79]

For me 2023.2 is not an option: this does not make sense to reintroduce a bug similar to #14170.

Technically I am able to provide a PR for this issue, but I do not consider it a priority because it's just a little improvement in the GUI. In any case, I would wait for NVAccess green light before doing something, and even if they give it, I will or won't do it depending on the time and the other projects I have.

For anyone else wanting to implement this, you may have a look at how #14233 fixes #14170.

[amirmahdifard]

@josephsl @CyrilleB79 you both said that you can add a pr for this, but because it is a small ui change, you won't do that: whel, as like other combo boxes, this also would be a combo box that i would like: and also, 2023.1 or 2 is ok, but 2024.1 is so long for this small change: please in another comment, tell me that somehow anyone could open a pr for this or develop this or something or i should close rhis tikit: at the first i got a little excited for the first thing that i request is developped or submitted in nvda, but it looks like it is too hard or it is risk or something: and i'm sorry if anyone is got annoyed at me.

[amirmahdifard]

@leonardder hello: could you please look at this, and if you have time and it is possible for you, could you add a pr for this so the developers can work on it and submit it? it is a simple request i like it if it gets developed: thanks in advance!

[XLTechie]

It would be a compatible approach with how other such things are done in NVDA, and slightly declutter the settings UI.

@CyrilleB79 all those "little" changes do add up to a better UI experience over all, and for that reason I would support this. Not in 2023.1, however; it's not a "problem" exactly, so doesn't warrant delaying the release for IMO.

I would favor doing the UI change targeting 2023.2/3, but keeping the two settings as @josephsl suggested, then doing the config upgrade along with probable others in 2024.1.

As for your concern, @CyrilleB79, regarding what happened in #14170: I think that can be resolved by requiring changes to the config value set to be done in a break-before-make style. That is: turn them both off, save, turn on the one required, save. I haven't looked at how to code that, but it doesn't seem insurmountable.

I expect to be doing some settings UI work later in the year--I may tackle this one then if I have time and nobody else takes it on first. The config challenge might prove interesting.

[LeonarddeR]

It makes sense to do this, but I don't bother much myself.

[CyrilleB79]

Replying to all in the same message:

@amirmahdifard writes:

and also, 2023.1 or 2 is ok, but 2024.1 is so long for this small change: please in another comment, tell me that somehow anyone could open a pr for this or develop this or something or i should close rhis tikit:

Please be patient. Even if this proposal is interesting (according to all the comments in this ticket), GUI improvements are not so necessary with respect to others. Thus you should accept that it is not given a high priority.

Please do not close this ticket however. The discussion around this request proves it is interesting and it is valuable to keep it open in any case.

at the first i got a little excited for the first thing that i request is developped or submitted in nvda, but it looks like it is too hard or it is risk or something: and i'm sorry if anyone is got annoyed at me.

No one is annoyed at you, do not worry. Keep on communicating your ideas in the future!

[CyrilleB79]

Answering to @XLTechie (that was missing in my previous reply):

It would be a compatible approach with how other such things are done in NVDA, and slightly declutter the settings UI. @CyrilleB79 all those "little" changes do add up to a better UI experience over all, and for that reason I would support this.

OK, makes sense.

As for your concern, @CyrilleB79, regarding what happened in #14170: I think that can be resolved by requiring changes to the config value set to be done in a break-before-make style. That is: turn them both off, save, turn on the one required, save. I haven't looked at how to code that, but it doesn't seem insurmountable.

Good point. This seems indeed a good solution which does not require to target an API-breaking release anymore. Thanks for this idea.

[amirmahdifard]

@CyrilleB79 ok bro, but please open a pr for this, even if it is murged after a long time: i don't think if i will be able too open another suggestion for nvda soon, so please this one time open one pr for this, i understand you have life prayority, i understand this is so small, but please if possible for you, please open a pr for this this time, i will apprishiate it unlimited, hope when next time i read these comments, you accepted it! really thank you, i really like nvda, but because i don't have a lot of money, we donate $2 for each download: hope you accept it bro!

[XLTechie]

@amirmahdifard wrote:

@CyrilleB79 ok bro, but please open a pr for this, even if it is murged after a long time:

Forgive me if I am explaining something you already know, but "opening a PR", means actually doing the programming necessary to make this happen. Along with that goes testing, compiling, bug tracking and fixing, more testing, and other things that take time.

For anyone to just "open a PR" involves a lot of ground work, even for small changes. A PR is not the last step in making a change to NVDA, but it is closer to the last step than it is to the first step.

So as has been said: please be patient. Someone will open a pull request for this, when someone has time to do the work that goes into it. Even if some of us agree that it should be done, it may not be for many weeks before anyone's existing schedule of work opens up enough to work on it.

[amirmahdifard]

@XLTechie yes, i know that, so i said that if possible, do the programming and open a pr for this so that if the pr has some bugs, fix them, and make it redy to be murged, so the nvaccess will merge it whenever it's time to do it: that is what i've requested from @CyrilleB79 thanks

[josephsl]

Hi,

To follow up on Luke's point and to explain my situation: I am a graduate student studying for his master's degree in a field outside of computing, and this academic term is the last term as a master's degree student. I am also a graduate teaching assistant at the university I attend and take night classes. I am also, or used to be, an active volunteer code contributor for the NVDA project, and still do contribute somewhat (I sent pull requests a lot recently as it was a winter break for me and had some NVDA changes I had in mind which were tested for some time). If things align, I might embark on a big change in my life journey, and if that happens, I won't be able to contribute much to the project.

Writing and submitting pull requests is not an easy task (speaking from experience). First, you need to do lots of thinking before programming: what exactly is the problem, what exact (or close to exact) change is needed, where and what to change in the source code, what are consequences of making this change including not making the change at all, how to test changes, how to communicate changes to different audiences (users, developers, community, you name it), follow-up changes if the pull request introduces bugs, and possibly thinking about removing the change made. Second, the pull request author must think about interaction with others: developers, reviewers, users, community, among others. I always advise pull request writers (and to some extent, NVDA add-on authors) to think before writing code because that can change the whole picture (and to respond to a recent comment: programming and submitting a pull request right away is not the answer as you will see below).

As for GUI's importance in screen reading: while people would say that the user interface of a screen reader takes a backseat, I think it is an important aspect to think about. Not all screen reader users are blind - we do receive reports from sighted users about how NVDA works and doesn't work, and as people say, for some, GUI is their first impression with screen readers (the first thing users will see when running NVDA for the first time is the launcher window, which is part of NVDA's GUI subsystem).

I think recent comments on this post provides an interesting teachable moment: what warms the hearts of developers. If there is one lesson I want readers of this GitHub issue to get at, it is that programmers are not machines capable of solving world's problems on the spot. Sure, there is a talk about how artificial intelligence can solve things based on what it can understand, but AI's themselves are also programmed by humans to begin with. If we ask say, Chat GPT to write a pull request for this issue, it might be able to do so based on what it can find about NVDA source code (with human edits afterward); but that doesn't free humans from the responsibility of reviewing and testing changes, and more importantly, communicating changes to different audiences.

What developers crave is an honest discussion between people that helps them understand the problem better, not a work order to fulfill expectations. And I'm sorry to say that the latter attitude, as seen somewhat in this issue discussion, can have mixed consequences for the progress of this issue. On the positive side, it could motivate someone to resolve this. On the flip side, it can be a huge turn off for some and adds pressure. After all, developers are humans, not superheroes (at one point, I thought programmers were superheroes, but it took me years to come to the opposite conclusion, more so after a series of recent health issues (physical and mental) that made me realize that I am a human and I'm limited in what I can accomplish; this is why I exercise more discretion in pull requests these days to avoid burnout 2.0). Humans are emotional and social beings, and what developers crave is opportunities to have discussions and understand the world through others (on that front, I think we are doing a good job at it throughout this GitHub issue).

Key takeaway for folks submitting issues: let us move away from the mindset that we won't be satisfied until whatever we ask comes to NVDA as soon as a request is made. It takes time for people to understand the problem, formulate the issue in a way that folks can internalize, and plan a potential fix or two. IN the short-term, the attitude I described could be a starting point for someone to get to it and do something. In the long-term, it forces projects like this to be swayed by fulfilling expectations of only a few stakeholders, which can impact the reputation of a vital software for many (sometimes, in a negative way; this is one potential outcome of what is known as iron law of oligarchy that says a project or an organization that started out as a democratic institution or goal to help the masses eventually becomes a group led by and responsible to only a few key leaders and stakeholders). And to give my honest assessment, the attitude I described is, or soon, will hinder the progress of this GitHub issue folks are reading.

Thanks.

[amirmahdifard]

@josephsl i totally understand what are you saying, but i got a little bit disapointed when everyone in here said that they are able to provide a pr for this, but they said that they won't bother them selves to do it: thats all.

[amirmahdifard]

@seanbudd hello, i think that you are one of the nvda staff developers: i like it if this change has been add to nvda, so please you also say what do you think about this? thank you.

[amirmahdifard]

@mazen428 hello: a fue developers in here said that they can do this request, but they doesn't bother them selves much to do it as it is a small change: i know you are recently contributing to nvda, and you already had a fue pull requests: can you please try to do this small request? i'm sorry if it also bothers you to do this too: thanks!

[amirmahdifard]

@josephsl hi sorry to mention you here again, but i wanted to ask you something as how i understand from one of your comments here, you said, if anyone doesn't develop this until then, i will give this issue a proyaritty and develop it for the 2024.1 api breaking change. so, is it actually true and will you do it in that time, or i mis understood you or something? thanks so much.

[josephsl]

Hi,

It appears I won't be able to work on a potential pull request for this issue at all - an important life event just showed up, making it necessary for me to skip this issue.

Thanks.

[amirmahdifard]

@josephsl ok then: i'm sad that i can't do it my self, and the development system is that developers just develop something if they feel and like to do it, i don't think if anyone likes to develop this: don't know.

[amirmahdifard]

if you all don't want to develop this, then please don't say that it's not dificalt to develop this: i don't think if ever anyone is going to develop the things that i have opened this in here: i'm a supporter of nvda: as a non developer person, i asume that developing this one for example, could take 3 houers at moste, i'm not saying it too short to avoid the complanes, but i think a developer can develop this issue in 40 minits for example.

[michaelDCurran]

@amirmahdifard may I kindly request that you avoid placing pressure on others to have issues implemented. A reminder of our Citizen and Contributor code of conduct. Thank you.