Sorry, but... Isn't ORCA use supposed to be transparent for user programs?
If so, why is it reported as an Ekiga bug?

It seems that ekiga changed some of multi-line text area properties, that makes user can not navigate focus into it. Or ekiga failed to fire some events orca requires.

I don't really understand. Do you have a patch?

Does orca do something with GtkTextBuffer or GtkTextView ? We have special implementations of those ; could it be that ?

Custom implementations of components tend to cause problems with accessibility.  I tried configuring ekiga, but it seems to hang on me somewhere in the setup wizard during/after the detection of the NAT type at page 5/10, so I'm not sure what might be the root cause of the problem.  Nor do I even know what the suspect dialog looks like.  :-(  As Tim says, it may be that Orca is not getting the events it expects, and/or the user is unable to traverse to the given text area.

What is the particular dialog in question doing?  Is it some form of instant message?  If so, Orca *might* be getting the events it needs.  We may need to write a script similar to what we did for GAIM to present information that is being updated in an area that does not have focus.

The hang you are seeing is 329454 but you probably already know that. Can you do the ekiga configuration with accessibility disabled?

(In reply to comment #6)
> The hang you are seeing is 329454 but you probably already know that. Can you
> do the ekiga configuration with accessibility disabled?

Aha!  Yep.  I can configure ekiga with a11y disabled.  I'm now guessing that this report is related to the "chat window"?  If so, I'm going to guess this is indeed something we may need to script for in Orca just like we did for GAIM.  I have no known SIP addresses of anyone to chat with so I can test this out.

If the ekiga folks, however, were able to make the chat area traversable (i.e., allow the user to tab into it and traverse it with the caret), it would help delay the urgency of us needing to provide custom behavior.

Well, what exactly can disallow the user to "tab into it and traverse it with the caret" ?

I mean, we just have a subclass of GtkTextBuffer/GtkTextView, so we must have set some property which breaks orca...

The function gm_tw_build_tab calls 
 gtk_text_view_set_editable (GTK_TEXT_VIEW (twp->conversation), FALSE)
and 
 gtk_text_view_set_cursor_visible  (GTK_TEXT_VIEW (twp->conversation), FALSE);

I have not looked at what gaim does but I assume that it is similar.

We can unfortunately not make it editable... Is there an alternative?

Making it editable is indeed bad. Orca should probably deal with uneditable text views, or it will have to add workarounds for any non-trivial program...

(In reply to comment #11)
> Making it editable is indeed bad. Orca should probably deal with uneditable
> text views, or it will have to add workarounds for any non-trivial program...

Agreed and we have done this for GAIM.  However, if one were able to make uneditable text views at least tab traversable and allow people to arrow around using normal caret navigation techniques, many users would get a win.  For example, people with physical impairments who cannot use a mouse would be able to more easily cut/paste snippets of a conversation.

@Willie: if you can explain me briefly how to do this in GTK+ with a GtkTextView, I'll gladly invest some time on it.

How to make it uneditable and traversable? My guess is that it will require
work in gtk+. Once gtk+ supports it, all programs will follow automagically (including ekiga).

(In reply to comment #13)
> @Willie: if you can explain me briefly how to do this in GTK+ with a
> GtkTextView, I'll gladly invest some time on it.
> 

This part is magic that I don't know how to do.  I know that I've seen people allow labels to be traversable. so I'm hoping text areas allow this to do.  I've been asking around in private e-mail to see if anyone knows if this is possible.

Probably it is not possible without modifying GTK+, but I'm not sure. Thanks for asking!

Perhaps we should move that bug to either "orca" or "gtk+" ?

Darn - I keep on responding to bugs, but Firefox keeps crashing on me and my responses don't seem to get through.  Argh.  I added the following response hoping we might be able to try this before requiring special-casing in Orca (we generally want to fix accessibility problems at the source):

It may be that calling:

gtk_text_view_set_cursor_visible  (GTK_TEXT_VIEW (twp->conversation), TRUE);

might have the desired effect.  I'm attempting to build ekiga with this change in each of the calls to gtk_text_view_set_cursor_visible (there are three of them), but I'm not really sure how to test this since I don't know of anyone else with an ekiga account I can talk to.

BTW, I should also add that autogen'ing ekiga on my Ubuntu box is a bit of a struggle, so I'm not sure I can even test the changes.  Sigh.  I'm wondering if the Ekiga folks might try making such as simple change and giving it a quick check?  If you could, the way you'd know it works is if you can tab into the chat area and arrow around in it.

I don't understand comment #19... if you have a simple patch to test :
$ apt-get source ekiga
$ patch the sources
$ make -f debian/rules build
$ sudo make -f debian/rules binary
$ sudo dpkg -i ekiga_something.deb

and it's done...

(In reply to comment #20)
> I don't understand comment #19... if you have a simple patch to test :
> $ apt-get source ekiga
> $ patch the sources
> $ make -f debian/rules build
> $ sudo make -f debian/rules binary
> $ sudo dpkg -i ekiga_something.deb
> 
> and it's done...

Wish it were so simple.  It's still a struggle for me - I think there must be a number of dependencies I need to build ekiga (I'm unfortunately not an ekiga user or developer).  It may be a more efficient use of our time if someone with a working ekiga build environment were able to try this out.  Otherwise, I fear we may be spending most of our time running down the "it's so easy" path trying to figure out why it's not so simple.  I'll attach a patch and it would be great if you could try it out.

Created attachment 77436 [details] [review]
Patch to pass TRUE to gtk_text_view_set_cursor_visible

If an experienced ekiga developer with a working ekiga build environment could try this out, it would be great.

Something like :
$ sudo apt-get build-dep ekiga
will install all needed build-dependancies.

I'm very short on free time those days :-(

Ah well...the make seemed to do OK.  Here's the results of doing:

$ sudo make -f debian/rules binary
$ sudo dpkg -i ekiga_something.deb

...
dpkg-deb: building package `ekiga' in `../ekiga_2.0.3-0ubuntu3_i386.deb'.
tar: -: file name read contains nul character
> sudo dpkg -i ekiga_something.deb
dpkg: error processing ekiga_something.deb (--install):
 cannot access archive: No such file or directory
Errors were encountered while processing:
 ekiga_something.deb

Is there some other way to install/test this?

In addition, it seems as though you might spend less of your time applying the patch and doing a quick check instead of getting me going as an ekiga developer.  Even if we eventually get this going, I still won't even be able to test because I don't know any other ekiga user to chat with.  I'd estimate this check would take an ekiga developer less than 8 minutes, which is a fraction of the total time spent on this problem so far.  If there is an ekiga developer with 8 minutes to help out here, it would be great.

(In reply to comment #13)
> @Willie: if you can explain me briefly how to do this in GTK+ with a
> GtkTextView, I'll gladly invest some time on it.
> 

Damien - maybe you're the ekiga developer I'm hoping for.  :-)  Would you be able to try out the patch?

The "ekiga_something.deb" was an example ; according to what you pasted, it really should be :
$ sudo dpkg -i ../ekiga_2.0.3-0ubuntu3_i386.deb

(In reply to comment #26)
> The "ekiga_something.deb" was an example ; according to what you pasted, it
> really should be :
> $ sudo dpkg -i ../ekiga_2.0.3-0ubuntu3_i386.deb
> 

Thanks.  I'll wait first to see if our friendly ekiga developer Damien might be able to give the patch a quick poke.  As I mentioned before, even if I continue to invest time in this and manage to get it to build, I don't know any ekiga users that I can contact to even test it.  My assumption here, of course, is that I cannot bring up the chat window unless I have someone to chat with.

I don't have the impression to be that unfriendly, thank you.

I wouldn't expect a "quick" poke from Damien either : he said "I'll gladly invest some time on it", but didn't say when.

If you want, I can also tell you that I'll work on it :-)

(In reply to comment #28)
> I don't have the impression to be that unfriendly, thank you.

Oops!  I didn't to imply that "All those not named Damien are unfriendly."  Sorry you took the message way.  My primary focus here is to make a better experience for users of your product and I'm trying to find the most efficient means to do so.  My feeling so far is that the current means is rather inefficient.

Success.  The patch at http://bugzilla.gnome.org/attachment.cgi?id=77436&action=view works.  I still had no ekiga pals to chat with so I typed in an address of sip:500@ekiga.net, which is something I was able to dig up from a Google search somewhere. Even if I couldn't connect, it at least dumped an error in the chat window.  I was able to tab to it and review the error with Orca.
  
I'm going to toss this back to the ekiga folks.  I'll be happy to spend the extra time to write the ChangeLog entry and commit the patch if the ekiga folks don't have time for that.

Thanks for your patch and tests, I'll apply it probably tomorrow.

I have tested the patch, and I must admit that I don't like it at all from the usability point of view.

Indeed, if you take the general history, you can now move the cursor anywhere in the history, giving the feeling that you can start typing things inside the history.

Would it be possible to only show the cursor if the person clicks in the history instead of showing it all the time?

From the GTK+ doc :
"A buffer with no editable text probably shouldn't have a visible cursor, so you may want to turn the cursor off."

I'm sure there must be an alternative.

Damien:

The primary target users cannot click (as they are blind and cannot use the mouse).

Putting a visible text caret in non-editable text is the standard technique for making such text accessible to blind users - see for instance the F7 "show text caret" technique in mozilla/firefox.  I believe evolution and/or OpenOffice do likewise.

Perhaps using F7 as a "turn text caret on/off" toggle makes sense here too, since orca users will be familiar with it, and it hides the (mis)feature from sighted users who might find the presence of a caret in readonly text odd.

best regards,

Bill

BTW that reminds me that someone should file a "caret browsing" RFE against Epiphany, which currently doesn't offer it.

Bill, having it working the way you describe it makes sense. If someone can create a patch, I will apply it. Otherwise I will put it on my TODO list for next release.

Yes, it looks more sensible like this.

It just occurred to me that instead of having each and every program under the sun detect the F7 key to react and make the cursor visible in each and every GtkTextView, it would be better if the framework were doing the work behind the scene.

Wouldn't that make more sense ?

Yes. IMHO yes. Is it worth to reassign that to GTK itself?

J.

Let's do it. They're more knowledgeable about such things that we are.

I think that in the meantime Ekiga should detect F7 and toggle the cursor, as do other apps.

Moving this feature to gtk+ _may_ make sense but it would require coordination with the apps which are already implementing this themselves (i.e. gedit, mozilla/firefox, evolution, etc.)

I haven't read all the way through this bug, but commenting on something that was said in one of the earlier comments: 

cursor visibility is independent of editability, as can easily be tested with
the testtext demo in gtk+/tests

(In reply to comment #42)
> I haven't read all the way through this bug, but commenting on something that
> was said in one of the earlier comments: 
> 
> cursor visibility is independent of editability, as can easily be tested with
> the testtext demo in gtk+/tests
> 

The patch proposed in comment 30 sets the visibility. I believe it is being rejected by the ekiga developers because it is believed that it may potentially cause confusion for some users: they might mistakenly think they can edit the area if they can see the caret.  I don't agree with this, but my personal opinion should not outweigh those far more experienced in usability than myself.

The ultimate solution is probably to do the F7 bit and also add a menu option to enable/disable caret navigation.  Based upon the discussion in this bug, it seems as though it's going to be a bit of a resource struggle to get that done (nobody has the time to do it and everybody thinks it's someone else's problem).  So...the message area and ekiga will have to remain inaccessible for now unless we can reach a short term compromise and turn the caret visibility on.

If someone proposes a patch for Ekiga based on the F7 thing, I will apply it.
If nobody does it, I will finally end up doing it myself.

However, I think it should be fixed at the GTK+ level so that not all programs have to implement the same thing.

(In reply to comment #44)
> If someone proposes a patch for Ekiga based on the F7 thing, I will apply it.
> If nobody does it, I will finally end up doing it myself.
> 
> However, I think it should be fixed at the GTK+ level so that not all programs
> have to implement the same thing.

Damien - I definitely appreciate your offers here.  This is definitely one of those sticky situations where nobody has a lot of time on their hands.  :-(  As an interim solution, would you be willing to allow the proposed patch in until the F7 stuff is done? 

FWIW, there is precedent for showing a cursor in non-editable text areas without having to press F7 first: the selectable message text in any standard GNOME alert box.  Assuming the text in question here is selectable too (which I'd hope is the case), it seems like an analagous situation to me, so I don't see much of an issue with it from a usability POV.

I really don't like the idea of having a visible caret in a portion of a GtkTextView in which the user can not enter data.

I'll investigate about a proper fix when I have the time.

Hi Damien;

You may not "like it" but having a visible caret in non-editable text, on user request, is standard practice.  It's considered necessary for accessibility, since the text needs to be focussable and have a clear onscreen indication of focus (according to accessiblity standards such as the US section 508 rules).

So I believe the proposed fix is both the best fix and the correct fix.  Users don't need to use it if they don't like it, i.e. it's an opt-in/on-demand feature.

best regards,

Bill

(added after the last comment): Damien I see from reading your previous comments that your "proper fix" probably is the F7 toggle as discussed, so we're probably in agreement about the solution.  Thanks for having a look at it when you are able.

Created attachment 87213 [details] [review]
a patch

Here is a patch that adds a keybinding to make F7 toggle cursor visibility in GtkTextView. It is not quite clear to me if this is what is wanted here, or if this should be a more global thing.

> Here is a patch that adds a keybinding to make F7 toggle cursor visibility in
> GtkTextView. It is not quite clear to me if this is what is wanted here, or if
> this should be a more global thing.

This seems like a good thing to me.  We're having tons and tons of trouble trying to compile GKT+ on Ubuntu, though, so we're having a tough time trying to test this patch.  I have a  question, though:

If the cursor visibility is not on, will someone still be able to tab to it and then press F7 to toggle visilbity (i.e., does cursor visbility impact tab traversal)?

cursor visibility and focusability are independent, so that is possible.

Hello Mathias, I've also been having trouble compiling gtk on ubuntu feisty.  Looking at the intended functionality this seems like it would be a very useful feature for a screen reader user though.  

Matthias: I think what we're trying to say is "THANKS!  This sounds wonderful, even if we cannot test it.  Would you be able to check it in so we could pick it up from a distribution that has success in building GTK+?"

Yeah, I'll check it in in a bit.

2007-05-18  Matthias Clasen  <mclasen@redhat.com>

        * gtk/gtktextview.c: Add a toggle-cursor-visibility keybinding
        signal, and bind F7 to it.  (#380048, Tim Miao)

Can someone tell why this funny shortcut is added to gtk? Does it really benefit all textview users? If it's one application, then perhaps the application should do it? Does it really make sense for editable textview? Here, for example, I finally found out why F7 isn't working as a shortcut and why sometimes cursor disappears, it was quite non-trivial! How about making F7 switch visibility only when textview is not editable?

(In reply to comment #57)
> Can someone tell why this funny shortcut is added to gtk? Does it really
> benefit all textview users? If it's one application, then perhaps the
> application should do it? Does it really make sense for editable textview?
> Here, for example, I finally found out why F7 isn't working as a shortcut and
> why sometimes cursor disappears, it was quite non-trivial! How about making F7
> switch visibility only when textview is not editable?
> 

In general, F7 is reserved for enabling caret navigation and one should probably not change its meaning.  

http://library.gnome.org/users/gnome-access-guide/latest/keynav-1.html
http://en.wikipedia.org/wiki/Caret_navigation

Then it maybe makes sense to introduce GtkWidget::switch-caret-navigation and implement it properly. F7 turning off the cursor in a text editor is not a feature, it's a bug. It's not obvious that shortcut from mozilla (if you know about it) which turns on caret navigation in an html view also makes the cursor disappear in a textview. Even HIG says that F7 is a shortcut *in Yelp*, not something general-purpose.

Matthias?

I guess making F7 only toggle cursor-visibility on non-editable text views
would be good enough, and would avoid the unexpected behaviour in editors.

Would you be willing to do a patch for that ?

Created attachment 106047 [details] [review]
trivial patch

It'd be nice to make the signal return a boolean, so that F7 would do nothing at all in an editable textview (and so F7 wouldn't be stolen for no useful purpose!), but that would be a break.

Hello,

Matthias (or any gtk+ devel), Could you review the Yevgen patch?

Thank you!

We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.