Re: [Markus Kuhn cl cam ac uk: A suggestion for gucharmap, KCharMap and umap]

[Noah Levitt <nlevitt columbia edu>]

Thanks for all the comments. I think I can answer most of
them. ;)

On Wed, Jan 15, 2003 at 23:55:51 -0500, Havoc Pennington wrote:
> On Wed, Jan 15, 2003 at 10:58:42PM -0500, Noah Levitt wrote:
> > 
> > I agree with Markus that gucharmap should have the unicode
> > annotation and cross reference information. 
> > 
> > Does anyone have ideas on how to present the information in
> > a way that is usable and not overwhelming?
> > 
> 
> Would it fit naturally into the same details pane that currently has
> Unicode category, canonical decomposition, and all that?  Perhaps
> under a second fold-down arrow? Or perhaps it should just be under the
> existing one.

I see some problems with this. When the triangle is open,
the information already takes up a lot of space (at least,
with my theme settings). And the number of items of
information varies for each character, so the size of the
chartable will be varying manically. At various iterations
of development I ran into this bouncing problem, and let me
assure you, it is VERY annoying. Especially if you use
keyboard navigation in the chartable, because the active
character changes very often.

> 
> Some other stuff I noticed when trying out the app just now (I only
> bother to comment because it's a really great app, so don't mind the
> list of stuff):
> 
>  - crashes when you view Hebrew, probably pango at fault,
>    http://bugzilla.gnome.org/show_bug.cgi?id=103634   
>    filed

I saw this too and figured it was pango. :) Thanks for
filing.

> 
>  - GtkOptionMenu is preferred over non-editable GtkCombo
>    (some people may find GtkCombo more attractive, in 
>    GTK+ 2.4 we plan to kill this rationale by making the 
>    optionmenu-type widget themeable to be combo-looking/acting.
>    but combos have bad usability e.g. 
>    http://www.joelonsoftware.com/uibook/chapters/fog0000000063.html).
>    Also, GtkOptionMenu API is more convenient than 
>    GtkCombo. ;-)

If your gtk+ 2.4 promise is true, I might be willing to
switch then. But for now, it takes three keystrokes to move
to the next item in a GtkOptionMenu, whereas it takes just
one keystroke in a GtkCombo. This is kind of important to
me, because I want to be able to quickly compare all my
fonts.

> 
>  - the horizontal scrollbar in the character details (bottom right) 
>    pane never seems to go away. Maybe a GtkTreeView bug, or 
>    maybe just need to use GtkScrolledWindow with GTK_POLICY_AUTOMATIC?

It is GTK_POLICY_ALWAYS, to avoid bouncing. I think it's
ugly too, but it's the only way I've thought of to avoid the
problem.

> 
>  - in the character details, should fields that don't apply to the
>    current char (e.g. "Cantonese pronunciation") still be shown?
>    Hiding it may cause a bouncing effect I guess.

Yup, bouncing.

> 
>  - in Go to hex code point, a "Go" button might be better than "OK"

Ok. I'll do it.

> 
>  - Expand/Collapse All seems like it could be reworded, if it's going 
>    to be a check menu item. Not sure it should be a check item, since 
>    it can have an inconsistent state. (Though we do have a 
>    gtk_check_menu_item_set_inconsistent().)

I agree! Would a usability expert kindly suggest a wording?

Are you suggesting I have two menu options "expand all" and
"collapse all", instead of a check menu item? I could do
that.

I was aware of gtk_check_menu_item_set_inconsistent, but
since the treeview is inside the charmap widget, and the
menu is not, I would have to set up a bunch of signals and
stuff. I guess I could do it, but it seems like overkill.

> 
>  - If you can convince the GNOME docs guys to write you a manual, it
>    might be neat if the various fields in the character description
>    such as "Canonical decomposition" were links to docs describing
>    that field... might be too cluttered, I don't know. But might be
>    useful.

Sounds like a cool idea.

> 
>  - the fields in the character details pane seem to be editable
>    but don't do anything if edited.

That is so the values can be copied and pasted. (Is there
another way?)

> 
>  - Characters around U+1137 seem kind of hosed in Sans but work in
>    some other fonts, may be Pango's fault.

I think it's pango; it does the same thing in gedit. I
mentioned this to Owen.

> 
>  - Putting a hex code in the Find field, at least in U+whatever
>    or 0xabc format, seems like it should work.

Think so? Ok. Do you think I should get rid of the Go to Hex
Code Point, then?

> 
>  - When clicking Find, the only indication that something happened
>    is in the status bar. It might be better if this text were 
>    right next to the Find entry, perhaps? Someone else may have ideas
>    here. I agree a dialog would be annoying.

I agree, the status bar doesn't jump out at you. Not sure if
text right next to the find thing is the way to go. I'll
probably try it and see how it looks at some point.
Hopefully other folks have ideas, too.

> 
>  - Might be nice to remember the font that was set last time the app
>    was opened. (Or all state really, even the "text to copy")

Really, you think a simple thing like a charmap should save
state in a dotfile? Well ok, maybe so. I'm interested in
what other folks have to say about this. It has been
suggested before.

> 
> The app has come out really sweet, everything works - the tree on the
> left tracks scrolling, you can drag-and-drop the characters or
> double-click them, keyboard navigation, it's very nice.  Very fast
> development too, it seems pretty much finished already.

Thanks! I'm glad you like it. :) Plenty of stuff on the todo
list, though.

> 
> You should clearly take the advice of Calum and Seth and other pros 
> over any of my speculation above.

Ok.

> 
> Good luck -
> Havoc

Thanks.
Noah