Component renamed but still appears in Napkin


We have a component that was renamed on one branch, and after merging Napkin still retains the old Component (as well as the new one). It appears as a component that can be added and also components which had links to the old component now include both. There is no mention of the old component name in the app_structure.json anywhere.

I have also tried to delete the module/lib folder (the component exists in the project’s module) and even the bin, xcode folders and cached_project_json.cmake file out of both the project and module, run regenerate and then re-built (successfully) from Xcode but still the old Component and references to it persist in Napkin.

Where is NAP retaining the old Component and how do I get rid of it?


@bas any ide what could be the reason for this? Is it still lingering around in the json file as well?


I’m not sure if I understand the issue correctly, but I’m assuming that after changing the type name of the component in your source code, the old type name persists in Napkin?

A couple of things come to mind:

  • Napkin will only (re)load the modules on startup (there is a ticket to support reloading after a module has changed). For now, restart Napkin after each recompile of your module.
  • When you try to load a json file with a component of an “old” type, it should fail to load. NAP stops loading the file when it encounters an unknown type.
  • Aside from your json file and its settings (window size, dock layout and the likes), Napkin does not retain anything. You can inspect the settings file if you want, the latest version should log the settings file as such:
    [debug] Using settings file: /path/to/your/Napkin.conf

If this doesn’t shed any light on the issue, can you show me an example before/after version of your json file?


Hmmm indeed… Seems to be related to having a “copy” of a previous version of the module in user_modules (we are currently using a “project” module instead).

I guess the tricky thing is that Napkin tries to look for all modules everywhere instead of the ones you specify as dependencies in your project, which is confusing?


NAP itself actually loads the modules, this is not Napkin/editor code and I’m not too familiar with this part of the code. @chris explain better how this works.

For now it would probably help to show where it’s loading the modules from (so instead of showing just the names, you’d be getting full file paths).


Yes that’s basically right. It’s loading all of the modules that it can (easily) find.

If there were a design decision made to restrict Napkin to only loading the modules that are depended on by the current project it’s running from, I imagine that wouldn’t be too difficult to implement. That’s somebody else’s decision to make though, and I’m not sure that’s the right direction.


Agreed. Although it might make it a bit harder to read the other 95% of the time.

Maybe there could be a way to affect the logging level of Napkin (and NAP?)?


That does make sense, (at least as an option). It might be a little pedantic, but you’d always know exactly what is being loaded and it forces the user to think about this and keep their application as lightweight as possible.
Napkin could make it easier to enable/disable modules in a simple UI.

Did you mean visually excluding certain levels in the Log panel? If there is no filter in Napkin right now, I must have accidentally removed it and will need to bring this back.


Which would then trigger core re-initialisating I guess? That sounds pretty nice.

No I was actually thinking more on the console, but you’re right, that of course for Napkin what’s happening in the UI is more relevant.


I’m not sure if it’s pedantic, or just sensible? Otherwise the loading mechanism is a bit vague to the user?


I agree. One wants to avoid vagueness, as it may otherwise lead to (false) superstitions, and a feeling of unease (due to not knowing exactly what’s going on at times).


Made a ticket for this: