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 [hidden email] https://lists.gnu.org/mailman/listinfo/gnustep-dev |
On 30 Jun 2017, at 21:46, Daniel Ferreira (theiostream) <[hidden email]> wrote:
> > 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? I suspect that this will probably not work, because the bridging expects the two runloops to coexist. Ideally, we’d have a libdispatch-based implementation of both NSRunLoop and CFRunLoop and each would then be a fairly thin wrapper around the underling dispatch queue. > 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. Note that the POSIX 2008 xlocale extensions (which are now widely supported because the locale stuff in C++11 is ) were designed by Apple to implement most of this functionality in libc, so they should be relatively easy to implement now. It would actually be very nice to reimplement a bunch of the NSLocale stuff in terms of locale_t as well now. David _______________________________________________ Gnustep-dev mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/gnustep-dev |
Stefan wrote:
> That seems reasonable. The only problem you'll probably run into is that, from my understanding, NSRunLoop is built on top of CFRunLoop, and trying to go the opposite direction might prove difficult. For example, it is not immediately apparent to me how each iteration of the loop would be run. I assume Apple simply adds observers, sources and timers directly to the CFRunLoop inside the NSRunLoop. > Additionally, I did not write the code in CFRunLoop, and I'm only vaguely familiar with it. I think it was the author of Darling (for the life of me, I cannot remember his name, now) so you probably want to direct your question to him. CFRunLoop was one of the types that are over my head. I understand how to use it, but not how to implement it. David wrote: > I suspect that this will probably not work, because the bridging expects the two runloops to coexist. Ideally, we’d have a libdispatch-based implementation of both NSRunLoop and CFRunLoop and each would then be a fairly thin wrapper around the underling dispatch queue. I assume GS has some internal logic for NSRunLoop's implementation. I haven't looked into it (and will probably only do in the course of the next weeks), but would it seem reasonable to make CFRunLoop a wrapper around this same implementation and use this to make NSRunLoop and CFRunLoop share the same resources (i.e. same internal data structs etc.) This would require rewriting a good part of CFRunLoop, but it seems more approachable than expecting Base's NSRunLoop to depend on libdispatch. Once again, I really haven't looked into it, so this may be totally off. Just wondering whether there would be opposition even to this basic idea. > Note that the POSIX 2008 xlocale extensions (which are now widely supported because the locale stuff in C++11 is ) were designed by Apple to implement most of this functionality in libc, so they should be relatively easy to implement now. It would actually be very nice to reimplement a bunch of the NSLocale stuff in terms of locale_t as well now. It is exactly CFLocaleCopyPreferredLanguages() I'm talking about ;) This is not a priority for me since I can adapt WebKit to assume en_US or something like that as a default, but good to know a viable implementation can be done. On the medium term, I may look into it. _______________________________________________ Gnustep-dev mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/gnustep-dev |
On 1 Jul 2017, at 22:51, Daniel Ferreira (theiostream) <[hidden email]> wrote:
> > This would require rewriting a good part of CFRunLoop, but it seems > more approachable than expecting Base's NSRunLoop to depend on > libdispatch. Note that an increasing amount of Cocoa code depends on at least the main runloop having a libdispatch queue, and libdispatch runs on all GNUstep-supported platforms (including Windows - there are multiple ports, and Microsoft maintains one, though I also talked to that team a few months ago about reimplementing the libdispatch APIs on top of the Windows concurrency primitives). David _______________________________________________ Gnustep-dev mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/gnustep-dev |
> On 2 Jul 2017, at 10:07, David Chisnall <[hidden email]> wrote: > > On 1 Jul 2017, at 22:51, Daniel Ferreira (theiostream) <[hidden email]> wrote: >> >> This would require rewriting a good part of CFRunLoop, but it seems >> more approachable than expecting Base's NSRunLoop to depend on >> libdispatch. > > Note that an increasing amount of Cocoa code depends on at least the main runloop having a libdispatch queue, and libdispatch runs on all GNUstep-supported platforms (including Windows - there are multiple ports, and Microsoft maintains one, though I also talked to that team a few months ago about reimplementing the libdispatch APIs on top of the Windows concurrency primitives). While, for many years, GNUstep has had a policy of minimising external dependencies (because a common complaint was that it was difficult to install, and we wanted to minimise instrallation problems), I really don't like sending time working on or maintaining code when someons else is doing it and we can leverage their work. In that spirit, I'm very much in favour of using libdispatch where it's available and as efficient as (or better than) existing code. Of course using it without breaking existing code may be a challenge... In particular I worry about breakage on windows since libdispatch, like the I/O and event APIs in Foundation, was not designed with portability to windows in mind. It's good to hear that windows ports exist. _______________________________________________ Gnustep-dev mailing list [hidden email] https://lists.gnu.org/mailman/listinfo/gnustep-dev |
Free forum by Nabble | Edit this page |