Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use icon (emoji) for file defined via icon: property #243

Closed
redactedscribe opened this issue Sep 18, 2023 · 11 comments
Closed

Use icon (emoji) for file defined via icon: property #243

redactedscribe opened this issue Sep 18, 2023 · 11 comments
Assignees
Labels
enhancement New feature or request

Comments

@redactedscribe
Copy link

Is your feature request related to a problem? Please describe.
The plugin saves the icons for files (and folders) somewhere external to the Markdown files. Specifically icons for files is what this FR is about.

Describe the solution you'd like
If I could define icon: as a front matter property and give it an emoji, the plugin could use its value for a file's icon. icon: is a convention also used by Logseq (maybe the property name which defines the icon should be user-definable, e.g. iconize-icon:?). It'd be good to check that the property's value is actually an emoji.

Additional context
Having the file's icon defined in the Markdown would mean not losing such icon customisations if moving away from Obsidian or publishing with some other Markdown tool.

It's not clear whether if a file has been assigned an icon using the currently possible method, that it should be overridden if icon: exists within its Markdown, or vice versa, or to allow only one icon to be assigned to a file at a time. If icon: overrides, deleting the property would then have a fallback if the icon was also set using the current icon assigning method, which may or may not be what you want, but it sounds sane enough.

Thanks.

@FlorianWoelki FlorianWoelki added the question Further information is requested label Sep 18, 2023
@FlorianWoelki
Copy link
Owner

Thank you for the feature request. Might this be the same as #38?

@redactedscribe
Copy link
Author

redactedscribe commented Sep 19, 2023

It sounds similar, but it's not quite clear what that FR is (latter comments don't help much either). It appears to be more to do with defining a file's icon via some detectable keyword in the Markdown (front matter value or tag) which obsidian-iconize would then reference against its known list of icon names and apply to the file. It also doesn't store the icon itself in the Markdown file like my FR suggests to do via emojis.

In short, I see your plugin can display emoji next to file names and in tabs and I'd like to define that emoji per Markdown file via a YAML icon: property. I myself am not interested in leveraging any image icons for files. The emoji displayed would be the OS's native style.

If this FR were to be implemented, reading the icon from both YAML and JSON front matter may need to be supported due to Obsidian supporting both (upon property edits via the UI, Obsidian rewrites JSON front matter to YAML anyway, so not supporting JSON "icon": likely isn't a big deal).

@FlorianWoelki
Copy link
Owner

It sounds similar, but it's not quite clear what that FR is (latter comments don't help much either). It appears to be more to do with defining a file's icon via some detectable keyword in the Markdown (front matter value or tag) which obsidian-iconize would then reference against its known list of icon names and apply to the file. It also doesn't store the icon itself in the Markdown file like my FR suggests to do via emojis.

In short, I see your plugin can display emoji next to file names and in tabs and I'd like to define that emoji per Markdown file via a YAML icon: property. I myself am not interested in leveraging any image icons for files. The emoji displayed would be the OS's native style.

If this FR were to be implemented, reading the icon from both YAML and JSON front matter may need to be supported due to Obsidian supporting both (upon property edits via the UI, Obsidian rewrites JSON front matter to YAML anyway, so not supporting JSON "icon": likely isn't a big deal).

I got you. Your request is really specific to Emojis, if I am not mistaken. That's why I am unsure of implementing this feature. I'll think about it.

@redactedscribe
Copy link
Author

I got you. Your request is really specific to Emojis, if I am not mistaken. That's why I am unsure of implementing this feature. I'll think about it.

Perhaps a standalone plugin would better handle this, however it doesn't seem far removed to what this plugin already does: give symbols to things in Obsidian. Why not via an additional method? Thanks anyway.

@FlorianWoelki FlorianWoelki added enhancement New feature or request and removed question Further information is requested labels Sep 22, 2023
@Aeases
Copy link

Aeases commented Oct 2, 2023

Why not do something similar to Obsidian Banners, where if emojis are entered they are shown as Twemoji / current selected preference in the icon itself, but allow typing in the icon ids defined by custom icon packs like "LiFileText" to use those instead, and just automate the selection through the Icon UI?

@redactedscribe
Copy link
Author

The current workaround for the idea I have proposed in this FR is to rely on title: and use a plugin called Front Matter Title instead. It lets me assign a title: value, which I prepend with an emoji to set my "icon", and for the value to shown as the inline title, explorer list item title, graph node title, etc, without affecting the filename. In short, I can have an emoji set for my file which is then shown across Obsidian's UI wherever the filenames are displayed.

The title: value is also typically leveraged by software which can publish your notes online, so online versions would also have an emoji prepended to the displayed title (this benefit alone may make this approach better than the FR above, unless publishing tools can read and display icon: when set to an emoji too -- some read icon: but I believe valid values are only image paths).

@FlorianWoelki
Copy link
Owner

Why not do something similar to Obsidian Banners, where if emojis are entered they are shown as Twemoji / current selected preference in the icon itself, but allow typing in the icon ids defined by custom icon packs like "LiFileText" to use those instead, and just automate the selection through the Icon UI?

That's what I am planning to implement as well (same for in text icons).
Regarding the front matter feature: I think this feature might be incomplete because there are still folders that cannot have a front matter property. So it might only apply to files, which I think, can be confusing to other users.

@FlorianWoelki FlorianWoelki changed the title FR: Use icon (emoji) for file defined via icon: property Use icon (emoji) for file defined via icon: property Oct 8, 2023
@Aeases
Copy link

Aeases commented Oct 22, 2023

Would it be possible to include a Icon property as an optional override to the default functionality as mentioned by @redactedscribe in the original F.R?

The icon itself can be defined similar to #273, a defined icons property would override that notes icon, as mentioned originally. (also it'd be nice to have an option to automatically assign a property when selecting an Icon from the UI where applicable. (not for folders)


Having the Icons determinable in properties aligns with the Durability & Malleability obsidian aims to maintain within it's markdown files.
It also allows for the interoperability of plugins, for example, I can use Obsidian Banners if I prefer it's implementation of header Banners / Icons, and use Iconize functionality for everything else, like adding Icons and Tab Icons, while having them permantly embedded within my notes themselves if you are ever forced to stop developing this plugin due to burnout or any number of reasons.

I see where your coming from with it being confusing for some users, and I agree, obsidian really needs to add a way to make properties defined by plugins to be hidden so they dont clutter & confuse users, though, in the mean-time having it only auto-assign if you opt-in, and fundamentally being an override for the default functionality I feel resolves this,

For folders it shouldn't really be an option as folder properties would fundamentally have to be defined within obsidian itself (if they added them), and at that point it's no different to just being in Iconize's data.json, as it doesn't allow for the durability & independance of the .md files produced with vanilla obsidian which should be completely independant from both obsidian, in-case someone wanted to migrate to logSeq/others (as said in the o.g. F.R by @redactedscribe)

Also folder properties wouldn't be accessible from other markdown based tooling, like publishing tools (also mentioned earlier)

  • Personal Anecdote being when publishing my notes to a Astro site, I can't access properties defined by Iconize, but can read those defined by Banners as they are defined in frontmatter.

Thanks for reading my dexy induced essay, theres every chance I missed some context but writing is more dopamine inducing then reading :)

@redactedscribe
Copy link
Author

redactedscribe commented Oct 31, 2023

Looks like this will be possible in v2.7.1 when #284 is fixed.

@FlorianWoelki
Copy link
Owner

This has been resolved and added in >2.7.0! Cheers ☕

@FlorianWoelki FlorianWoelki moved this from Done to Deployed in Iconize Board Nov 1, 2023
@FlorianWoelki FlorianWoelki self-assigned this Nov 1, 2023
@redactedscribe
Copy link
Author

@FlorianWoelki I wanted to let you know that I've made a similar FR (snezhig/obsidian-front-matter-title#182) for another plugin due to the fact it supports modifying the displayed title (via title:) in many other UI areas (bookmarks, graph, etc) compared to Iconize (only Files, tab, and note). I think supporting emoji via icon: is a good step for Iconize but I'm not sure how interested you'd be in supporting other UI areas which Front Matter Title (FMT) already does. The goal is to not duplicate developer efforts. Take a look if you have time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Archived in project
Development

No branches or pull requests

3 participants