Rapidweaver Version 8.1.4 (20642)
macOS Mojave Version 10.14.3
Before the latest update of Rapidweaver 8, I was able to apply ‘Format> Ignore Formatting’ to a Text Stack with a selected text. The color then turned purple.
Now the color is no longer purple, but the text remains black, but according to the menu ‘Format> Ignore Formatting’ it has been applied.
I’ve managed to reproduce this and while a change in RW8.1 has caused this problem to presented itself, I believe it to be an issue in the Stacks plugin.
Hmmmm… it definitely only seems to happen in Stacks. So that makes it look like it’s probably a Stacks bug.
… but …
Stacks hasn’t had a new version since November. So maybe we should do some deeper checking…
I installed Stacks 3.6.5 into a few versions of RW and here’s what happened:
RW 7.5.3:
RW 8.0.0:
RW 8.0.3:
RW 8.1.0:
I also tried Blocks, since it uses the same RW api:
RW 7.5.3:
RW 8.0.0:
RW 8.0.3:
RW 8.1.0:
So, it seems like perhaps that API might have been changed in RW 8.1 – and that change broke things.
I’ve done a bit more digging, and it seems to me that the problem is somewhere around the RWTextView API. I can use an RWTextView – but… I think… when it gets hooked up to normal delegates for noticing changes and such – that’s when it breaks.
Anyway, I think I’ll leave it at that for now.
@tpbradley - I know that RW8.1 changed quite a few things in Styled Text. Perhaps you could have a look to see if you might have caused this.
If you can’t find it, I can probably provide more info – but I’ve now spent most of the day working on this – and all indications point to this being outside of my control – and probably not something that I can work around. So I think the ball is probably in your court now. If you need some info from me, please let me know.
For everyone else, I’m afraid I don’t really have a workaround for you at the moment, and all indications point to this as something I don’t have control over in my code.
So if you need this feature of RW then I’d recommend sticking to RW 8.0.3 for now. I know that’s a terrible solution and that RW 8.1 writes files the aren’t readable by prior versions of RW8, which makes going backwards, even within this same version, almost impossible.
I will do my best to hunt for some workaround to this.
One more thing: For 14 years I’ve used Style Text in my plugins to maintain seamless compatibility with other plugins within RW. However RW Styled Text is getting a bit long in the tooth and, if my support inbox is any judge, has had quite a few issues recently. It may be time to move on to a more modern text editing engine – and perhaps just support RapidWeaver Styled Text as a secondary compatibility option.
OK. I’m not sure how that concerns me. But sounds good.
Not to my knowledge. I’m definitely not doing anything with temporary attributes on purpose.
I am not replying to this delegate message.
I do, however, set my controller to be the layout delegate of the text view. This seems pretty normal, however. I use the layout manager to get notified when the height of the view needs to change – something that’s really necessary for both Stacks and Blocks.
If RWTextView needs me to stop using the layout manager delegate then… well… we’re probably in a real bind.
That’ll be it, RWTextView has always assumed it’s the layout delegate so if you’re changing that things are gonna break. Can you implement the method in your delegate and call one in RWTextView?
Not sure how you expect me to use a text view in a complex app with a layout manager delegate – it’s not exactly optional.
Seems like if you’re going to steal the layout manger then you aught to provide a pass-through delegate like RWTextViewLayoutManagerDelegate – or better yet, just subclass the layout manager and do your business there directly. Either way, whatever view controller that’s using this text is is probably going to need some access to those methods.
I guess. That seems pretty upside down. It means any developer that is using this API needs to have that special information just to use this class. But I can give it a try if you want – but I don’t really have time for all this messing around
- (NSDictionary<NSAttributedStringKey, id> *)layoutManager:(NSLayoutManager *)layoutManager shouldUseTemporaryAttributes:(NSDictionary<NSAttributedStringKey, id> *)attrs forDrawingToScreen:(BOOL)toScreen atCharacterIndex:(NSUInteger)charIndex effectiveRange:(NSRangePointer)effectiveCharRange {
NSDictionary<NSAttributedStringKey, id> *outAttrs = attrs;
id <NSLayoutManagerDelegate> tv = (id <NSLayoutManagerDelegate>)[self textView];
if ([tv respondsToSelector:@selector(layoutManager:shouldUseTemporaryAttributes:forDrawingToScreen:atCharacterIndex:effectiveRange:)]) {
outAttrs = [tv layoutManager:layoutManager shouldUseTemporaryAttributes:attrs forDrawingToScreen:toScreen atCharacterIndex:charIndex effectiveRange:effectiveCharRange];
}
return outAttrs;
}
whelp, it’s ugly. it’s backwards. it’s all kinds of wrong. but there you go. enjoy.
maybe put that in the API docs so other devs know they’ll need to do this too.
i guess i’ll try to update my plugins sometime to fix “my bug”
Pardon the impertinence of this comment but . . . I am a happy Rapidweaver user (couple of bumps with v8) - and a very happy Stacks user (with a large library of stacks). But based on reading this thread I would vote for @Isaiah to move on to a more modern text engine. Doesn’t seem like RealMac is going to address the RW Styled Text issue any time soon.
Thanks Isaiah…going above and beyond again. Yes new and modern is the way to go.
Not sure what is going on with Realmac…??
As a long time supporter and advocate of RW, the team at Realmac…in my humble opinion…seem to have taken their eyes off the ball and for the first time I am concerned about the long term future of RW.
Like many of you, I have put a great deal of investment (both time and money) into RW and have purchased many stacks and plugins…and I mean many…over 200 at last count! So I really don’t want to move to Wordpress or another platform.
I would love to hear from Dan and his team about what they have planned for RW and where they see it going in the long term.
I am very grateful to Realmac and all the devs that have made RW what it its today. I hope I’m not being too negative…just letting you know how I feel and my concerns for RW.
Having read Toms comments to Isaiah before he himself decided to grow up and delete them, I’m very concerned about the working relationship between RM and Yourhead, as it certainly seems to be less than rosey.
Either Tom lacks all social skills and DOESN’T represent RM (in which case he needs kept away from real people), or he does and there is a serious rift happening, which bodes very badly for everyone going forward.
You two need to take this shit private, it looks bad on everyone (mainly Tom and RM though).
Many if not most RapidWeaver users are professional web developers, and RW is our primary tool. We are wholly dependent upon RW.
YourHead and @isaiah have done more to expand the utility of RW with the addition of the Stacks Plugin, which in turn led to the development of Stacks developers such as @joeworkman, @Doobox, @willwood, @yuzool–which expanded the developer community beyond just theme developers.
Theme development has slowed to a trickle.
Not sure who @tpbradley is exactly. Didn’t know of him prior to all the troubles with 8.1 and beyond.
@tpbradley, @dan, @bon, I’d encourage you to take notice of the overwhelming RW community support for @isaiah. It’s strong evidence of brand loyalty. .
Rolling out the change for this in a Stacks beta. It will get automatically posted to the beta auto-update feed as soon as all the automated tests pass. It’s about a third of the way through – so 10 minutes tops. If you’re not on the beta feed you can jump over to http://slack.yourhead.com and the download it directly. I’ll post the link there.
Update: new version passed tests on RW7.5-RW8.1. Let me know if the fix works for you.
After a few days in beta I’ll post it to everyone else too. It’s a very minor change, so there probably won’t be any complications that arise in beta testing.
The fix for Blocks will take me a bit longer. That one is a bit more involved because the code there is so old. I have to blow off the dust first.
And don’t worry about the back and forth. It’s no big deal. Always better to swim with the current than against it.
