Week 2: Menus, Architecture, and Ghost Actions

In my first week of Season of KDE, I managed to stop the Lokalize menubar from jumping around by enforcing a strict "Global Skeleton" in the XML files. We gave tabs empty menus just to hold space and keep the layout from shifting. It solved the jumping bug perfectly, but it introduced a new, slightly awkward UX problem.

Because those empty menus were technically just sitting there to hold space, they were still clickable. If you were in the Project Overview tab and clicked "Sync," nothing happened. No dropdown appeared, it was just a clickable menu that did nothing. It didn't crash the app, but it felt unfinished. My mentor, Finley, pointed this out and showed me how Kate handles this by greying out unusable actions. To see if we could replicate that, i built a massive "Complete Menu Action Comparison" matrix to map every action across every tab.

The matrix proved we couldn't just copy Kate. Lokalize menus change drastically depending on context-the Edit menu has 20 actions in the Editor, but only one (Find) in the Project Overview. Showing 19 greyed-out, irrelevant actions would just clutter the ui. Instead, Finley suggested a better approach: what if we grey out the menu headers themselves right on the menubar? Figuring out how to code that became my primary goal for week 3.

While analyzing the menu architecture, we also discussed whether to move all menu definitions into one centralized file, dropping the individual KXMLGUIClient .ui.rc files. I analyzed how other major KDE projects like Kate, Okular, Dolphin, and Ark to see how they handled it.

I found out that every major KDE app keeps a distributed model and merges dynamically. Centralizing Lokalize would force us into manually managing visibility and shortcuts, creating a fragile refactor. I shared this with Finley, and we agreed to stick to the distributed approach.

Also when i was working with .rc files, I found a graveyard of "ghost actions"-XML entries with zero implementation in the C++ backend. I drafted an email to the KDE translators' mailing list asking for direct feedback on which actions they actually use in their workflows so i can decide which actions i need to implement or remove.