Closed incanus closed 8 years ago
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?
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.
Great, thanks! Let me know what you find, and happy to merge anything in — it doesn't hurt to have a framework header regardless!
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
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.
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.
Also, debating between themeFile
and theme
as the variable. Thoughts?
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).
I agree - just checking because I hate camel case ¯\_(ツ)_/¯
.
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!
@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!
The header isn’t necessary—CocoaPods makes one for you when it packages your project as a dynamic framework.
Ah - so just adding public
should work. Great, I'll do that now!
Fixed by 6a9e702eb72c630d6f770ee0b5d05a095416fb73.
When used via CocoaPods, the
Notepad.framework
is built and included, but the individual classes aren't able to be used. For example,import Notepad
works just fine, but you can't use theNotepad
class in code. Perhaps this is because there is no framework header?This is in a Swift 3.0 project. I maintain frameworks of my own (e.g. Mapbox-iOS-SDK) so I'm fairly familiar with the process here, though I could be making a dumb mistake.
The
pod try Notepad
example just has theNotepad.swift
etc. files included directly in its own module, which is why it works.