Unable to be used with CocoaPods about notepad HOT 14 CLOSED

Just FYI I will still get to this, but my needs for a project changed and I'm not actively blocked by this anymore so it'll be a little later on. That said this is the best-looking GUI-based Markdown renderer I've seen and I'd like to help tune it up for possible future use!

from notepad.

This was a red herring, since CocoaPods provides an umbrella header file and creates all pods as frameworks.

The real problem is that per http://stackoverflow.com/a/37089794/977220 the Notepad class isn't public by default outside of the framework. Again, it works in your example since the Notepad.swift file is present in the same module as the app.

I'll submit a PR for this. It gets complicated when you try to use a Notepad in IB, since you can't later set the themeFile in code. Making Storage also public is one fix, but that requires a bunch of other stuff be made public as well.

One idea I have here is to introduce a safe setter for themeFile on Notepad so we don't have to expose Storage, but that introduces concurrency issues with setting the themeFile on a Notepad after it's already been rendered once.

¯\_(ツ)_/¯ coding

from notepad.

Hey, thanks for the note! Can you link me to an example of a framework header, and I can create one? Or, alternatively you could open up a pull request?

from notepad.

Sure, it should just be as simple as something like this:

https://github.com/mapbox/MapboxGeocoder.swift/blob/master/MapboxGeocoder/MapboxGeocoder.h

In this project's case, maybe:

#import <UIKit/UIKit.h>

FOUNDATION_EXPORT double NotepadVersionNumber;

FOUNDATION_EXPORT const unsigned char NotepadVersionString[];

All of the Swift files should be included automatically since they are part of the module.

I'm not 100% positive this will solve the problem, but I think it should. I will try to experiment more.

from notepad.

Great, thanks! Let me know what you find, and happy to merge anything in — it doesn't hurt to have a framework header regardless!

from notepad.

Another issue here is that Theme refers to Bundle.main.path to find its JSON resources, yet the main bundle is actually the user's app, not the Notepad.framework. I have a fix for this as well.

from notepad.

Awesome, thanks. Yeah — I definitely am going to implement something with IBInspectables/IBDesignables going forward, but feel free to hack away! Looking to build this out so it's extra flexible (roadmap may include loading themes from online, who knows what the future holds).

Regarding exposing Storage, I agree with you. I found it difficult to work with NSTextStorage and the safety of Swift, in terms of the order of initialization in classes. I used a different approach in RFMarkdownTextView that I could get away with as it was Objective-C.

from notepad.

Also, debating between themeFile and theme as the variable. Thoughts?

from notepad.

theme implies a Theme will be passed, which you might also prefer to keep private. themeFile, themeName, or themePath implies a String (in the latter case, allowing you to pass your own full JSON path).

from notepad.

I agree - just checking because I hate camel case ¯\_(ツ)_/¯.

from notepad.

@incanus do you have the header for CocoaPods in git already? Because if not I have some time on my hands now and can clean some stuff up. Just let me know!

from notepad.

The header isn’t necessary—CocoaPods makes one for you when it packages your project as a dynamic framework.

from notepad.

Ah - so just adding public should work. Great, I'll do that now!

from notepad.

Fixed by 6a9e702.

from notepad.