Closed lafoletc closed 3 years ago
Test here currently failing. Not sure this is the right approach, and not sure the data type is correct - enums in GLib not long?
We can currently pass int to set()
or enum name to setAsString()
. I don't really like the mismatch when calling get()
. But if we do this, maybe convert any NativeEnum to its int value at the start of the method? And document that this will happen for convenience, but that get()
will return an int?
Please be careful not to reorder imports. I know we inherited a mess! At some point we should sort them out, but please not in PRs for other things.
Merged master to pick up GitHub Actions for testing.
Still more inclined to the option at #216 for now. This whole aspect, mapping Java types to types in GValue / property needs rethinking anyway. Thoughts? What exactly is the issue for you that you're trying to resolve?
Hello, my modifications only extract the int from the NativeEnum. Now GObjet::set can accept an enum thar implement NativeEnum Regards
Yes, I realise what it does, and would rather implement like #216 More interested in what your use case is? Something missing in the code here, or in your code? I turned down an earlier request for this functionality, but will consider merging. Still think it's the wrong approach in most cases - if you've mapped a NativeEnum you should also have implemented a proper API to accept (and return!) it, not be relying on GObject::set.
Thanks, but closed in favour of #216
Allow to use an enum which implements NativeEnum to set a property