Hi Stefan, I don't know if you've been following the list for my huge thread on a TODO list that GNUstep needs to implement for WebKit[1], but among those items are some related to CoreBase. I've scratched the surface of how to implement some of them but I'd like your two cents before I start working on it and possibly screw things up.
In order of priority from first to last, these are the issues: 1) Implement -[NSRunLoop getCFRunLoop] This one is really, really needed for WebCore to set up a lot of stuff -- and is the only one in this list we can't live without. I can think of solving this by creating a category to NSRunLoop in CoreBase that implements this method by creating a new CFRunLoop with all sorts of information we can gather from the receiving NSRunLoop. I don't know if any bizarre issues will arise, though. Does this seem sane? 2) Implement CFNotificationCenter We need CFNotificationCenterRemoveObserver() and CFNotificationCenterAddObserver() for WebCore edge cases. I would be tempted to follow the model of some current "classes" and forward these functions' behavior to NSNotificationCenter, but in this case (per the Apple documentation) the classes would not be toll-free bridgeable, so I don't know if relying on the Base implementation would be okay. If we *can* use Base, that's great, but if we can't, I'd like to know how you'd implement these functions. Also, is there any particular reason why you did not implement this? 3) Implement CFPreferences We need CFPreferencesCopyAppValue(), CFPreferencesSetAppValue(), CFPreferencesAppSynchronize(). Once again, if I could just rely on Base I'd use NSUserDefaults, but since this is not a toll-free-bridgable class (or a class at all), I wonder if that's "legal". The same question applies here: if we can't use Base, how would we do this? Note: for WebKit purposes, we don't need to access any non-app-specific user defaults, so this reduces the scope of the work that is currently needed. We can live without this because we can change WebKit not to look for preferences and just assume the default. 4) Missing CFLocale functions I suppose I can figure out the Unicode functions in CFLocale by myself to add the new functions needed by WebKit. I'll send a pull request with it in the near future. The same for preferences goes here -- we can mostly keep these functions unimplemented and assume the default. These are particularly needed by JavaScriptCore. 5) CFStringTokenizer We lack CFStringTokenizer, which is used by WebKit if it is on iOS, but since that's not the case of our build we can leave that alone for now. Aside from these ones, I am almost sure we'll need to do some bugfixes, but nothing that I can anticipate right now. Also, please let me know if there's any issue you'd like to work on so I can focus elsewhere :) -- Daniel. [1]: http://lists.gnu.org/archive/html/gnustep-dev/2017-06/msg00040.html _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev