I want to use this bug to track our proposal.

Created attachment 161922 [details] [review]
Initial concepts patch

Hi Alejandro!

I have some implemented concepts around this feature.
The patch i attach, has a lot of things to do, but it is half-functional, and let see how i'm trying to impement this.

By default, as orca startup, it will set up a 'keybindings-profiles' directory as a python package, and creates the 'default' profile as a python module, for an easy import from user-settings.py.

At this moment, profile creation is not implemented, but you can make it runnin a 'touch new_profile.py' into 'keybindings-profiles' dir.

Any feedback/suggestions will be grateful!

Just a little comment : shouldn't this bug be added as metabug 614831 blocker?

(In reply to comment #4)
> Just a little comment : shouldn't this bug be added as metabug 614831 blocker?

Added to metabug 614831.
 I don't see it like a blocker but like a enhancement. Anyway I just added it to the main metabug to track it. Thanks!

Dear Javier,
It would be intresting to discuss this in detail with you.

I think with the changes that bug#618381 made, we can have something even more generic and clean looking.

At top level we would have:
keybindings, with the default keybindings that the user chooses (laptop/desktop/whatever), laptop/desktop comes default with orca, but they might have customized it in their .orca directory.
(1) This is the default keybindings at runtime.

runtime:
a user opens a new application (firefox as example)
If  a particular script needs to define additional shortcuts, then
a new keybindings class is initiated (2)
The parent is the default keybindings class (1)
If orca defines anything for this script by default, then load them into (2), and again, if the user has defined anything extra for this script in their .orca directory then add them in.

user presses something (a)
we check with the active script (2), if it binds (a)
If (a) not found, then continue looking until we hit root of keybindings (1).
If we found an action for (a), then perform it, if we are at root and nothing was found, then we know it is not an orca shortcut.

When closing an application:
The script is deactivated, if (2) has been modified then write it to .orca directory

gui:
Small modifications, (desktop/laptop/anything new) will be entered into the combobox from the key maps that we find, and it will be used as (1)

I would be intrested to hear your views on this.

Thanks.

-Jon

Hi!

First of all, thanks for your attention and quick response, Jon.

Yes, i think it will be more generic as you expressed, but i have some dues and i'm not entirely sure if i've undestood your design's proposal correctly.

Correct me if i'm not right, but your proposal is to store keybindings profiles as an extended default's keymap (desktop/laptop), and discarding current overridekeybindings implementation model defined in .orca/user-settings.py? 

If i'm right in the paragraph above, your proposal differs a little of mine, my initial purpose is to store profiles based on overridenkeybindings (not based on keymaps, as yours), where profiles will be independent of default's keymap profile (desktop/laptop).

I'm so interested with your idea, but i still not imagine how to implement this, i will need more time to study it. Might be interesting to meet us on irc and discuss about our ideas?

Cheers!

Hi guys.

Jon, what you describe sounds like it will be cleaner than what we currently have. I think it's something we should pursue. 

Javier, if I'm understanding you correctly, what you're proposing is that we have the capability to include different keybindings as a set. While an interesting idea, I think that raises some questions:

1. Where would these layouts be coming from?

2. How can we be sure that a layout is valid (i.e. doesn't have conflicting commands)?

3. What happens if a layout is valid now, but down the road we add a new bound command into Orca that might potentially conflict with something bound in another layout?

Hi all,

I'll try to give some light about this feature.

AFAIK, current keybindings profiles are like "System Profiles" which are dependent of physical input (laptop keyboard, extended keyboard, etc...)

What we're trying to develop is "User profiles" which is a particularized set of their parent "System Profiles". We're trying to implement the "User profile" concept.

Then, in this enhancement bug we're trying to implement user profiles to allow users to redefine keys and create and load theirs own profiles. Also this feature allow to store particularized keybindings sets to soften the learning curve to people that come from other systems to Orca (like Jaws users i.e.)

People from CIDAT [1] told us that this a good feature for computers centers with various user in each computer. In Andalucia we have "Guadalinfo centers" too, where different people use the same computer. This is an useful feature for orca. IMHO

[1]: http://translate.google.es/translate?u=http://cidat.once.es/&sl=es&tl=en&hl=&ie=UTF-8

-- 
Alejandro

(In reply to comment #6)

> runtime:
> a user opens a new application (firefox as example)
> If  a particular script needs to define additional shortcuts, then
> a new keybindings class is initiated (2)
> The parent is the default keybindings class (1)
> If orca defines anything for this script by default, then load them into (2),
> and again, if the user has defined anything extra for this script in their
> .orca directory then add them in.
> 
> user presses something (a)
> we check with the active script (2), if it binds (a)
> If (a) not found, then continue looking until we hit root of keybindings (1).
> If we found an action for (a), then perform it, if we are at root and nothing
> was found, then we know it is not an orca shortcut.
> 
> When closing an application:
> The script is deactivated, if (2) has been modified then write it to .orca
> directory

Jon, is this idea related to this bug #485154?

(In reply to comment #9)

> AFAIK, current keybindings profiles are like "System Profiles"
> which are  dependent of physical input (laptop keyboard, extended
> keyboard, etc...)

You are correct.

> feature allow to store particularized keybindings sets to soften
> the learning curve to people that come from other systems to Orca
> (like Jaws users i.e.)

Gotcha. There are already quite a few commands in Orca that happen to be the same as what is found in other screen readers, including the Windows screen reader JAWS. We did that *not* to imitate JAWS, but because we chose keybindings which we felt made sense. It turns out that the manufacturers of other screen readers also thought these keybindings make sense. :-) So for more common functionality including navigation, the commands are already the same without your having to change anything or introduce keyboard profiles.

However, there are many other places where the way Orca works is quite different from the way JAWS works. This is by design. Given this fact, I think that mapping other commands in Orca to keystrokes for the commands which kinda sorta have a parallel in JAWS -- even though the functionality which will result is different -- will not soften the learning curve; I think it will harden that curve by confusing the users in question. They'll be spending their time trying to figure out why pressing such-and-such key "didn't do what JAWS would do" rather than becoming familiar with what happens to be a different screen reader which provides access to a different desktop environment. As I've said before, GNOME isn't Windows; Orca isn't JAWS. Rather than try to ease the transition from one to the other by trying to make these two different environments sorta work the same, wouldn't it make more sense to ease the transition through education, training, and documentation?

> People from CIDAT [1] told us that this a good feature for computers
> centers with various user in each computer. 

And they're certainly entitled to their opinion. :-) All I can do is approach this from my perspective. 

My second master's degree is in education specializing in blindness and visual impairment. For the past almost 15 years, my DayJob has been to teach computer users who are blind or visually impaired how to use (most often) JAWS and Windows applications. For almost 5 years now I've been a member of the Orca community, the last nearly 4 of those years have been spent as an active developer of Orca. CIDAT and I are going to have to agree to disagree I'm afraid. :-)

But having said that, let's ignore what I think for the moment. Quite some time ago, back when Will Walker was still project lead/maintainer and Mike Pedersen (who is blind and used to be a developer at Freedom Scientific before joining our team) was our UI lead, the team was approached about the very RFP that your company bid on. The response back then from Will and Mike (fully supported by me), was that this was a bad idea. So I'm not saying anything different from what has already been said. That the contract was put out with the stipulation that the winning bidder not only create a JAWS mode, but that the bidder get us (upstream) to accept it knowing that we (upstream) fundamentally think it's a bad idea is unfortunate. IMHO. I think it's unfair to both us and to you.

What would be a better use of everyone's time I think is to focus on the bug fixing and documentation components of the lot you bid on. Those are things that would truly benefit all users and ease the transition from one screen reader to the other.

(In reply to comment #11)
> (In reply to comment #9)
> 
> > AFAIK, current keybindings profiles are like "System Profiles"
> > which are  dependent of physical input (laptop keyboard, extended
> > keyboard, etc...)
> 
> You are correct.
> 
> > feature allow to store particularized keybindings sets to soften
> > the learning curve to people that come from other systems to Orca
> > (like Jaws users i.e.)
> 
> Gotcha. There are already quite a few commands in Orca that happen to be the
> same as what is found in other screen readers, including the Windows screen
> reader JAWS. We did that *not* to imitate JAWS, but because we chose
> keybindings which we felt made sense. It turns out that the manufacturers of
> other screen readers also thought these keybindings make sense. :-) So for more
> common functionality including navigation, the commands are already the same
> without your having to change anything or introduce keyboard profiles.
> 
> However, there are many other places where the way Orca works is quite
> different from the way JAWS works. This is by design. Given this fact, I think
> that mapping other commands in Orca to keystrokes for the commands which kinda
> sorta have a parallel in JAWS -- even though the functionality which will
> result is different -- will not soften the learning curve; I think it will
> harden that curve by confusing the users in question. They'll be spending their
> time trying to figure out why pressing such-and-such key "didn't do what JAWS
> would do" rather than becoming familiar with what happens to be a different
> screen reader which provides access to a different desktop environment. As I've
> said before, GNOME isn't Windows; Orca isn't JAWS. Rather than try to ease the
> transition from one to the other by trying to make these two different
> environments sorta work the same, wouldn't it make more sense to ease the
> transition through education, training, and documentation?

Absolutely agreed, as I said, JAWS is not the point.

In fact, we are going to improve the documentation of Orca and provide howtos. I know how Jaws and Orca works, and Orca is far better than Jaws, no doubt about that. And the operation mode is different.

> 
> > People from CIDAT [1] told us that this a good feature for computers
> > centers with various user in each computer. 
> 
> And they're certainly entitled to their opinion. :-) All I can do is approach
> this from my perspective. 
> 
> My second master's degree is in education specializing in blindness and visual
> impairment. For the past almost 15 years, my DayJob has been to teach computer
> users who are blind or visually impaired how to use (most often) JAWS and
> Windows applications. For almost 5 years now I've been a member of the Orca
> community, the last nearly 4 of those years have been spent as an active
> developer of Orca. CIDAT and I are going to have to agree to disagree I'm
> afraid. :-)
> 
> But having said that, let's ignore what I think for the moment. Quite some time
> ago, back when Will Walker was still project lead/maintainer and Mike Pedersen
> (who is blind and used to be a developer at Freedom Scientific before joining
> our team) was our UI lead, the team was approached about the very RFP that your
> company bid on. The response back then from Will and Mike (fully supported by
> me), was that this was a bad idea. So I'm not saying anything different from
> what has already been said. That the contract was put out with the stipulation
> that the winning bidder not only create a JAWS mode, but that the bidder get us
> (upstream) to accept it knowing that we (upstream) fundamentally think it's a
> bad idea is unfortunate. IMHO. I think it's unfair to both us and to you.
> 
> What would be a better use of everyone's time I think is to focus on the bug
> fixing and documentation components of the lot you bid on. Those are things
> that would truly benefit all users and ease the transition from one screen
> reader to the other.

I have no doubt, Joanie, that your knowledge is vast, you demonstrate it every day.

I make a mistake in my explanation, our only target is allow users to load/save their own profiles, no more.

Sorry for lead to confusion.

Well, I'm looking at a bug summary which is (currently) Keyboard shortcut profiles.

I comment #8 I said the following:
[...]

> Javier, if I'm understanding you correctly, what you're proposing is that we
> have the capability to include different keybindings as a set. While an
> interesting idea, I think that raises some questions:
> 
> 1. Where would these layouts be coming from?
> 
> 2. How can we be sure that a layout is valid (i.e. doesn't have conflicting
> commands)?
> 
> 3. What happens if a layout is valid now, but down the road we add a new bound
> command into Orca that might potentially conflict with something bound in
> another layout?

And rather than answering those questions, you told me about what CIDAT thinks. My questions still remain.

Dear Alejandro,

I agree with Joanie, helping us to solve existing bugs and improving documentation would be very useful.
There are some important issues that need improving, my favorits are performance related issues, because that would really benafit all the users, and orca needs some work in this area.
It would be really great if we could focus on existing bugs for the time being.

-Jon

(In reply to comment #8)
> Hi guys.
> 
> Jon, what you describe sounds like it will be cleaner than what we currently
> have. I think it's something we should pursue. 
> 
> Javier, if I'm understanding you correctly, what you're proposing is that we
> have the capability to include different keybindings as a set. While an
> interesting idea, I think that raises some questions:
> 
> 1. Where would these layouts be coming from?

Actually, overridenkeybindings are defined in user-settings.py. My idea is
implement overridenkeybings out of user-settings file, as an independent module
in user's '.orca' dir, giving the chance of make profiles based on
overridenkeybindings. So, if i use an specific application that has a keystroke
that conflicts with an orca's keybinding, i can in a easy way select my profile
and use that application without any problem, so each time i need use that
application, i don't need to set this overridenkeybindings again and again.

> 
> 2. How can we be sure that a layout is valid (i.e. doesn't have conflicting
> commands)?
> 
> 3. What happens if a layout is valid now, but down the road we add a new bound
> command into Orca that might potentially conflict with something bound in
> another layout?

About this two points, orca's current overridenkeybindings doesn't has a
control if there are conflicts with any other orca or other application
commands, maybe this is a reportable bug.

I'll give you an example. I'm an orca user, i use orca on my laptop, so i have
to use Laptop's layout. Usually, i use my computer with an USB keyboard, so i
must select Keyboard's layout. I have an overridenkeybinding defined, like
increaseSpeechRateHandler using KP_3, that's not defined in Laptop's layout,
but in Keyboard's. If I switch to Keyboard's Layout, then, when i want to
increaseSpeechRate using KP_3, orca crashes.

Thanks for your attention!

Thanks for your clarification.

Largely we handle the keybindings validation when the user is doing the rebinding. (i.e. if you try to use Orca's feature to (re)bind something and that keystroke is already been assigned, Orca should complain.)

As for the crash you report, that sucks. :-( Mind opening another bug for that?

On a different/related note, what's so special about keyboard shortcut profiles? :-) Would it make sense for there to be a way to save all settings? In a multi-user environment, different people are going to have different preferences around speech rate, braille contraction tables, synthesizers, text attributes, etc. It might be cool to take a broader look and importing and exporting settings.
I've opened bug/rfe 619745 for this purpose should anyone be interested.

(In reply to comment #16)
> Thanks for your clarification.
> 
> Largely we handle the keybindings validation when the user is doing the
> rebinding. (i.e. if you try to use Orca's feature to (re)bind something and
> that keystroke is already been assigned, Orca should complain.)
> 
> As for the crash you report, that sucks. :-( Mind opening another bug for that?

I'll opening a bug report for this, stay tuned. You were right with point 3, but is not caused by Javier's patch but how configuration is handled in Orca. 

> 
> On a different/related note, what's so special about keyboard shortcut
> profiles? :-) Would it make sense for there to be a way to save all settings?
> In a multi-user environment, different people are going to have different
> preferences around speech rate, braille contraction tables, synthesizers, text
> attributes, etc. It might be cool to take a broader look and importing and
> exporting settings.
> I've opened bug/rfe 619745 for this purpose should anyone be interested.

bug #619745 is a nice feature to take care but I think that anybody will harmed if orca support both features (all settings plus keyboard layouts)

(In reply to comment #17)

> bug #619745 is a nice feature to take care but I think that anybody will harmed
> if orca support both features (all settings plus keyboard layouts)

Sorry. Say again?

(In reply to comment #18)
> (In reply to comment #17)
> 
> > bug #619745 is a nice feature to take care but I think that anybody will harmed
> > if orca support both features (all settings plus keyboard layouts)
> 
> Sorry. Say again?

:)

What are the reasons for not supporting both?

(In reply to comment #19)
 
> What are the reasons for not supporting both?

In short: Because it's redundant to do so.

If we're saving all settings -- which would include the keyboard-related settings and bindings (right?) -- why should we have an additional feature (and associated code? and associated UI elements?) just to deal with keyboard profiles. Keyboard profiles will already be getting saved along with everything else.

Might we also be confusing the user by having two places to save settings into a profile: 1. keybindings and 2. everything else?

~~~

Here are a couple of questions in return: Why is saving all settings something the folks at CIDAT should be happy to support? Why should they think of it as "essential," rather than just "nice to have"?

Here's how I'd answer that:

As has been pointed out by y'all in this bug, one of the main motivators behind this feature is providing better support in computer centers where you've got multiple systems being used by multiple users throughout the day. To be honest, I'd say the one thing most active users have in *common* with respect to settings is the keybindings they use. In other words, realistically, keybindings don't need to be changed all that often in a multi-user environment. But these very same users, who can happily agree upon the keybindings, have *vastly* different preferences when it comes to things like:

* Speech settings (volume, rate, pitch, synthesizer)

* Punctuation level (how much should or should not be spoken?)

* Echo level (none, characters, words, both characters and words,
  sentences? if characters -- which ones should be echoed?)

* Whether or not tooltips should be spoken

* Whether or not mouse review be enabled

* Whether or not magnification should be used (and if so, what
  type of zoom window? and should colors be reversed? and how
  much magnification? and should there be cursor crosshairs or
  not? etc.)

* Whether or not braille should be used? (and if so, should it
  be contracted braille or uncontracted braille? Should flash
  messages be presented? If so, for how long? What should be
  used to 'underline' selection in braille? dots 7 or 8 or both
  or None? Ditto for links. Ditto for text attributes.)

* Speaking of text attributes, which attributes are of interest and
  which are not? In what order should those attributes be spoken?

* Should brief verbosity levels be used or more verbose levels?
  This goes for speech and for braille.

* Should positions in the list be spoken?

* Should tutorial messages be spoken?

* Should indentation and justification be spoken?

I could list more, but I'm tired of typing these out. ;-) My point is: For any given user, you are likely to find a different combination of the above being that user's preferred settings -- settings which make the difference between muddling through on a system, and working effectively on a system.

So in my mind, what would be incredibly useful in such a multi-user, multi-system environment such as the one you describe is: the ability to walk up to any system and have the perfect-for-that-user combination of settings. Store the file on the network; store it on a thumb drive; whatever. But let me walk up to any computer and have what I need instantly. It would be amazing. And it would benefit a lot of Orca users.

Keyboard profiles far less so.

How else would saving all settings and not just keyboard settings in a profile be beneficial? One user can have differing needs throughout the day, even on the same system, even without a USB keyboard. Users with low vision can get eye fatigue; lighting conditions vary. So you might want normal/true colors and 2x magnification and no pointer enhancements and no mouse review or tooltips normally, but at the end of a long day (or every time you have to take your laptop to the glare-filled conference room for a meeting) need to switch to reversed colors and 4x magnification and pointer cross hairs and mouse review and perhaps some speech output.

In both of these scenarios, you could easily have no need whatsoever to change the keyboard settings.

The ability to save all settings into a profile would also potentially be a way to address feature requests we've had around fast language switching, which I'd think would come in handy in Spain. If we're going to do language switching the RightWay(tm) (rather than slap out a quick fix), we don't just need to change the synthesizer. You might also want to change:

* The rate of speech: Fast for Spanish, slower for English.

* The level of punctuation: When chatting with me, you don't need to
  hear every stupid comma I type in IRC; but with your day-to-day
  job tasks, you want every punctuation mark spoken.
  
* Whether misspelled words are announced and indicated in braille:
  If you're composing a message in English on a Spanish system
  without an English dictionary enabled, Orca would likely be
  announcing every other word as misspelled. Ick!
  
* The braille contraction table: It should correspond with the
  language. *In addition* if you're extremely fluent in braille
  in your native language, and far less fluent with braille in
  other languages, you probably want contracted braille for your
  native language and uncontracted braille for the rest.
  
Not sure you'd have a need for different keyboard shortcuts, however... And even if it might be nice to have them, you could easily get by without them, I'd think.

So hopefully I've made a decent case (sales pitch?) for why making it possible to save all settings -- which would include keyboard shortcut settings -- would be extremely useful. :-)

Here's the other piece:

Unless you can promise me that you'll stick around forever and support your new feature, the reality is that if we upstream accept it, we upstream are also accepting the obligation to maintain it.

If it's not already clear from my answers here and in previous comments on this bug and on the Orca list, I'm afraid I see a stand-alone keyboard shortcut profiles feature as unimportant upstream: We don't have users clamoring for it -- not in our community anyway. And Orca users (and anyone else, such as the sysadmin in a multi-system, multi-user environment) can already customize and save their keyboard settings. True, we apparently have a crasher bug that Javier discovered... :-/ But the solution to that crasher is not multiple profiles; it's to figure out where we screwed up and fix that bug. And while perhaps it would be kinda nice to have multiple profiles for that USB keyboard, it's far from being an essential Orca feature.

The only folks I'm hearing advocating for this particular feature are folks related in one fashion or another to Guadalinfo. That makes this a downstream issue. If Canonical or Oracle or Novell came to me with a similar request, I'd tell them the same thing. We've got WAY too much to do to take on the maintenance of something which we don't see a need for and which active members of our community haven't even asked for, let alone demanded.

HOWEVER, since the ability to save all of the other settings into a profile would be of GREAT value to us upstream and to Orca users everywhere, and since it would be kinda silly to have a feature to save and load all settings *but* keyboard shortcuts, I'd would be willing -- even happy -- to take on the maintenance of keyboard profiles as being one component of a single, comprehensive settings profile feature.

Thanks for the brilliant explanation. Very clear. It's the way to go.

Ok Joanie, totally agree with you, it's quite more interesting to store all settings as profiles, for mobility questions and a multi-user environment like Guadalinfo, and of course for all orca users.

So i will focus my implementation's proposal and will track it into the bug you opened, bug #619745.
I can work with these new feature from now, and will have, probably next week, an implementation's proposal with some proof of concept.

In relation to the bug with keybindings conflicts, i can report it with full info and maybe suggest a fix. :]

Thanks again and again for your attention!

Cheers!

Reported (In reply to comment #8)

> 3. What happens if a layout is valid now, but down the road we add a new bound
> command into Orca that might potentially conflict with something bound in
> another layout?

Created bug #619809

Comment on attachment 161922 [details] [review]
Initial concepts patch

Sorry for the spam. Setting to 'reviewed' to get it off of the 'patches without a response' list.

Planning spam. Sorry!

I think the current profile setup fixes this issue