Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report for Bug 8967 on
GitHub or Developer Community if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
GLib.Object.GetProperty and GLib.Object.SetProperty are protected in Gtk#, whereas their equivalents in other languages, including the original C API, make those calls public (see. e.g. http://www.gtk.org/api/2.6/gobject/gobject-The-Base-Object-Type.html#g-object-set).
The decision to make them protected was deliberately made as they were originally public and then made protected in this commit: https://github.com/mono/gtk-sharp/commit/1a1f5e1702dd7b9b67ef4973577f48e806e83d7b. The commit author didn't provide a reason for this change though.
A possible reason might be type safety as described by the java-bindings reference page (http://java-gnome.sourceforge.net/doc/api/4.1/org/gnome/glib/Object.html):
"The use of a String property name is, of course, insanely type-unsafe, which is why we don't expose it in our public API. Luckily, though, in general it is not necessary to use this at all, as most GObjects provide convenience methods for such things, and should be used in preference wherever available."
However, if you still need access to them, you can always create a subclass and add public access (as long as it's not a sealed class).
I personally would vote to close this issue as invalid, because it would open the doors for unsafe programming and this is just not what C# programming is about.
Thank you for your answer. I interpret it as follows:
* It is not your intention to expose all Glib features.
* You believe you know better what programmers who use your libraries should be allowed to do.
If I recall correctly, I submitted this bug report because I needed to have full Glib object introspection capabilities for my project (a reactive framework on top of GTK). Subclassing every single GTK class is not an option in this case obviously, as I would need to also work with objects created outside of my project.
I fully understand your point of view, even if it makes building certain classes of libraries impossible. Thankfully, I haven't wasted much time on the idea and—given how much time has passed since then, I'm sure you'll understand that I'm not interested in it anymore. Therefore I'm fine with closing this issue, if you will.
Although it's not relevant for you anymore, I'd like to add that in this case you might had been able to leverage C#'s reflection capabilities to achieve this.
I'd also like to clarify that I was just posting observations and stating my opinion (and the opinion of the java-bindings dev I cited) in comment #1. I'm not a member of the core dev team of mono/gtk-sharp, just an occasional contributor. However, I *think* there have been design decisions made that favour some use cases over others, namely desktop app development vs. building libraries that deeply integrate with glib-sharp (which doesn't necessarily mean that's impossible to do that, but not as straight forward as app development).
I also think it's sad that bug reports in the gtk-sharp module remain unattended more often than not. In an attempt to change that, I'm going through some of them right now:)
I don't have edit rights in this bug tracker, so you might close it yourself or wait for someone who has.