[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KWord keyboard accessibility enhancements
From:       Gary Cramblitt <garycramblitt () comcast ! net>
Date:       2005-10-21 21:56:43
Message-ID: 200510211756.44459.garycramblitt () comcast ! net
[Download RAW message or body]

On Friday 21 October 2005 04:35 am, Thomas Zander wrote:
> On Friday 21 October 2005 04:03, Gary Cramblitt wrote:
> > I have committed some enhancements to KWCanvas and KWView for keyboard
> > accessibility.
> > With focus in the document window, pressing Popup Context Menu (Menu
> > key) will popup up the menu for the current frameset.  If a frame is
> > currently selected, it pops up the frame/border menu.   Ctrl+Menu will
> > popup the frame/border menu in either case, which seems to work for
> > text, table, and formula frames, but doesn't work for picture frames,
> > unfortunately.
>
> I think we need to make these KPopup instances, since IIRC thats what is
> needed to give them a title.  Having a title for 'Frame Menu' or  'Text
> Menu' makes sense here IMO.

Good suggestion.

> I think we should make the 'edit text frameset' the default action for
> keyboard navigation.  Pressing enter should therefor do more then
> clicking the node with the mouse; it should additionally start editing.
> What do you think?

Yes.  The current default in the document structure popup menu when you hit 
Enter seems to be "Select Frameset", which means you have to hit Tab twice to 
begin editing.  Anybody object to changing the default to "Edit Frameset"?  
In the case of a readonly doc, the default will have to be "Select Frameset".  
Also, I think double-clicking a node in the document structure area should 
also default to Edit Frameset (with fallback to Select Frameset if doc is 
readonly).

BTW, it isn't very clear to me what the purpose of "Select Frameset" really 
is. ???  As best I can tell, it makes a frameset "current" so that operations 
from the main menu will then apply to that frameset.  But isn't it just as 
easy to choose "Edit Text Frameset"?  If a doc is readonly, it would make 
sense, because "Edit Text Frameset" would be disabled, but then why not just 
combine them into a single menu item that changes its label based on whether 
doc is readonly or not?

Also BTW, the popup menu logic in the document structure area doesn't make a 
lot of sense.  In order to popup the menu, you must right-click (or highlight 
and press Menu key) a frame, but the operations available in the popup menu 
are all frameset operations.  Why can't I right-click on a frameset and get 
the same menu? I found this very confusing and only by experimenting for 
quite a while did it dawn on me what was really happening.  As it is now, if 
I have a 5 page document, the only thing I can really do is choose any page 
and "Edit Text Frameset", which *always" takes me to the top of the document, 
i.e., page 1.  When right-clicking on a frame, table, picture, etc., it 
should be possible to perform the appropriate *frame* operations, such as 
"Edit Contents of Frame", "Delete Frame", or "Frame/Border Properties", but 
these are missing.

Also BTW, the document structure area doesn't list framesets in the order they 
appear in the document; it lists them in the order they are inserted by the 
user.  If you don't name the framesets/frames, it pretty hard to tell where 
they are in the document.

And, as long as I'm pointing out usability problems... the document structure 
area highlighted item should track where the caret is in the document.

If I get some time, and nobody objects, I'll take a look at improving the doc 
struct area.

>
> > The biggest remaining problem in KWord for keyboard accessibility is to
> > allow creation of new frames without the mouse.
>
> Well, if you have time...
> In KWCanvas::eventFilter() you can catch Key_Enter and
>  if(m_mouseMode != MM_EDIT) you can create a nice m_insRect and then call
> the appropriate mrCreate[Foo] just like in contentsMouseReleaseEvent from
> line 1686 and down.

Thanks!  I'll give it a shot.

Since you sound like you are familiar with the code...  I've been trying to 
figure out a way to select the frame border with the keyboard.  In some 
places I see code like this

   frameSet->frame(0)->setSelected(true)

but I assume this selects the *first* frame of a frameset; not necessarily the 
frame that the caret is in.  Is there a way to know which frame the caret is 
in?

Also, as long as I'm fishing for code hints... I'm also trying to get the 
screen position (in pixels), of the text caret.  It looks like I need to get 
the KoTextCursor object and use its x() and y() properties, but I had no luck 
figuring out how to obtain the KoTextCursor object from KWCanvas.  (If I can 
figure out the screen position of the caret, then I can figure out which 
frame is under it using frameset->frameAtPos() or doc->frameUnderMouse().)

-- 
Gary Cramblitt (aka PhantomsDad)
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]