PluginSDK Update: Please update to the latest RWPluginKit

Hey Guys,

Please build your plugins with the latest RWPluginKit available on GitHub:
https://github.com/realmacsoftware/RWPluginKit/tree/7.x

If you build with the latest RWPluginKit included the console should name plugins when reporting errors (instead of the generic RapidWeaver name). This will be a great help to everyone and should help us all track down issues going forward!

Let me know if you have any questions.

Thanks,
Dan

Unless I’m mistaken, it shouldn’t matter what we link to. The only RMKit/RWKit loaded will be the one in the running app – which will be whatever the customer is running when the error happens.

A plugin can’t opt to have anything different than what’s in the app.

That said… while you’re in beta I’ve been linking to the one that ships in the beta app. It’s not my usual methodology, but it’s helped me track all the changes, which is nice.

Isaiah

speaking of which – i have a question…

i was walking through diffs and i noticed this one…

i always assumed this was strictly for themes – but i noticed uninstall Addons and it caught my eye. are these methods useful for installing any sort of add-on?

also feature request!!! it would SOOOOO awesome to have an URL scheme to RW that could trigger install/uninstall.

OK. I now see what you did in regards to errors. And also that it really doesn’t work very well. :stuck_out_tongue:

you’re #defining over NSLog in a framework header file.

ummm… I see what you’re trying to do, but this isn’t the solution. like. NO. please just stop that. that’s a very bad thing.

there are 1000 great reasons to never ever do something like that. i’ll start with:

  1. #defines are not globals – they operate inline. so if i include a couple headers before including RWAbstractPlugin – then those header will not get this define – they’ll get the old one.

  2. very few files within my plugins require RWAbstractPlugin. Stacks has hundreds of classes and only two of those classes rely on this one.

  3. any developer worth their salt has their own logging facilities that enable more logging for debug builds – your override makes these… challenging.

here’s my recommendation:

  1. an opt-it console log API: RWLog() – logs to the console in whatever way you like an is argument compatible with NSLog. Anyone that wants to log things in release builds should use that.

  2. if you do anything that changes the default logging facilities, then please please please but a defaults switch in so that we can disable those things while working in Xcode. logging is a necessary thing sometimes – especially when you’re building a plugin for an foreign app where the debugger has very limited info available. :wink:

  3. shut off all other logging completely by using _NSSetLogCStringFunction (you’ll have to google that one, it’s private – so ifdef APPSTOREBUILD etc etc) – also: man 3 all

+1 on this one.

I’m already using my own “logging facility” as well, which adds a prefix containing plugin name to logged messages.

We’ll be reverting this change in the next build and will look at it again post 7.0