Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support IMap and IMapView #530

Merged
merged 36 commits into from Aug 5, 2022
Merged

Support IMap and IMapView #530

merged 36 commits into from Aug 5, 2022

Conversation

halildurmus
Copy link
Member

@halildurmus halildurmus commented Jul 15, 2022

Closes #486

  • Adds support for IKeyValuePair, IMap, and IMapView interfaces
  • Adds PedometerStepKind enum (used as a key type for the above interfaces)
  • Adds PropertySet, MediaPropertySet, StringMap and ValueSet classes (implementations of the IMap)
  • Adds NotificationData class

After we land this, I'll send a PR that will include support for Windows.Data.Json and tests for IMap<String, IJsonValue?>.

As for the IMap<Object, Object?> type, I haven't been able to test it as the ResourceDictionary is the only API that supports it, and I think it only works in UWP apps.

@halildurmus halildurmus added enhancement New feature or request winrt labels Jul 15, 2022
@halildurmus halildurmus added this to In progress in WinRT projection via automation Jul 15, 2022
Comment on lines +89 to +102
@override
bool operator ==(Object other) {
if (identical(this, other)) return true;

return other is GUID &&
other.Data1 == Data1 &&
other.Data2 == Data2 &&
other.Data3 == Data3 &&
other.Data4 == Data4;
}

@override
int get hashCode =>
Data1.hashCode ^ Data2.hashCode ^ Data3.hashCode ^ Data4.hashCode;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These overrides are required for Map<GUID, XX> types (e.g. Map<GUID, Object?>) to work properly.

/// Gets the key of the key-value pair.
K get key {
if (isSameType<K, GUID>()) return _key_GUID as K;
if (isSameType<K, int>()) return _key_Uint32 as K;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used Uint32 for int keys since it is the only int type to be supported for IKeyValuePair: https://github.com/timsneath/win32/blob/339c6e4ac04a9d2f2c1933c958bc0893be65dee2/lib/src/winrt_constants.dart#L147-L148

Comment on lines +217 to +218
V get _value_enum {
final retValuePtr = calloc<Int32>();
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Used Int32 here for enum values since all supported enum types for IKeyValuePair are Int32 type (e.g. AppCapabilityAccessStatus, ChatMessageStatus).

@halildurmus halildurmus marked this pull request as ready for review July 17, 2022 16:18
Copy link
Contributor

@timsneath timsneath left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an astonishing piece of work. You have outclassed me! I've been busy in my free time fixing up another package that I own which has bitrotted a little, so I'm thrilled to see you continuing to make progress here. A few comments inline to check out.

At some point, we need to converge on a release, since there are folk waiting on more mundane fixes (e.g. some of the Win32 APIs that have been added over the last couple of months. I'm thinking of shipping a 3.0.0-pre based on what we've got so far to help out those who are waiting, and then we can keep iterating until you feel the new WinRT projection has settled down. WDYT?

}
}

PedometerStepKind get _key_PedometerStepKind {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgive me, but this seems weird here. Why would such a specific type as PedometerStepKind be embedded in a generic collection object like this? There could be hundreds of these, couldn't there? What if we decide (as is likely) to partition Windows.Device.Sensors into a different export from Windows.Foundation.Collections?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here are the supported key-value pairs of IKeyValuePair according to IIDs taken from here:
https://github.com/timsneath/win32/blob/339c6e4ac04a9d2f2c1933c958bc0893be65dee2/lib/src/winrt_constants.dart#L62-L148

According to these, there is only one enum type (PedometerStepKind) used as a key type of IKeyValuePair. It seemed easier to handle it this way instead of adding a new parameter (keyCreator) that takes an enum constructor for the key type of ÌKeyValuePair which will allow me to create an instance of that enum type.

I can modify the implementation to handle these types with the keyCreator parameter I mentioned above if that's what you want.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if the best thing is to make the PedometerStepKind pieces an extension method in winrt/device/sensors? I don't know that this is the right answer, but it does feel like a very odd outlier. Are there other classes that might have a similar pattern, I wonder?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if the best thing is to make the PedometerStepKind pieces an extension method in winrt/device/sensors?

I've created extension methods for the PedometerStepKind pieces but I'm not sure if it's the way you wanted it. Could you take a look?

Are there other classes that might have a similar pattern, I wonder?

I don't think there are.

@@ -38,6 +33,93 @@ class IPropertyValue extends IInspectable {
factory IPropertyValue.from(IInspectable interface) =>
IPropertyValue.fromRawPointer(interface.toInterface(IID_IPropertyValue));

Object? get value {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if this should be implemented by keeping the interface autogenerated but adding an extension method for this helper method? The more that is autogenerated, the better, obviously -- both less prone to errors and more likely to catch errors in the generation. WDYT?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that makes sense. Before doing that, I need to modify the generator to fix the deallocation bug I mentioned below.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@@ -363,24 +445,18 @@ class IPropertyValue extends IInspectable {
GUID getGuid() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this deallocation a bug in the generator code? Or is this fix unique to this interface?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this deallocation a bug in the generator code?

Yeah, it is a bug in the generator. retValuePtr should not be freed for structs (just like for COMObjects).

I don't know how can we avoid memory leaks from these as NativeFinalizer cannot be used with structs.

@halildurmus
Copy link
Member Author

This is an astonishing piece of work. You have outclassed me! I've been busy in my free time fixing up another package that I own which has bitrotted a little, so I'm thrilled to see you continuing to make progress here. A few comments inline to check out.

Thank you!

At some point, we need to converge on a release, since there are folk waiting on more mundane fixes (e.g. some of the Win32 APIs that have been added over the last couple of months. I'm thinking of shipping a 3.0.0-pre based on what we've got so far to help out those who are waiting, and then we can keep iterating until you feel the new WinRT projection has settled down. WDYT?

That's a great idea. I saw your comment and I think these are great. I'll let you know if I come up with something to add there.

WinRT projection automation moved this from In progress to Reviewer approved Aug 5, 2022
Copy link
Contributor

@timsneath timsneath left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@timsneath timsneath merged commit c35d945 into main Aug 5, 2022
WinRT projection automation moved this from Reviewer approved to Done Aug 5, 2022
@timsneath timsneath deleted the map-mapview branch August 5, 2022 23:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

Support IMap & IMapView
2 participants