I've built a plugin for Obsidian that adds lightweight, highly customized, and native-feeling chart layouts (Bar, Line, Pie) specifically for the new database-like "Bases" feature.

Repository: https://github.com/zobweyt/obsidian-bases-chart-layouts Plugin page: https://community.obsidian.md/plugins/bases-chart-layouts

### The Problem

I needed a way to visualize my structured note data in Obsidian without the bloat. Existing chart solutions either required writing complex JavaScript inside codeblocks or felt like heavy web-views slapped onto the app.

I wanted charts that feel like a built-in, core feature of Obsidian—lightweight, snappy, and deeply integrated with the UI.

### What makes it "Native-Feeling"

It goes beyond basic SVG rendering to mimic Obsidian’s native desktop UX patterns:

- *Interactions:* Full support for `cmd/ctrl + click` and middle-click (`auxclick`) to open underlying data files in new tabs or split panes. - *Context Menus:* Right-clicking the chart triggers native Obsidian context menus, not generic browser ones. - *Theme Adaptation:* It doesn't just switch light/dark modes. It dynamically inherits your exact Obsidian theme CSS variables and fonts.

### Tech Stack & DX

I wanted to keep the codebase as clean as the UI:

* *No Node/NPM Boilerplate:* The entire project is built purely with Deno (fmt, lint, build). This kept the development environment exceptionally lightweight and fast. * *Rendering:* Powered by Apache ECharts under the hood for crisp vector rendering. The final plugin size is only ~1MB. * *I18n:* Built-in localization support (currently English and Russian).

### How to try it

1. Ensure you have Bases enabled in Obsidian. 2. Add a chart layout to your view. 3. Map your columns using the native Properties panel.

I’d love to hear your thoughts on the UX integration, and especially on using Deno for building Obsidian plugins. Any feedback or feature requests are welcome!

Comments URL: https://news.ycombinator.com/item?id=48199577

Points: 3

# Comments: 0

Yeah, there is such a problem with the naming "text" suggests something different than just a "string".

I guess handling these nuances falls under the broader categories of internationalization (i18n) and localization (l10n).

I guess handling these nuances falls under the broader categories of internationalization (i18n) and localization (l10n).

I appreciate your suggestion regarding the name, but unfortunately this name was already taken, so "textcase" was chosen.

I also have ideas for adding dictionary key conversion and other features in the future that will handle more than just strings. In addition, you can use this library to convert cases of Iterable[str] using textcase.pattern

It does not support non-English title casing. From the documentation:

> It also works non-ascii characters. However, no inferences on the language itself is made. For instance, the digraph ij in Dutch will not be capitalized, because it is represented as two distinct Unicode characters. However, æ would be capitalized

It sounds like you had quite the adventure with text casing on your project. I'm happy this library can save you some time and hassle. Looking forward to see what can be built with it!

Right now, there's no such GH badge. Since the project will always have zero dependencies, I think we can simply use a static badge like this:

https://img.shields.io/badge/dependencies-0-green

Actually, this library supports conversion of even such strings!

```python

>>> import textcase

>>> textcase.convert("HAppY ApRiL FoOLs!", textcase.case.SNAKE, (textcase.boundary.SPACE,))

'happy_april_fools!'

```

Thanks for the congratulations!

This library actually has zero dependencies! I'm glad you appreciate the no-dependency design.

It's great to hear that it fits well with your work!

Comments URL: https://news.ycombinator.com/item?id=43551915

Points: 71

# Comments: 41