Hussein Shafie wrote:
> Yves Forkl wrote:
>
>>Keyboard-only operation is very important for high productivity. Thus
>>XXE should support it for each user task.
>>
>>Currently, in the following cases, XXE does not allow keyboard-only
>>operation:
>>
>>- Switching between the "superposed" tools like Attribute tool, Search
>> tool etc. is not possible (while it is of course possible to use the
>> HotKeys assigned to the corresponding menu entries, except for the
>> Character tool which is not in any menu). A key combo like Ctrl-Tab
>> might be adequate for this task and consistent with other tab-based
>> interfaces.
Hi Hussein,
might I ask your opinion on this point? Could you imagine to make
Ctrl-Tab switch between these tools? (Please excuse me for nagging.)
Even if the Character tool is mouse-only (as you explain below) and
would not profit much, I would find it useful to open it using the
keyboard only: I might just want to see again the character range that I
saw last in that tool.
Switching between the other tools with Ctrl-Tab seems quite efficient to me.
> The Character tool (and its alternative: command "insertSpecialChars")
> are definitely mouse-oriented and therefore, are intended to be used
> just from time to time.
*grin* Taking that word by word, I have a suspicion that I am not alone
preferring the keyboard to the mouse in many situations... ;-) In fact,
one of the strong points of XXE in my view is that it can be used nearly
without constantly making your fingers fly back and forth between the
keyboard and the mouse. Alas, nearly, for the moment. :-)
> I would rather suggest to add this snippet to your customize.xxe:
>
> ---
> <!-- ================================================================
> Inserts at caret position a character specified
> using its entity name.
>
> Add parameter="[DocBook]" to use the character entities defined
> in the DocBook 4.2 DTD, whatever is the DTD/Schema of the document
> being edited.
> ================================================================= -->
>
> <binding>
> <keyPressed code="ESCAPE" />
> <charTyped char="C" />
> <command name="insertCharByName" />
> </binding>
> ---
Thank you for reminding me of this alternative which is a very fine
thing. Just two suggestions to make it still better:
1) Finding the character you want to insert would be even easier if its
glyph was shown after the entity name, e.g. like this (taking a trivial
but ASCII example):
quot (")
2) Being able to acess the character favorites which also the Character
tool uses would be a great thing. This could be realized by prepending a
prefix illegal in real entity names, like "-" or "(fav)", to the actual
entity name of the favorite. Such a "low-ASCII" prefix would equally
bring the favorites up to the top of the list.
BTW, it will make local (character input) gurus happy to know that they
can make use of, in the user's preferences.properties file, the property
favoriteCharsInTable, and e.g. set it to a value of \u03B1\u03B2 in
order to define small alpha and beta as character favorites for their
users...
> * If you don't author documents for which character entities are defined
> in the DTD, simply specify parameter="[DocBook]". (Just like the
> Character tool, this command inserts *characters*, not *character
> entities*.)
This way of distinguishing between the sets of "real" and "faked"
(DocBook-like) character entity names is perfect. However, in the
documentation (commands/ch06s27.html), it should maybe be stated more
clearly how entity references and entity names are dealt with here as
not all users might be familiar with this topic. (This should teach you
why you can happen to insert a character based on the name of its
DocBook entity and find it encoded after saving as a reference to an
entity from your own DTD carrying a completely different name, for
instance.)
>>- Navigating the document's structure using the Node Path bar ("Find
>> Element| Advanced" with its XPath-based search can be used for
>> similar purposes, but is not really the same thing)
>
> I don't understand this request:
>
> Ctrl-Up = Select Parent
>
> Ctrl-Down = Select Child
>
> Shift-Ctrl-Up = Select Preceding Sibling
>
> Shift-Ctrl-Down = Select Following Sibling
>
> Esc Down=Select All Children
>
> Esc Left=Extend Selection to Preceding Sibling (or select element if
> there is no selection to be extended yet)
>
> Esc Right=Extend Selection to Following Sibling (or select element if
> there is no selection to be extended yet)
>
> See Help|Mouse and Key Bindings. See also
> http://www.xmlmind.com/xmleditor/_distrib/doc/user/userguide4.html#id.s4
Thanks a lot! I wasn't aware of the ESC key combos. (I should have
studied section 4 of the User's Guide more closely...) It is true that
keyboard-based node selection is quite efficient, but "navigating" the
Node Path bar directly (without the mouse) would be even more efficient
at some moments. However, I agree that this feature is not of prime
importance.
>>- Entering characters from the Unicode character sets is currently
>> totally impossible using the keyboard only but requires using the
>> mouse: there is no menu item for character entry and the Character
>> tool does not allow to select a character using the keyboard only.
>> But there is some hope in the new character tool (see below).
>
> See answer above. [snip]
Command insertCharByName provides almost all you need for keyboard-based
character input. So I feel sad reading that you intend to hide this
command from the novice (keyboard-focussed) user in the first place by
not putting it, e.g., in the Tools menu. That would spare the user
having to bind it to a key first, which implies learning a bit to deal
with configuration files beforehand. (I don't know in how far XXE V. 3
will make this easier.)
>>Of course, it would be even more desirable if the new functions of the
>>normal character tool (management of favorites) would also be
>>available here. Especially, the "virtual" range of favorite characters
>>available in the "normal" character tool should also be available
>>here. If so, using a keyboard only should give access to all functions
>>(management of favorites, copying to clipboard) that are offered to a
>>mouse user.
See above: character favorites should also be available to the
"mysofuges" (as I would call those people in French) who are bound to
use insertCharByName.
>>3) Command for vertically recentering the cursor's context [...]
>
> This command exists. See command "center"
> http://www.xmlmind.com/xmleditor/_distrib/doc/commands/ch06s06.html
>
> By default, this command is bound to Ctrl-Shift-L. See Help|Mouse and
> Key Bindings.
Great! Unfortunately, it has a little flaw. In the cited documentation
page it is characterized as: "Centers node selection, text selection or
caret in the document view." However, in the case of an implicit
selection, it only works when caret is inside a text node, not when
caret is in a CSS-generated attribute value editing field.
This is particularly bad when several of these fields are styled to
appear after the root element: tabbing down there can easily result in
the caret disappearing in the non-visible bottom of the document (while
a kind of caret zombie, having stopped blinking, is intriguingly still
visible in the document's last text node which is glued to the window's
bottom line).
Certainly, you can bring the caret back up to that text node by
continuously typing Shift-Tab (provided you know what is going on). But
XXE should rather allow you to center the document view equally when
caret is in a CSS-generated attribute value editing field. I have found
no way of making caret's position visible again using the keyboard only
in this situation.
>>4) Localized interface vs. English Documentation
>> [...]
>>As long as the ideal (?) of a fully localized XXE documentation is out
>>of reach, XXE's documentation should be enriched with a table showing
>>the mapping of all localization names for each language. Maybe the
>>output of the translatexxe utility could be processed to create a HTML
>>document showing these correspondencies before delivering a localized
>>version of XXE?
>
>
> This is certainly feasible using the translatexxe utility, but this
> seems to be a rather crude solution to the problem of lack of
> translations of our documentation.
I agree that translating all of the documentation is indispensible to
complete XXE's localization. That said, I would like to insist that
many XXE's users would benefit much from a list showing the original
English equivalents of their localized GUI items, especially when
- trying to put into practice in their localized GUI what the English
documentation taught them
- asking for help in xmleditor-support list, working hard in guessing
XXE's original English GUI items (and messages) from their localized
interface and the English docs
Meanwhile, as long as XXE is not delivered with such a table for each
language, could you explain briefly to me the steps I need to take to
create a simple plain text list of equivalences myself, calling
translatexxe with some parameters?
>>5) Make navigation between the HTML documentation components easier [...]
>
> * Yes, the documentation of XXE may be improved in many ways, including
> navigation consistency.
>
> * The distribution of XXE includes all the documentation found on our
> web site (unless you are a Java programmer). Simply bookmark
> XXE_install_dir/doc/index.html in your navigator and you'll have a quick
> and easy to access root of our documentation tree. (Windows users have a
> shortcut to this index.html automatically added for us by the installer.)
Well, I have bookmarked the root of my local copy of XXE's documentation
since long, but using this bookmark is by far not as convenient as
clicking on a link in the docs themselves.
> * OK, we'll add a link to XXE's Home to XXE_install_dir/doc/index.html.
I am grateful to you for doing that, looking forward to V. 3 of
definitely one out of the best XML editors in the world.
Yves Forkl
