I am thinking of a better design for my stamps. I would like to add emoji (I have symbols that I would like to use) as custom badges. I don’t necessarily know the unicode for them. Is it possible to use them if they are set up as emoji. I use an application called Textexpander and I could just add them with a few keystrokes. Or some way to find out what their unicode is.
Badges, including custom (i.e. user-installed) badges need to be PNG images. You can create your own sets of badges that you can apply to a note’s $Badge. These custom can be used instead of or mixed with app-installed badges. Read more on custom badges If you don’t know where the application support folder for Tinderbox are, don’t worry as you can open the folder in Finder via Tinderbox’s Help menu (last item on that menu).
Note that the name of any badge - built-in or custom - is the name of the PNG file (without the file extension (i.e. you set $Badge to ‘ok’ not ‘ok.png’. This name is used when setting the badge. Note that badge names are case-sensitive ‘ok’ would not match a badge actually called ‘OK’. My understanding is that the names need to be unique across all badge sets. So, if making your own badge set consider giving the items a prefix. you could thus has a OK symbol called ‘e_ok’ which wouldn’t conflict with the built-in ‘ok’ badge.
Badges are stored on your Mac and not in a TBX, so if you open your document on a different Mac (or send it to a colleague) any custom badges not also stored on the other Mac will not be shown.
I should add, in case it’s not self evident that badges are images and emoji that you type are font characters. In order to use emoji as badges you will need to find a set of images of the emoji characters. You can’t just type a letter (be is ‘a’ or some Unicode number) and have that font character appear as a badge.
So unless you have, or can get a set of 32x32 pixel PNGs of emojis, I’d suggest abandoning this approach.
Conversely, as emoji are fonts you can use them in note titles and text.
I’d caution against using them in titles if you’re going to need to search against them (I don’t know how those sort of characters get handled in things like find)proved wrong - see further down thread. They might work though used in Subtitles or Captions though noting these two features are essentially used in Map view only (which appears your preferred view type).
Edit: corrected false assumptions re emoji as unicode characters in find, queries, actions.
I think this is a great (and more modern ) idea – regardless of current design or capabilities. It would be a welcome change.
I would note that another app, Curio, also has a similar “badge” feature and will accept any typographical character, including emoji, and any PNG. So, it is doable.
BTW – emoji in note $Name is searchable! And why not – it’s just another character. Easy to test.
@PaulWalters thanks for he confirm on emoji and search strings. I’m always cautious lest some dark corner (unintentionally) trip on less usual Unicode. It does feel counter-intuitive to type:
But it works. I’ll amend my advice above (for benefit of later readers).
Note, too, that Ms. Madono is right: you can use emoji as badges.
If you set the badge to be a one-character string, that string will be used for the badge in the absence of the image file. So here’s a note for which I applied the stamp
Using Emoji as badges is such a cool thing. I use them in notes but never tried as a badge. I frequently want a new Badge for outlines but never feel like going through the hassle of creating an image and putting it in the right place, etc. Mark’s example stamp works perfectly and I’d like to use this everywhere! .
One behavior I noticed is that if, in an outline, I click on the badge and the badge selection dialog appears, the Emoji previously used as a badge disappears. Minor, but if we’re headed this way it would be an improvement if the badge “stuck”.
The same happens if you set a string value for a badge name of a non-existent badge, e.g. “homer” and it does not appear to be view-specific (for this or emoji badges). If an invalid badge name is stored in $Badge (i.e. matching no currently stored badge artwork, no badge is drawn and when the note is selected no plus-in-circle badge pop-up indicator is drawn; note that the text of that ‘bad’ badge value is not drawn to screen - though an emoji is. On clicking where the badge pop-up indicator should be my hunch is the ‘bad’ value is checked against know defined badge sets and if no match is found $Badge is reset to default state. Emoji characters don’t match a badge name so would - if the above assumption is true - get voided the same way.
It would appear the $Badge value validation process used by the badge pop-up needs a filter to ignore single character values in the emoji range from being voided if the badge selector pop-up is opened but no new badge is selected. In fact, opening the pop-up and setting no new value ideally should affect $Badge as it might hold a value correctly defined for use on another Mac that has custom badges not installed on the current Mac.
This is all fine, but concretely how to I do what Mark? (eastgate) did. I tried opening the inspector to make a quick stamp. Used Mark B’s code at quick
stamp/appearances-badge; paste $Badge=“”;$BadgeSize=128; but the emoji did not appear. Obviously this is not the procedure. The action inspector does not work either.
I think Mark Anderson is saying you have to make the emoji in the badge folder that you get to under the help menu. Then What do you do? I read the directions that Mark A pointed to, but they say nothing concrete. What is the “badge menu”?
I can’t replicate this error. Using v6.6.6b216 I made a stamp with the following code:
Applying a stamp via the stamp Inspector, I got the emoji badge I expected. I then used the same code in an $OnAdd and a $Rule, with the same success. However, the very first time I used the stamp Inspector I got no (visible) result. I was working fast and didn’t take deliberate step by step observations so I assume that I had either:
- Stamped with no item selected (the test file only had one note - N.B. minimal file contents to avoid side effects).
- There was a refresh issue and the act of de-selecting/re-selecting the note causes the assign (emoji) badge to be drawn.
Re-testing, all worked successfully. So, I would double check the issue you’re seeing is neither of the bullet points above. The first is easily done - whilst concentrating on the stamp inspector, one overlooks whether a note (or the intended note) has focus. I also definitely saw the refresh issue at least once, so the code was working but UI refresh issues were obscuring the fact. But as to the cause of that, I’ve no idea as the test file had only one note.
I also used Quickstamp successfully. In that case, select the target note(s), on the Quickstamp Inspctor select $Badge as the attribute to act on, type just the emoji character, e.g. , in the value box and click ‘Apply’.
My earlier point about badge artwork related to PNG-based badges, the more normal form of badge creation, was written before I became aware unicode emoji badges could be assigned. Jack Batty’s observation about such emoji badges getting unset is verified as an issue but is not the problem Ellen has at this point.
To understand why Ellen’s stamps aren’t working, i’d probably need to see the file with the problem code in situ. @ellen could you post a link to small test file that shows the problem so i could look at it on my Mac? A public URL from your Dropbox would work (if you use Dropbox) - I’m not sure you can upload TBX files to the forum. I’ll send for a forum private message with my email Anyway, a one-note TBX with a stamp should be able to show the problem. Then we can resolve if the problem only occurs on your Macs or on others, so we track down the right problem.
I have never used the quick stamp without an emoji. Probably I am missing something. I am running and will get back with another attempt in 2 days.
Did you mean “…with an emoji”? I’m a bit confused.
A ‘quickstamp’ (one word) is essentially a stamp done on-the-fly without using stored code. Using the Quickstamp inspector, you select the attribute you and to change, supply a value and hit ‘apply’ to apply that change to the selected note(s). Unlike a stamp the code isn’t saved so each time you use Quickstamp you have to do set up the Inspector. For actions you know you’ll repeat, normal stamps can therefore be more useful.
Quick stamp works differently from stamps. Quick stamp is for setting one attribute to one value, not for running arbitrary code.
Here’s the procedure to run Mark’s code using Quick stamp:
- Open quick stamp inspector (cmd+2)
- Type “Badge” in the search box and hit enter (make sure that “Appearance” is shown in the first dropdown and “Badge” is in the second
- Type your emoji into the value box (ctrl+cmd+space brings up an emoji selector)
- Hit “Apply”
- Type “BadgeSize” in the search box and hit enter, confirm BadgeSize is selected attribute
- Type 128 in the value box and hit “Apply”
btw thanks for asking this question… I’ve never been a big emoji person, but using emoji for badges in Tinderbox is awesome!!
Great! Simple and useful.
I played around with this tonight, and thought I’d create a rule that applies a randomly smiling badge to a note. It seemed pretty straightforward:
But nothing happened, the badge remained empty.
After some experimentation I found that emojis in Tinderbox are represented as 4 bytes in a string, and
substr interprets start and length as bytes, not as characters.
So I had to multiply start and length by four. This code does the trick:
I also tested German Umlauts, they appear to take 2 bytes each. That leads to some weird results
# 'ä234' $Name="0ä234".substr(1); # empty $Name="0ä234".substr(2); # '234' $Name="0ä234".substr(3);
I did not test the other string operations, so these are probably safe for non-ASCII characters.
Note: this misbehavior is going to change in 8.0.7. Umlauts, and other characters with diacritics, will be handled normally by .substr()
It turns out that a workaround will continue to be needed for emoji — Unicode is hard! But emoji will now occupy two characters, not four.
Finally, I think your code might want floor(rand() * 8) to give each emoji an equal chance.