Welcome to the TreeSheets productivity tool!

TreeSheets is an Open Source Free Form Data Organizer that leverages the power of hierarchical spreadsheets. Hierarchical spreadsheets serve as a great replacement for spreadsheets, mind mappers, outliners, PIMs, text editors and small databases.

Suitable for any kind of data organization, such as todo lists, calendars, project management, brainstorming, organizing ideas, planning, requirements gathering, presentation of information, etc.

It's like a spreadsheet, immediately familiar, but much more suitable for complex data because it's hierarchical. It's like a mind mapper, but more organized and compact. It's like an outliner, but in more than one dimension. It's like a text editor, but with structure.

Community

If you like, you are kindly invited to join the Discord channel and the Google group for discussion.

Installation

Pre-built binaries for Windows, macOS (Darwin) and Debian-based Linux distributions are available at the Release section.

Please note that the packages for Debian-based distributions provided are built on ubuntu-latest used by GitHub Actions Runner. They could also be installed on other Debian-based distributions depending on whether the required dependency packages are available.

If you use Flatpak, you can install TreeSheets from Flathub.

Using TreeSheets with an AI agent

Starting TreeSheets with the -a flag opens a local, token-authenticated socket that lets an external agent run Lobster script against whatever document you currently have open, and read the result back — useful if you want an AI coding assistant to inspect, automate, or build up a TreeSheets document on your behalf.

TreeSheets -a

It's off by default, only listens locally, and the socket is authenticated with a random, per-launch token file readable only by you. It's available on macOS, Linux and Windows:

• macOS and Linux: a Unix domain socket, /tmp/TreeSheets-agent-<user>.sock.
• Windows: a TCP socket on 127.0.0.1, on a port chosen at each launch and written to %TEMP%\TreeSheets-agent-<user>.port. This also works for the Windows build running under Wine on Linux.

In both cases the token is in the same path with .token appended. If -a doesn't produce a socket (or .port file), your TreeSheets build predates this feature.

If you're using Claude Code in this repository, it can drive a running TreeSheets directly through the bundled treesheets-agent skill (.claude/skills/treesheets-agent) — just ask it to inspect or script your open document once TreeSheets is running with -a. The skill's SKILL.md also documents the underlying wire protocol (a small newline-delimited JSON format) and works whether or not you have this repository checked out, so other agents or tools can talk to the socket directly without any TreeSheets-specific client library.

Source Code

This repository contains all the files needed to build TreeSheets for various platforms.

License

TreeSheets has been licensed under the ZLIB license (see ZLIB_LICENSE.txt).

Structure

src contains all source code. The code is dense, terse, and with few comments, typical for a codebase that was never intended to be used by more than one person (me). On the positive side, you'll find the code very small and simple, with all functionality easy to find and only in one place (no copy pasting or over-engineering). Enjoy.

TS is the folder that contains all user-facing files, typically the build process results in an executable to be put in the root of this folder, and distributing to users is then a matter of giving them this folder.

Ideas for future features and known bugs are tracked in the issues.

Building

This project uses CMake to enable compilation on various platforms and CPack on top of it to package the produced binaries. The build, installation and packaging instructions are within CMakeLists.txt. Please note that you are responsible to know how to use compilers and C++, the hints below are all the help we will give you for building TreeSheets:

1. Clone this repository

git clone https://github.com/aardappel/treesheets

2. Change the working directory to the working tree

cd treesheets

3. Configure the build system

cmake -S . -B _build -DCMAKE_BUILD_TYPE=Release

On Windows this needs the Visual Studio C++ compiler.

4. Build and package for binary distribution

cmake --build _build --target package -j

Alternatively, to only build without packaging:

cmake --build _build -j

On Windows, append --config Release.

5. Install (optional)

cmake --install _build

• macOS: append --prefix <directory> to specify another installation root for the bundle.
• Linux: usually requires root privileges, e.g. run this command with sudo.

If you do not have wxWidgets installed separately (e.g. as shared library on your distribution or operating system) or want to build it within the TreeSheets CMake project as a static library anyway, add -DTREESHEETS_BUNDLE_WXWIDGETS=ON to the build configuration. This builds wxWidgets from source with wxBUILD_SHARED and wxBUILD_INSTALL set to off, even if an installed wxWidgets is found, so that the wxWidgets libraries are statically linked into TreeSheets and no additional wxWidgets files get installed.

Translating

The user interface is translated with gettext. The translations live in TS/translations/<language>/ts.po, and the template they are derived from is TS/translations/ts.pot. You need the gettext tools (xgettext, msgmerge, msgfmt, and msginit for new languages), which are usually already present on Linux and macOS, or see here for Windows. After configuring the build as described above (step 3), the workflow is driven by three CMake targets:

Step 1 is normally done by the developer after changing strings in the source code. To add a new language, run this inside TS/translations (replace lang with a code like it, or pt_BR), then continue with step 3:

msginit --input ts.pot --locale=lang --output=lang/ts.po

More details can be found in TS/translations/readme_translations.txt.

Contributing

I welcome contributions, especially in the form of neatly prepared pull requests. The main thing to keep in mind when contributing is to keep as close as you can to both the format and the spirit of the existing code, even if it goes against the grain of how you program normally. That means not only using the same formatting and naming conventions (which should be easy), but the same non-redundant style of code (no under-engineering, e.g. copy pasting, and no over engineering, e.g. needless abstractions).

Also be economic in terms of features: treesheets tries to accomplish a lot with few features, additional user interface elements (even menu items) have a cost, and features that are only useful for very few people should probably not be in the master branch. Needless to say, performance is important too. When in doubt, ask me :)

Try to keep your pull requests small (don't bundle unrelated changes) and make sure you've done extensive testing before you submit, preferrably on multiple platforms.