win32
win32 copied to clipboard
halildurmus
[Proposal] Add support for WinRT Windows.Devices.Geolocation APIs
Description
Hey Tim, currently as a part of GSoC'20 we are trying to land new samples in the samples repo to help developers understand how to develop a federated plugin and use platform channels. For the federated plugin sample, we have decided to expose Geolocations APIs on different platforms, and currently, we are looking at the possibilities to add the support for windows too.
It would be great if we can provide the support for GeoLocator API to fetch the current location in win32.
cc:/ @domesticmouse
Hey Tim,
I'm curious where the IDL files under https://github.com/timsneath/win32/tree/master/tool/generate/winrt come from? I'm guessing to implement the extension that @AyushBherwani1998 requires involves finding the IDL that contains the Windows.Devices.Geolocation APIs and re-running your code generation tooling?
brett
Hi Ayush! I think you're on the right track here, in terms of the API to implement. Unfortunately geolocation is a particularly hard example to use here.
- The (traditional, easy to interop) win32 APIs are useless at this point. They were designed in an era when Microsoft included a GPS USB dongle with every copy of the Streets & Trips CD-ROM. And even if you still had one of those dongles, the device drivers are largely obsolete.
Windows.Devices.Geolocationis the right API -- specifically this one.
Unfortunately, there are some obstacles. While WinRT APIs can technically be called from Dart, you're pushing up against the limits of what I've achieved so far because this is an async API.
I have implemented a brute-force parser that converts some WinRT IDL to a Dart representation of a COM object, but aside from the poor-quality code (no flex/bison here), there are fundamental limitations to this approach, not least that many WinRT objects aren't documented as IDL.
Based on conversations with the Windows team, I've been advised to instead directly interrogate the CLI metadata database, which is what other language projections do. I've made great progress there with a separate tool, but this is far from easy because the spec is mostly "here's a binary BLOB that you can spelunk into". As a result, I now have some WinRT classes available from Dart, e.g. Windows.Globalization.Calendar. But I haven't yet figured out how to do the async callback, which is needed for a large percentage of WinRT APIs.
I don't know how much time you have for this, but I'm happy to spelunk with you. Failing that, I'd suggest that there are other plugins where a Windows federated version is much easier -- some of which already have primitive solutions available for you to work from (e.g. FilePicker). I'd be happy to add you as a collaborator if you wanted to take that one over and bring it to completion.
I see the obstacles over here, being not very good with the C++, and windows application development, this is something I would like to try and explore over the period of time, hence this would be a great opportunity for me to work with you on this and learn.
I have one more month left for the GSoC, but if it takes more time to explore the possibilities, I would be more than happy to keep contributing to the samples after the GSoC. In the meantime, I'll also try to write native code, and call it using platform channel which will also help developers to understand how to perform platform calls for C++.
Unfortunately, we have already landed the implementation for Android, and web, so I'll discuss the File Picker plugin with Andrew in the call next week. But if we are thinking it to be another example for the developers to develop federated plugin, I'm happy to contribute.