Plugin Code
API Programming
01/03/06 23:17
Writing code for an API has it's tradeoffs. On one
hand, someone else has usually done all the dirty
work. Dealing with preference files, checking for
updates, and building a consistent GUI experience.
On the other hand, it means that you're forced to
live with the tradeoffs that someone else made when
deciding what the API should do.
The RapidWeaver API isn't too tough to deal with. It's pretty easy to understand the calls and replicate them for your own use. But their are some pretty rigid limitations -- well, unless you start hacking.
In Collage, the limitation is that the link-window is not meant to work for anything but a styled text view. Since Collage doesn't have a styled text view I have a real problem. After a lot of digging I eventually I found that I only really needed that textview for a little while. After gathering all the link information, I can get rid of the textview and go about my business. It sounds like no big deal now, but it took me several days of hacking, a few days just to consider if it was going to be possible, and a lot more to clean it up.
In Columns it was again the links that caused the issue. Columns has the styled-text views, but it has too many. The API was designed to work well with exactly one view. The solution was another hack. As each view is edited I catch a notification that tells me which view is currently being edited. I quickly tell the API that the view that's being edited is THE primary view.
With Blocks the link issues were solved. Now I'm faced with two new hurdles:
The first is that Blocks cannot see how the theme will be rendered. This means that I don't know how wide to make the content view, what the default font will look like, or even if the base color of the blocks is going to be light or dark. This issue is currently unsolved and research is showing that it might be unsolvable. RapidWeaver might bring lots of new API features, but I'm not holding my breath.
The second hurdle is that styled text views were not really meant to be used as blocks that can overlap. The styled text view is opaque even if you try telling it not to be. The block background really needs to be transparent, because that's how it'll be on your web page in preview mode. I tried solving this in a lot of non-hack ways but then after a while I just punted. I emailed RealMacSoftware and asked if they could put in a change because I thought it just wasn't going to be solved.
But tonight I solved this one! It's a hack, of course. Mostly it just involves swapping out the Styled Text page unless it really needs to be there, but asking it how to draw its contents -- without letting it draw the background. It's the same tack I took to hack the links in Collage, but this time with a visible entity. Here's the magic drawing routine:
I have to admit that it's a pretty obtuse drawing routine. If I don't comment that I'll forget what it does in about 2 days.
Of course this means that the edit view has become even more WYSIWYG and that means that the first hurdle is all the more irritating.
Don't look for this in the downloads folder just yet. There's still some work to be done before it's fit for human consumption again. Images don't currently share the transparency breakthrough and the differences in the margins between preview and edit are even more out of whack than they were before. I'm going to clean up for another day or two and then try to get something out that will be much more usable.
The RapidWeaver API isn't too tough to deal with. It's pretty easy to understand the calls and replicate them for your own use. But their are some pretty rigid limitations -- well, unless you start hacking.
In Collage, the limitation is that the link-window is not meant to work for anything but a styled text view. Since Collage doesn't have a styled text view I have a real problem. After a lot of digging I eventually I found that I only really needed that textview for a little while. After gathering all the link information, I can get rid of the textview and go about my business. It sounds like no big deal now, but it took me several days of hacking, a few days just to consider if it was going to be possible, and a lot more to clean it up.
In Columns it was again the links that caused the issue. Columns has the styled-text views, but it has too many. The API was designed to work well with exactly one view. The solution was another hack. As each view is edited I catch a notification that tells me which view is currently being edited. I quickly tell the API that the view that's being edited is THE primary view.
With Blocks the link issues were solved. Now I'm faced with two new hurdles:
The first is that Blocks cannot see how the theme will be rendered. This means that I don't know how wide to make the content view, what the default font will look like, or even if the base color of the blocks is going to be light or dark. This issue is currently unsolved and research is showing that it might be unsolvable. RapidWeaver might bring lots of new API features, but I'm not holding my breath.
The second hurdle is that styled text views were not really meant to be used as blocks that can overlap. The styled text view is opaque even if you try telling it not to be. The block background really needs to be transparent, because that's how it'll be on your web page in preview mode. I tried solving this in a lot of non-hack ways but then after a while I just punted. I emailed RealMacSoftware and asked if they could put in a change because I thought it just wasn't going to be solved.
But tonight I solved this one! It's a hack, of course. Mostly it just involves swapping out the Styled Text page unless it really needs to be there, but asking it how to draw its contents -- without letting it draw the background. It's the same tack I took to hack the links in Collage, but this time with a visible entity. Here's the magic drawing routine:
[layoutManger
drawGlyphsForGlyphRange:[layoutManger
glyphRangeForTextContainer:textContainer]
atPoint:NSZeroPoint];
I have to admit that it's a pretty obtuse drawing routine. If I don't comment that I'll forget what it does in about 2 days.
Of course this means that the edit view has become even more WYSIWYG and that means that the first hurdle is all the more irritating.
Don't look for this in the downloads folder just yet. There's still some work to be done before it's fit for human consumption again. Images don't currently share the transparency breakthrough and the differences in the margins between preview and edit are even more out of whack than they were before. I'm going to clean up for another day or two and then try to get something out that will be much more usable.
|