RapidWeaver 8.0 Dev Beta 4 (Build 19335b)

Hey Guys,

Okay, this latest build is definitely a work-in-progress. We’re part way through making some fairly big UI changes, and things will be wonky/half-baked. However, I wanted to get it into your hands so you can have a play and see what you think. Feedback on the direction this is going would be appreciated.

What’s new in the build:

  • [NEW] All New responsive/scalable, live-updating preview window!
  • [NEW] Theme chooser is now in a pop-over (very unfinished!)
  • [NEW] More work on the Resources browser (top toolbar is slightly hidden, whoops)
  • [NEW] Integrated the Squash engine for better image compression
  • [DEV] Theme Styles now support slider controls
  • [DEV] Theme Styles now support numerical fields (Edit: sorry, not yet implemented!)
  • [FIXED] Fixed an issue with generating cache busting links incorrectly

Hopefully we’ll ship another beta later this week with a lot of these UI things fixed up.

Download RapidWeaver 8.0 Dev Beta 4 (Build 19335b)

Happy Weaving and let me know what you think.

P.S. You may see this dialog when previewing some themes, it’s a known issue and should be fixed in the next build. Don’t panic!

1 Like

Excited about these new theme controls! I suspect these will be outlined for us once they’re finished.


oh yeah, here’s what’s working right now, if you have any questions, just shout.

Logo Width and Height support:

In your theme’s Info.plist, you can now specify RWAssetOptions (with some forward thinking, we’d have put the RWBannerOptions into this instead - never mind). Inside that dictionary, you can specify RWThemeLogoImageRecommendedWidth and RWThemeLogoImageRecommendedHeight.


Slider support:

Valid options for the slider “Format” are:

  • “None” (or not set): formats as an integer (whole number)
  • “Decimal”: formats as a decimal number
  • “Percent”: formats as a percentage



Awesome! Thanks.

Also, I’m playing with the new Preview Mode. Very nice. Two thoughts on it –

(1) Would it be possible to allow the user to set a refresh delay? I suspect a lot of people will open the preview on a secondary monitor and edit “live.” At least I know I will do that for when I’m building and testing stacks I suspect. This would allow the user to adjust how long a delay after they finish typing something until RW refreshes the preview. While setting an exact value would be nice, it could even be something like …

Delay: ( ) fast ( ) medium ( ) slow

(2) Can the preview size for Custom be scaled non proportionately? It seems to stick to a set height and width proportion when dragging the corner of the window. I don’t know if that is by design or a bug, but I’d love to be able to drag it to the size I need / want as I’m not likely to use the presets very often.

Also, forgot one other thing… will the “elements” on the Basic page style be rearrangeable eventually?

New builds are looking pretty great Dan. I didn’t much time for testing, but will try to file a few more bug reports this week.

Really like the new Preview mode. Seems to be working very well. The window animations are a nice touch. Very slick.

There’s a slight issue here, that Isaiah can probably fix. When we’re asking for “export content”, Stacks seems to auto finish the edit on anything in the page, this is annoying as I loose focus on what I’m editing.

This video shows the issue with Stacks and how it works nicely with the Basic page type.

This is not a bug with Stacks, it’s just the way it works, however Isaiah can probably give us the content without forcing the current item to finish it’s edit. @isaiah What do you think?

I think we’ll add some more options for the auto refocus along the lines of this:

  • “Manual” - Only refresh when the user hits the reload button.
  • “Auto Refresh” - this should refresh when the user has finished editing (e.g. stopped for a second or so).
  • “Refresh on Focus” - Focus when the window gets focus.

That’s a bug, will be fixed so it resizes correctly (like a normal browser window) in the next build!

1 Like

I’d say ignore the basic page style for now, it’s in flux and may not even ship…

Well, I hope it does, or eventually does in a future version of RW. It could be a fun page type.

This is not a bug with Stacks, it’s just the way it works, however Isaiah can probably give us the content without forcing the current item to finish it’s edit. @isaiah What do you think?

I think it’s do-able, but I think there are probably some really fundamental performance issues that we’re going to hit right out of the gate – which is not a really good look.

Edit/Preview have traditionally been modal. Even RW7’s live browser preview only updated on focus changes and saves.

Changing that behavior is probably no big deal for a markdown page – but even a modest Stacks page takes noticeable time to export. Adding the expectation that previews are happening while the user types seems like it would be encouraging users to expect it to be nearly immediate.

We could probably do a lot better, if we thought about the bottlenecks between RW/Stacks and tried to smooth them out a bit.

Right now preview and publish are handled with the same RW API calls. Those API calls pass a context object (params) that tells the plugin how to export images and generate links. These params can (and do) change from one call to contentHTML to the next.

This means the content passed back to preview can’t be cached. And oh man oh man have I tried. :stuck_out_tongue_closed_eyes:

Stacks edit mode improves that in a bunch of ways:

  1. It only regenerates the content near the edit.
  2. Links/paths are static from one generation to the next – so can be cached.
  3. NSImages are passed with a NSURLProtocol callback which fetches the image data directly rather then writing out an image to disk and having the web view read it from disk immediately after.

I think in order to make user edits preview in roughly real-time we’ll need to add RW API calls that a tailored to preview mode that are more easily cache-able. or… thinking really outside the box here… really change up how preview content is updated.

instead of having the update loop look like this:

plugin: broadcast page changed
rw: request content from plugin
plugin: render content
rw: replace all content in preview

make it look more like:
plugin broadcastPluginChangedWithPreviewDOMNode:(NSString *)html

plugin: broadcast DOM node changed – with change
rw: replace just that DOM node in preview

with a fallback to do the regular stuff when necessary

1 Like

Hey, can you provide some more information here? Which params are changing for you? Can you provide some examples of the changes you’re seeing?


if a user previews, then publishes, then contentHTML will be called once for each of those and pretty much everything changes

What about if the preview is generated 10-20 times before publishing? Does anything change between those previews?

if the user changes something (page hierarchy, folder name, publishing settings, or whatever) they’ll obviously change — but i don’t see what you’re driving at.

my point is the params dict is not easily cached. it contains many complex mutable objects that can’t be persisted or copied without side effects.

nor can i be sure if/when it has changed.
and even if i can detect some changes, i can’t be sure how those changes might effect the behavior of the RWHTML exporter or other API calls that are dependent on the params.

and all those things will change the exported content. yes, it’s mostly just links and paths — but for most 3rd party stacks those get used a lot.

Hey Isaiah,

I’m totally up for changing up the preview system to improve it’s performance but I don’t believe it’s the biggest bottleneck at this time.

Running instruments on RapidWeaver previewing a Stacks page with a lot of images reveals the following.

Approximately 9 seconds of the 10 second preview time is spent transforming the images so I think something’s up with your caching system.

imageDataForKey: is called 3 times and each call transforms the image using CALayer.

Fixing this would result in a massive speed increase for previewing a page with a lot of images. It would also greatly affect publishing times.

I’m fairly certain there are other optimisations similar to this one that could be done, but lets start here, improve the biggest bottlenecks and then see if optimising the preview system is worth it.

The way you show it working in Stacks in your video is how I suspect users (and myself) would expect and want it to work.

Hmm, have you tired using it? I find it rather annoying as it keeps loosing focus on the item I’m editing…

Sorry I need more coffee… I was thinking at first you were referring to the fact that the preview didn’t update until after the user stopped editing a stack. Just realized you were talking about the stack losing focus. Gotcha.

(heads back to the coffee pot). :stuck_out_tongue_winking_eye:

@tpbradley - LOL. ok then! i guess that’s a no from you guys? wow.

the Stacks API often generates many variants of the same image for transforms, @2x and lots of other reasons.

or it could be a bug. feel free to post it:

for the record. i was not trying to imply that RW preview was slow – but that STACKS IS SLOW at preview – because it has to do it nearly from scratch each time.

only a tiny bit changes when the user edits content, it might be best to just update that bit instead of regenerating the whole page.


i suspect i’m just wasting my time here, i won’t post again.
let me know if you guys want my input.