API for hiding and showing the Page Inspector for your plugin

Hi all,

We’ve had a number of requests for an API to allow you to hide and show the Page Inspector from plugins - sometimes you might want to do it based on the user clicking a button, or sometimes you might wish to do it automatically.

We’ve gone and added the API to do this in RapidWeaver 7, which you’ll be able to test out when the next beta is released. You’ll also need the latest version of RWKit from the RWPluginKit repository.

When you show the Page Inspector using this method, the customer will be taken straight to the settings screen for your plugin. You don’t need to do anything else. We’ll automatically use their previous choice to decide whether it gets shown at the side or in a floating window.

To use it, do something like this:

NSDocument <RWDocument> *document = [self document]; // 'self' is your RWAbstractPlugin subclass
BOOL visible = document.isPluginInspectorVisible;

// Show your plugin settings in the page inspector
[document setPluginInspectorVisible:YES];

// Hide the page inspector
[document setPluginInspectorVisible:NO];

// Toggle the page inspector
[document setPluginInspectorVisible:!document.isPluginInspectorVisible];

// Observe changes to the page inspector state (this won't tell you if the plugin tab is selected - just that the page inspector is shown or hidden)
[self addObserver:document forKeyPath:NSStringFromSelector(@selector(isPluginInspectorVisible)) options:NSKeyValueObservingOptionNew context:&MyContext];
// You can then use the regular KVO methods to observe changes

You can find the header reference for this in RWDocumentProtocol.h inside RWKit.

If you have any questions or feedback, please respond to this post or email Dan directly.

(Poke @isaiah)

1 Like

This doesn’t appear to be in the latest release of RapidWeaver.

Linking to a version of RWKit that is ahead of what’s in RW just makes RW crash and burn.

Will this be included in RW soon?

Hey Isaiah,

RapidWeaver 7 v17667b was released this evening. That should have what you need :slight_smile:



downloaded. got it! thx!

1 Like

That’s great!

Any chance to have an API to hide a page (that is programmatically checking / unchecking General Settings -> Show in navigation) as well?

Or possibility to mark the page as “not a common page” (or something like this).
Pages like RapidBot or PlusKit are helpers that work in background and don’t need to be treated as common pages.

i’ve been considering making pluskit “just work” instead of requiring the user place a dummy page. the whole dummy page thing seems like the real problem. and that’s something we don’t need API to solve.

basically load the plugin always if it’s installed. add whatever hooks and categories and whatnot during initialize: or load: or whatever.

the page is really only there to give people a place to put settings and such – but maybe those would be better placed into some other type of UI: a Preferences menu; or a toolbar button; or something like that.

Anyone else considered this?


It makes sense. I think that the future of plugins is more for non-page types. For example, I now own Meta Mate. It definitely needs UI to manage meta tags. However, its not a page. Sitemap Plus is another example.

Providing explicit support for plugins that expand RW features without adding a new page type would be the optimal solution, but requires some work by Realmac.

Allowing to programmatically uncheck “Show in navigation” is an easy one. For sure an inelegant workaround, but a good start from my point of view.

for your use, perhaps – but some folks use it for the Table of Contents page that it generates, not for the SEO xml sitemap file.

Specifically what sort of “explicit support” would you need.

I’ll come clean: I’m already testing this right now in PlusKit. It works pretty well. I’d say even better than having a dummy-page.

The only challenge I’ve had is finding a place to put the settings/ui. But I think I’m going to try a toolbar button and see what beta-testers think of it.

I’m not sure I got what you mean, then.

Isn’t RapidWeaver in charge of loading plugins? So it would require explicit support for this new kind of plugins.

That’s absolutely cool. But I’m not sure RMS guys would love having several different plugins customize main RW toolbar adding their own buttons. So maybe RMS should add a new panel in page inspector for these new “special plugins”. And that’s another “explicit support”.

Anyway, even if a plugin produce no content for RW, it is shown in site menu unless Show in navigation is unchecked, isn’t it? And this is the third “explicit support” I can think of.

Or, even better, in “Settings” group:

Every installed plugin is “loads” – which is to say that the bundle read and code is loaded into the executable and a few calls are made.

Obviously, not being a page means you don’t get access to the regular plugin api. Not contentHTML: or extraFiles: methods.

I am a little concerned that there are other side effects that I haven’t considered. Or that there could be in the future. I’m fully prepared to dump this idea if I discover it’s a no-go.

PlusKit has ALWAYS been the leader of all things strange, quirky, and slightly dangerous – so I’m taking that as my queue to try out some more experimental things. :slight_smile:


I thought about using the general settings. I think it’s probably possible – however much has changed in these settings with almost every major release of RW – so I think it would mean limiting support to just one version of RW – which is probably a no-go for a mature plugin like PlusKit.

OK, got what you mean now.

This is not a viable solution for plugins like RapidBot, which partly relies on regular API but still would need to be hidden and loaded only once per project.

And that’s exactly why I mentioned some kind of “explicit support” as required by RMS.

Indeed. Your approach is definitely worth experimenting. Thanks for sharing.

In the meantime, I still cast my vote for this one: @simon :wink:

Well there’s nothing like last minute feature requests!

Ok, so let’s say we added a document-global settings area for your plugins in RapidWeaver 7.1 would you use it?

For plugins like PlusKit where there are no pages required, integration would be very simple - add a single BOOL value to your plugin’s Info.plist and it automatically gets shown in the Plugins area where supported, or as a page (as it always has been) where it’s not.

For other plugins where you want a document-global settings area as well as pages, I haven’t fully worked out the details yet but I’d expect you’d need to supply another view (like you already do for the editor and the page inspector).

In either case, we can also provide an easy way to store preferences, images and whatever else you need inside the project bundle itself that aren’t associated with a particular page.

But before we go and spend time building this feature and then find out nobody wants it: would you use it? What would it need for you to adopt it in your plugins?


So, after my brash post here I showed a prototype UI to a few friends. And no one really liked it. It was too big of a change from previous versions of PlusKit – so I’m afraid to say that I probably wouldn’t use this – I’m going to keep the dummy file approach (as much as I think it’s silly) just to appease existing users. Change is hard. :wink:

That said, I really really really like the idea of having a global plugin data/setttings/files. This is something that’s sorely missing and I would use it in nearly every plugin.

There are many settings that users may want to change that are document specific – usually style settings. They don’t want to change the settings for every document – but they don’t want to have to change those settings for every page either. Document storage would give us the power to save those types of things.

Some immediate wins:

  • Stacks: store partials and images – things that are used on many pages.
  • PlusKit: store pluskit settings – older versions of pluskit traverse the document to find the pluskit page to query the settings on each export – it’s very very time consuming (note: PlusKit v3 no longer does this – but must use Obj-C runtime cleverness instead – so i’ve replaced “slow” with “fragile” which is only slightly better)
  • Blocks: master pages
1 Like

Definitely. We’d love to move some of our plugins to this new “architecture” and create new ones using it.

What we may need:

  • A single instance allowed per project.
  • Keep requiring both content and option views.
  • Ability to export files and / or HTML / PHP like “regular” plugins.
  • Possible exported HTML / PHP (if any) hidden by default in navigation menu.