Opened 11 years ago

Last modified 2 years ago

#3651 assigned enhancement

Possible CharacterMap enhancements (easy) — at Version 35

Reported by: humdinger Owned by: nobody
Priority: normal Milestone: R1
Component: Applications/CharacterMap Version: R1/pre-alpha1
Keywords: Cc: cyberguijarro@…, dcieslak@…
Blocked By: #11518 Blocking:
Has a Patch: no Platform: All

Description (last modified by pulkomandy)

This is hrev29833.

A few possible enhancements:

(done) 1. If I scroll down in the character map on the right side, it'd be nice if the current position was reflected on the left "contents" view by updating the selected block "heading".
(done) 2. By moving the font selection into a drop down menu (to the right of the font size?) it would always be visible what font you're examining.
(wontfix) 3. Is the menu item "Show private blocks" really necessary, is there a need to hide those?

  1. Blocks that don't contain any characters could be greyed out (in the "contents" list to the left).
  2. Left-clicking a character could increase its size (x2 ?) for detailed inspection.

(done) 6. The selected character could also be shown black on white in front of the "Code:" line at the button. This way you can be sure you didn't accidentally move the mouse to the adjacent character while taking your eyes from it.
(done) 7. CharacterMap should node-monitor for updated fonts.

Change History (45)

comment:1 by axeld, 11 years ago

  1. Indeed, that would be nice. I'm just too lazy to implement that, though :-)
  1. Primarily, CharacterMap is a Unicode character map viewer, not a font inspector, therefore I don't think it's overly important to always see that. Especially once the app_server will support font overlays (ie. that means it will substitute the font to get the character). Although I would have an option to turn off those overlays to really only see the contents of the current font, so maybe it's not that a bad idea...
  1. That's a font issue: a font might define private characters, and you are able to see them this way. And yes, it makes sense to hide them by default as this doubles the number of characters, and that makes scrolling harder.
  1. This is currently not supported by Haiku (ie. BFont::Blocks() is not yet implemented).
  1. Too much effort for little gain, I think.
  1. Done.
  1. It should do so, yes. Maybe it should just use a lazily built font menu instead.

comment:2 by axeld, 11 years ago

Component: ApplicationsApplications/CharacterMap

comment:3 by humdinger, 11 years ago

Thanks for looking into things.

WRT 2.), me as an end-user, I'd use the app to find nice/weird characters. So seeing at which font I'm looking would be beneficial.
I guess that it's not possible to have the font type also been supplied when drag&dropping a character into an editor? Provided the editor checks for these things.
That's an area that I'd find very interesting: intelligent drag&drop (as flattened BMessage?). Provide all kinds of information, e.g. size, color, type alongside the "normal" data of the character. This of course for all kinds of inter-app data transfer. So you'd have ID3 Tags for mp3s, width/height for images, etc.

comment:4 by axeld, 11 years ago

You might be right about the font, but well. Maybe someone wants to do that; I don't think it's really needed.

Adding the font information to the text would be possible to do. I guess I could change that when I find the time.

comment:5 by humdinger, 11 years ago

I have one more thing to add, though I don't know if that's how the app is normally used:

  1. A drag&dropped character into CharacterMap could scroll to and highlight the according character in the map. You may see a character and be interested in it's mapping, right?

I dunno, your call. As always. :)

in reply to:  description comment:6 by cyberguijarro, 11 years ago

Hi! this sounds quite boring but actually a nice task to start getting involved in the project.

Let me see what I can do ;)

comment:7 by cyberguijarro, 11 years ago

Cc: cyberguijarro@… added

by cyberguijarro, 11 years ago

Attachment: 3651-2.patch added

Second enhancement (font list as a dropdown menu).

comment:8 by mmadia, 10 years ago

Has a Patch: set

comment:9 by aldeck, 8 years ago

I tested the patch (even though i had to manually apply the parts that are now using translated strings). I've discussed the resulting change with humdinger and noticed it wasn't too good ui wise. A solution would be to keep the original font menu where it is and simply display the current font as text, replacing the "Font size:" label which doesn't add interesting information.

comment:10 by dsizzle, 5 years ago

Cc: dcieslak@… added

Hi, I'm looking into the items as a first crack at Haiku. It's been a while since I programmed in C++ but I'm looking forward to getting back to it a bit.

While testing I noticed something else to add:

  1. The minimum window width should be increased. Currently at minimum width, the left/right side panes jump distractingly as different characters are selected (due to the width of the Code/UTF-8 data)

by dsizzle, 5 years ago

Attachment: 3651-Enh1.patch added

Patch for Enhancement 1

comment:11 by dsizzle, 5 years ago

seems like Enhancement 8 is already in the code, but I'm not sure how to test it.

comment:12 by pulkomandy, 5 years ago


Patch 1: In the (unlikely) "character not mapped" case, shouldn't SelectblockForCharacter return, rather than break? What happens if you call Select with an invalid block number? If this is done on purpose (didn't check the code, do we have an "unmapped" block at the end of the list?), a comment should be added to remember people reading the code of that. Something like this:

// Character is not mapped, we will scroll to the special "unmapped" block at the end of the list

Patch 2: It looks like the code for handling displayName would be much simpler if you used a BString instead of a char*. I think the " > " is not needed (we use "DejaVu Sans Book" elsewhere, with "DejaVu Sans" the family and "Book" the style).

Thanks for the patches!

by dsizzle, 5 years ago

Attachment: 3651-Enh2-2.patch added

rewrote C-style string operations for displayName to use BString - apply *after* 3651-Enh2.patch

comment:13 by dsizzle, 5 years ago

You're welcome for the patches! Thanks for reviewing them pulkomandy.

For Patch 1, the break; actually will exit the for loop, and then fall out of the function SelectBlockForCharacter without calling the select command. It is a stylistic difference, but if prefer a return; then I'm happy to change it.

For Patch 2, I rewrote the C-style string lines to use BString...much much nicer! I don't know how to combine patches so I uploaded a second patch.

I also added a patch for Enhancement 7 - node monitoring font directories to rebuild the font menu on the fly. It monitors B_SYSTEM_FONTS_DIRECTORY and B_USER_FONTS_DIRECTORY, which seemed correct but the system font dir is read-only, and the user font dir has a slightly different path (that doesn't exist in my installation). Are those appropriate directories to monitor?

Last edited 5 years ago by dsizzle (previous) (diff)

comment:14 by dsizzle, 5 years ago

dang, I accidentally left a debug printf in line 330 of 3651-Enh7.patch ...should I make a patch for that too?

comment:15 by dsizzle, 5 years ago

I added a patch for Enhancement 9, setting minimum width of character view pane so it doesn't jump when the code line gets too long. This problem can be seen if you shrink the window horizontally, and then navigate to higher code blocks like Domino tiles. In this patch I included the removal of the debug print accidentally left in patch 3651-Enh7; I hope that's ok.

comment:16 by pulkomandy, 5 years ago

Hi, You can use git rebase -i to edit your git history and merge or split patches. This would be cleaner and would make them easier to review.

Patch 1 applied in hrev48371.

I took another look at patch 2 and I see another strange thing : you have added a call to fFontSizeSlider->SetLabel(displayName); right after creating the slider with that name already, why is that needed?

On patch 7: unfortunately the list of directories to monitor is a bit bigger. You should use the newly introduced BPathFinder class to get the directories (headers/os/storage/PathFinder.h).

Patch 9: this assumes "w" is the largest character, which may be true only for latin fonts. I'm not sure there is a better solution, however. Also the patch now depends on patch 7 so I can't apply it.

comment:17 by dsizzle, 5 years ago

Thanks, I'll look into git rebase.

patch 2: You're right, that fFontSizeSlider->SetLabel(displayName); is not needed. I think it's a copy/paste error.

patch 7: Thanks, I will have a look at BPathFinder!

If i can figure out the rebasing I will redo patch 2 to remove the extra line and merge the 2 patches, as well as fixing patch 9 to not depend on patch 7.

Thanks for your patience; I'm not used to making patches. I need to be more careful with these!

by dsizzle, 5 years ago

Attachment: 3651-Enh2.patch added

Consolidated patch for enhancement 2

by dsizzle, 5 years ago

Attachment: 3651-Enh9.patch added

patch for enhancement 9 (character view pane size changing rapidly)

comment:18 by dsizzle, 5 years ago

I looked into the node monitoring some more. It appears that FontManager is the key, as it is already monitoring for fonts in directories and handling the addition and deletion of them. I don't think it's worth it to duplicate the functionality of FontManager. I could add an accessor function to return FontManager's list of font directories and then monitor those but again I'm not sure if that falls into the scope of this issue. Unless I am missing something, I don't see how BPathFinder would find the font dirs. Thoughts? Alternatively I could add a couple more system font dirs but it wouldn't be as robust as FontManager.

comment:19 by pulkomandy, 5 years ago

One of the directory constants for BPathFinder is B_FIND_PATH_FONTS_DIRECTORY (defined in FindDirectory.h). The BPathFinder APIs will return a complete list of all font directories in the system, and if we add more, it will return those as well.

For enumerating fonts, the existing APIs can be used (see for example src/preferences/appearance/FontMenu.cpp). As Axel suggested, maybe a lazily built menu would be the simplest solution. To implement this, you would use the "MenusBeginning" hook function (in BWindow) to recreate the whole font menu. This way, there is no need to node monitor anything and you can just get the current list of fonts from the FontManager, like the Appearance preferences do.

comment:20 by pulkomandy, 5 years ago

Description: modified (diff)

comment:21 by pulkomandy, 5 years ago

2 and 9 applied in hrev48376.

I noticed some problems with the first patch. There are annoying scrolling interactions and off by one errors.

  • When you start the application, it scrolls to the end of the character list and shows nothing. But when hovering with the mouse you can see there are some "ghost" characters there (?). It should show the start of the list instead.
  • Sometimes the next item in the block list is selected. For example select "Phaistos disk", then hover some characters on it, notice it instead highlights the next item in the block list. Probably happens only with short blocks. All items untill "Hangul Syllabs" are ok, starting from "CJC compatibility ideograms" they are off by one.
  • When you hover a character that is not fully visible at the bottom of the list, there is an attempt to scroll it into view automatically. However since this is done on just mouse hover, and it scrolls the list, the mouse may end up above another character. And then the list will scroll again. Sometimes it will jump down by several blocks before it stops. I think the character list should never scroll on mouse hover, only on clicks or mousewheel.

comment:22 by dsizzle, 5 years ago

Thanks for the feedback! I noticed those too and I will look into them.

comment:23 by pulkomandy, 5 years ago

Patch 7: update_font_families returns a boolean telling you if something changed. You should check this, and rebuild the menu only if needed (so you need to call update_font_families before clearing the old menu).

by dsizzle, 5 years ago

Attachment: 3651-Enh7.patch added

lazily-build font menu patch, now with check for updated font families

by dsizzle, 5 years ago

Patch to fix off-by-one errors in selection of Unicode block

by dsizzle, 5 years ago

Attachment: 3651-AppStartListFix.patch added

Patch to make app scroll to top of char list, and select first unicode block on app start

comment:24 by dsizzle, 5 years ago

Found another issue; not sure if I caused it but probably did:

  • when first unicode block is selected, selecting any other block doesn't change the character view. Scrolling the character view then allows block selection to function.

by dsizzle, 5 years ago

Patch to fix scrolling issues

comment:25 by dsizzle, 5 years ago

The last patch was meant to address the last issue I reported but it seems like that might have also been the cause of the hovering scrolling issue.

comment:26 by pulkomandy, 5 years ago

Applied all fixes in hrev48387. Some comments about commit message formatting:

  • The first line should be a short description of the change (70 characters maximum)
  • You can have a more detailed explanation below that

I have rewritten your commit messages to better match this format. This makes it easier to browse the changes in the source browser ( and other git tools.

So only items 4 and 5 are remaining now.

comment:27 by dsizzle, 5 years ago

Thanks for the info on the comments and for rewriting mine. I will follow that from now on.

item 4: It doesn't look like BFont::Blocks is implemented even still, which is why I haven't touched it. I could try to tackle that but I'm not sure what exactly it entails.

item 5: axeld says above that it is too much effort for too little gain. Do you agree with that?

comment:28 by pulkomandy, 5 years ago

BFont::Blocks probably needs us to make use of fontconfig to extract relevant information from the fonts. We need this for other reasons as well (implementing font overlays and picking appropriate fonts for a given language), so if you want to continue your work with bigger tasks, this could be one and would be very appreciated.

For item 5, I think there could be a reasonable solution using a BToolTip (this didn't exist yet when Axel made his comment) or maybe a BPopUpMenu. I think the Microsoft Windows character map has (had?) this and it is a nice feature as it allows you to browse the characters at a small font size, but still get a bigger view when needed.

comment:29 by dsizzle, 5 years ago

Created issue #11518 (Implement BFont::Blocks) as a related issue. I'll give it a whirl.

comment:30 by pulkomandy, 5 years ago

Blocked By: 11518 added

comment:31 by dsizzle, 5 years ago

I can find ToolTip.cpp, but ToolTip.h seems to be missing...did it get removed for some reason? Or accidentally never checked in?

comment:32 by pulkomandy, 5 years ago

It's not a public class yet, so it is available in headers/private/interface/ToolTip.h, only for applications bundled with Haiku. Other apps are limited to the sime tooltips provided by BView->SetToolTip (with just a string) only, but in this case you need a more "advanced" one to set the font.

comment:33 by axeld, 3 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:34 by dsizzle, 3 years ago

FYI, item 7 has been done for a while (hrev48387)

I'm working on item 4 since #11518 is now done.

Last edited 3 years ago by dsizzle (previous) (diff)

comment:35 by pulkomandy, 3 years ago

Description: modified (diff)

by dsizzle, 3 years ago

Performance patch; linear lookups converted to binary searches

Note: See TracTickets for help on using tickets.