Dino Inside KDE Dolphin: Towards Person‑Centric (and Reptile‑Centric) Software

Vlad — Wed, 20 May 2026 10:47:01 +0000

Did you ever contemplate that at some point we'll never see a movie or read a book in its original form - only the rewritten or re-shot version tailored to our preferences and personality - maximizing engagement? If rare purists reach for the original piece(assuming it exists at all), they will surely find it dull: wrong pace, shallow characters, and too many/few sexual or action scenes for their taste.

How about software heavily tailored to personal data and workflows(ideally in real time)? Apps that look little like their upstream. Apps shaped around past user experience and feedback. Apps that enhance the scenarios that matter, dropping the rest. Apps that cross platform and vendor boundaries. The payoff is immediate: better performance, productivity and privacy; less cognitive load to switch tools.

Apps adapt to people, not vice versa.
This isn’t a new idea.

Last year I ran into the Data-Centric Manifesto in the “Personal Knowledge Graphs” book. The premise is explicit: focus on integrating data from different sources; look at apps as interchangeable views over a data layer; give users the power to compose personalized apps from standard add-ons on their own. A few quotes:

… personal data — emails, contacts, calendar events, files, notes, and more — is no longer fragmented across siloed applications but interconnected in a graph structure.

What is needed is flexible, person-centric ways of achieving interoperability (cohesion), while allowing freedom (autonomy) for choosing and combining applications and services managing personal data.

Applications are allowed to visit the data, perform their magic and express the results of their process back into the data layer.

The authors offer a concrete example: instead of needing to pick a single email client, can I compose my favorite email client out of an inbox, a compose window, and a spam filter?

What we have now, instead, is decades of building app‑centric software: incompatible standards, data captured in silos and fragmentation across vendors. Anything else sounds like a pipe dream, doesn't it? On the other hand, this idea is captivating and resonates deeply. It can have far-reaching consequences and huge impact across many domains, productivity- and privacy- wise.

Supply and Demand

Users can extend and customize existing functionality to fit their actual workflows instead of googling each time how something can be done in a specific tool. Mix and match features from different vendors. Work on the same data across platform and storage boundaries.

What does it take to make it real?

First, tailoring software to the user needs sounds a lot like core FOSS freedoms. Unfortunately, FOSS has never fully fulfilled its potential - turns out that having sources available is neither a sufficient nor a necessary condition in practice. More important is the overhead of working toward intentionally extensible design from the start, maintaining good docs(which devs rarely write willingly) and keeping a stable API - with some closed-source products admittedly doing better job here.

It's good to have sources available, to make patches - but something else is missing.

Second, there are many existing solutions: COM/ActiveX components, plugin based architecture of WordPress or Firefox, DOM access with Greasemonkey-like extensions in browsers to run user scripts and modify the web pages on-the-fly, Slack integrations, scripting and Microsoft Office macros. Still, we aren't there yet.

The roadblocks are well known: vendor lock-in, incompatible and conflicting data formats and API, poor docs and lack of ownership for maintaining and ensuring the quality of end-user app mashups. Feel free to extend the list. One thing stands out: these examples all require careful upfront planning and design.

The supply-and-demand declarative pattern comes to mind here. Consider a host app and a set of add-ons, that do the actual heavy lifting. Declare a spec for each add-on. Describe what an add-on offers(supply), then define constraints, dependencies and possible configurations(demand). Introduce an independent factory-like middleware layer tasked with reconciling supply and demand and generating an exact configuration plan to make the assembly work together. This is basically how package management works in most distros. Turns out, the pattern does not scale well for general software.

I actually worked on a project in the past shaped around modules with specs attached and a constraint solver assembling them into a single bundle. The project was eventually abandoned. It required precise specs with all details spelled out explicitly to work, and that in the end didn't make it easier to develop.

So I spent a few days on a little experiment, approaching the problem in a different way.

The Dino Experiment

Tailor your desktop to fit your style and needs - FOSS KDE Desktop promos say. It's indeed a customizable desktop and as a KDE user I have first-hand experience of the resulting pros and cons.

I wanted to extend the real-world app that does not necessarily aligns with my needs. Typically, I'd look up the API and docs to figure out how to write a plugin.

Not this time.

I started with a generic, app-agnostic spec first, acting as a demand. A generic File Manager, in this case. There I lay out expected workflows, API and hooks, focusing on customization and omitting the rest.

Only after that did I look into docs and sources to reconcile my demand with what the concrete app of my choice actually offers. The mapping is partly manual and partly automated with a prompt: Dear agent, please utilize the available docs, if any, otherwise analyze the codebase itself to map high-level spec concepts to concrete classes and functions and along the way identify existing extension patterns, plugin scaffolding, hooks, and signals/slots. I independently built an add-on strictly against my own demanded ephemeral API.

Finally, with the add-on code and mapping scheme available, I asked the agent to glue both pieces(the host app and the add-on) together locally.

I chose KDE Dolphin: mid size project, ~500 files, ~80K locs.

It has neither published API, nor dev docs as far as I can tell. I'd never drill into internals w/o clear guiding docs in the past. It's black box for all intents and purposes, despite having sources available.

Well, not really. Turns out the internals are “quietly” documented - the Doxyfile is missing, but the code itself is commented. Still, there is no high level overview to get started.

The add-on I decided to embed for the experiment, is a lil silly Tamagotchi-like game to play with right inside the file manager: drag-and-drop files to satisfy the critter's needs; if neglected, the critter might become little mischievous and retaliate by messing w/ files(well, make backups more often).

And it worked! The plugin, built against a generic File Manager API, was glued to Dolphin quite nicely based on the provided mapping!

Public Spec Repo

How is it useful?

First, plugins written against the spec and working happily in one tool can be easily adapted to another tool with the same role. Second, there's also an complementary scenario(largely overlooked): decouple functionality found in one tool as a generic plugin and make it available for others as well. Neat.

In general, this means we are now able to tolerate gaps between supply and demand, between the contract as understood by the client and the actual implementation by the service. That was always a major pain point. The more powerful coding agents become, the wider the gap that can be tolerated.

This opens a possibility of maintaining a public repo of generic specs for common desktop roles: generic mail client, calendar, file manager, and so on. Very similar to FreeDesktop standards or schema.org, in fact. Not just yet another spec that nobody supports, but one paired with non-intrusive mappings that project common roles onto popular concrete specimens in the desktop zoo.

Specs that are usable right away. They require neither a lot of upfront work, nor deep rewrites of existing projects. Projects can be gradually updated over time to better align with the roles they represent.

It can't replace the powerful, heavyweight products that fully embrace properly designed extensible plugin-based architecture and commit to maintaining stable API and docs. That still is the only way forward to ensure stability, proper QA and manageable security risks(at the cost of upfront work). This also requires plugin writers follow the contract precisely and update their work each time the API breaks.

Consider this a middle ground between a proper plugin-based approach, which is not always an option, and pure vibe coding on the road toward automating and personalizing user workflows and boosting productivity.

[Appendix] The Spec in Detail

The spec is progressive and hierarchical, with the most important items at the top and advanced details hidden below. It does not replace docs; it inverts the perspective to support extensibility and map generic roles to concrete classes, modules and symbols in the code.

We need to know where and when to run an add-on(sort of spacetime coordinates in software context) to modify or extend behavior. This requires capturing both static and dynamic details.

The spec needs to cover at least 4 aspects:

UI structure: components, widgets, and their relationship. This is not limited to GUI - the same structure is often reflected in CLI, scripting API and IPC(e.g. D-Bus)
Flows
Data models(e.g. filesystem API). For example, to show NextCloud remote files instead of local folders, the file manager must be extended at this point.
Persistent storage: settings and add-on-specific data

For UI, I ended up with this excerpt:

- Main Window: root node, top-level application windowFolder Viewer: lists directory contents
- Side panels: additional dockable panels
  - Bookmarks /  Shortcuts Panel: lists bookmarked folders
  - Details Panel: shows file or folder metadata
- Action bar: main toolbar with navigation and actions
- Status Bar: shows status and progress

This structure is generic and can be mapped to desktop, mobile and cloud based file managers. Also, it's not GUI-specific - it can do as a single representation for CLI, scripting API, IPC interaction( e.g. the FreeDesktop file-manager-interface D-Bus API is compatible with this structure as well), or even agent-facing interfaces.

With the help of a coding agent I then analyzed the codebase and mapped the generic File Manager spec to specific Dolphin classes and other symbols. The mapping turned out to be quite clean - Dolphin follows the given blue print rather closely.

A few words on flows: they capture sequences - control flow, app lifecycle, user scenarios. A flow consists of a start, an end, and optional intermediate steps. Typical flows for a file manager are:

- App lifecycle: initialization, finalization
  - Folder flow: enter folder, leave folder`

Flows can be nested just like UI elements or data structures. Formally, an outer flow starts before any inner flow and ends after it.

Think of flows as generalization of event handling, signals/slots(Qt), hooks, pub/sub pattern, coroutines, etc. Explicit reasoning in flows(which is called model checking in formal proofs) helps avoid many bugs where initialization or cleanup does not run on all paths. Event-driven systems often have sloppy, inconsistent flows, which leads to issues like stale state or invalid caches. It's just plain, old GOTO in different clothing. Harmless flow-related glitches are common - for example, the “Select Background Color” dialog sometimes renders blank until resized(refreshed).

Dolphin does not follow this abstraction cleanly. There is no explicit leave-folder finalization point; it can be emulated by intercepting changeUrl signal and running cleanup for the previous location. The code agent also identified DolphinMainWindow::changeUrl() as the entry point for enter-folder step, but in practice it fires twice per navigation - very common in GUI app(sort of signal chatter).

A minimal Tamagotchi code I built against the abstract File Manager blue print uses enter-folder state to trigger interaction(the critter analyses current folder content and may decide to play a little with the flies..) and the leave-folder event to clean up the mess left behind. Finally, I asked a coding agent to glue it into Dolphin using the mapping - and it worked!

DEV Community: Vlad

Dino Inside KDE Dolphin: Towards Person‑Centric (and Reptile‑Centric) Software

Supply and Demand

The Dino Experiment

Public Spec Repo

[Appendix] The Spec in Detail