On Tue, 2013-03-26 at 17:02 +0100, Kjell Ahlstedt wrote: > 2013-03-26 03:16, José Alburquerque skrev: > > > On Tue, 2013-03-19 at 10:23 +0100, Murray Cumming wrote: > > > I will do the .0 releases of the current glibmm and gtkmm series in the > > > next few days, to try to be in sync with GNOME, who have their .0 > > > release on March 27th: > > > https://live.gnome.org/ThreePointSeven > > > > > > So, if you have added new API, please take an extra moment to make sure > > > that you don't need to fix it quickly, because you probably can't break > > > it later. > > > > > The not so extensive newly added Tls* API is pretty much complete. I > > just thought that I would point out a couple of things that struck me as > > unusual which I think would be good to be aware of before the stable > > release goes out. Also I have one final question. > > > > > May I contribute to the confusion? I think only part of the class > structure is in glib. The rest is in a TLS backend (whatever that is). > Like so, if I mix C++ syntax with C class and interface names. > > In glib > > class GIOStream : public GObject > class GTlsConnection : public GIOStream > class GTlsClientConnection : public GInterface > class GTlsServerConnection : public GInterface > > class GTlsDatabase : public GObject > class GTlsFileDatabase : public GInterface > > In a TLS backend, e.g. glib-networking > > class GTlsConnectionGnutls : public GTlsConnection, public GInitable > class GTlsClientConnectionGnutls : public GTlsConnectionGnutls, public > GTlsClientConnection > class GTlsServerConnectionGnutls : public GTlsConnectionGnutls, public > GInitable, public GTlsServerConnection > > class GTlsDatabaseGnutls : public GTlsDatabase > class GTlsFileDatabaseGnutls : public GTlsDatabaseGnutls, public > GTlsFileDatabase, public GInitable > > > g_tls_client_connection_new() returns an instance of a class that > derives both from GTlsConnection and from the interface > GTlsClientConnection. > g_tls_server_connection_new() returns an instance of a class that > derives both from GTlsConnection and from the interface > GTlsServerConnection. > g_tls_file_database_new() returns an instance of a class that derives > both from GTlsDatabase and from the interface GTlsFileDatabase.
Thanks. That's mostly how things are presently. The exception I was getting (in the partial example I provided) was due to TLS support not being available. When I installed the glib-networking package (which was not installed in the jhbuild environment), the exception disappeared. However, now I'm getting warnings about invalid setting of properties when the Gio::TlsClientConnection is created: (process:20604): GLib-GIO-WARNING **: gtlsconnection.c:329: invalid property id 1 for "base-io-stream" of type `GParamObject' in `gtkmm__GTlsConnection' (process:20604): GLib-GIO-WARNING **: gtlsconnection.c:329: invalid property id 4 for "use-system-certdb" of type `GParamBoolean' in `gtkmm__GTlsConnection' (process:20604): GLib-GIO-WARNING **: gtlsconnection.c:329: invalid property id 2 for "require-close-notify" of type `GParamBoolean' in `gtkmm__GTlsConnection' (process:20604): GLib-GIO-WARNING **: gtlsconnection.c:329: invalid property id 3 for "rehandshake-mode" of type `GParamEnum' in `gtkmm__GTlsConnection' This is the backtrace. #0 g_log(log_domain = 0x7ffff6226d33 "GLib-GIO", log_level = G_LOG_LEVEL_WARNING, format = 0x7ffff6226d00 "%s: invalid %s id %u for \ \"%s\\" of type `%s' in `%s'") at gmessages.c:1009 #1 g_tls_connection_set_property(object = 0x7ffff00059c0, prop_id = 1, value = 0x7fffffffd260, pspec = 0x62d400) at gtlsconnection.c:329 #2 object_set_property(object = 0x7ffff00059c0, pspec = 0x62d400, value = 0x64d578, nqueue = 0x648a40) at gobject.c:1358 #3 g_object_constructor(type = 6455760, n_construct_properties = 3, construct_params = 0x64d4f0) at gobject.c:1869 #4 g_object_newv(object_type = 6455760, n_parameters = 0, parameters = 0x0) at gobject.c:1719 #5 Glib::Object::Object(this = 0x64c998, __vtt_parm = 0x7ffff7b10f88 <VTT for Gio::TlsClientConnection+40>, construct_params = ) at object.cc:231 #6 Gio::IOStream::IOStream(this = 0x64c998, __vtt_parm = 0x7ffff7b10f80 <VTT for Gio::TlsClientConnection+32>, construct_params = ) at iostream.cc:168 #7 Gio::TlsConnection::TlsConnection(this = 0x64c998, __vtt_parm = 0x7ffff7b10f78 <VTT for Gio::TlsClientConnection+24>) at tlsconnection.cc:404 #8 Gio::TlsClientConnection::TlsClientConnection(this = 0x64c990, castitem = 0x64a090) at tlsclientconnection.cc:95 #9 Glib::wrap_auto_interface<Gio::TlsClientConnection>(object = 0x64a090, take_copy = false) at ../../glib/glibmm/wrap.h:89 #10 Glib::wrap(object = 0x64a090, take_copy = false) at tlsclientconnection.cc:40 #11 Gio::TlsClientConnection::create(base_io_stream = , server_identity = ) at tlsclientconnection.cc:129 #12 main() at giomm_tls_client/main.cc:44 However, the following bug has a patch to Glib::Interface, the _CLASS_INTERFACE m4 macro and Gio::TlsClientConnection which if used would make the warnings disappear: https://bugzilla.gnome.org/show_bug.cgi?id=696671 The bug also has an updated test that shows that the Gio::TlsClientConnection class (along with the other classes, including TlsDatabase) works fine. Under the circumstances, and if the patch is accepted, I would opt for inclusion of the Gio::Tls*Connection classes because the Gio::TlsServerConnection class is wrapped just like Gio::TlsClientConnection and would work in a similar fashion. From the information you've provided and what Murray has done already, it might also be possible to include the Gio::TlsFileDatabase class although I still don't object to it not being included. There are a few things I want to point out that I think are small problems which should still be considered: 1) Because classes like TlsCertificate and TlsDatabase have methods with optional parameters and I used gmmproc's optional parameter functionality (using '{?}') to wrap those, I ran into some compiler ambiguity problems. For example, the following line using the Gio::TlsDatabase::verify_chain() method (where 'certificate' is a TlsCertificate and 'address' is a SocketConnectable): database->verify_chain(certificate, G_TLS_DATABASE_PURPOSE_AUTHENTICATE_SERVER, address); Generates the following compile error: giomm_tls_client/main.cc: In function ‘int main(int, char**)’: giomm_tls_client/main.cc:119:92: error: call of overloaded ‘verify_chain(Glib::RefPtr<Gio::TlsCertificate>&, const char [18], Glib::RefPtr<Gio::InetSocketAddress>&)’ is ambiguous giomm_tls_client/main.cc:119:92: note: candidates are: In file included from ../gio/giomm.h:133:0, from giomm_tls_client/main.cc:1: ../gio/giomm/tlsdatabase.h:317:23: note: Gio::TlsCertificateFlags Gio::TlsDatabase::verify_chain(const Glib::RefPtr<Gio::TlsCertificate>&, const Glib::ustring&, const Glib::RefPtr<const Gio::SocketConnectable>&, Gio::TlsDatabaseVerifyFlags) const ../gio/giomm/tlsdatabase.h:323:23: note: Gio::TlsCertificateFlags Gio::TlsDatabase::verify_chain(const Glib::RefPtr<Gio::TlsCertificate>&, const Glib::ustring&, const Glib::RefPtr<Gio::TlsInteraction>&, Gio::TlsDatabaseVerifyFlags) const ../gio/giomm/tlsdatabase.h:326:23: note: Gio::TlsCertificateFlags Gio::TlsDatabase::verify_chain(const Glib::RefPtr<Gio::TlsCertificate>&, const Glib::ustring&, const Glib::RefPtr<Gio::Cancellable>&, Gio::TlsDatabaseVerifyFlags) const make[2]: *** [giomm_tls_client/main.o] Error 1 make[2]: Leaving directory `/usr/src/jhbuild-sources/glibmm/tests' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/usr/src/jhbuild-sources/glibmm/tests' make: *** [check-recursive] Error 1 I don't know how to avoid it (except by specifying empty Glib::RefPtr<>() with appropriate types for the RefPtr's in such an order so that the ambiguities disappear). For example, the error would disappear if the line were changed like so: database->verify_chain(certificate, G_TLS_DATABASE_PURPOSE_AUTHENTICATE_SERVER, address, Glib::RefPtr<Gio::TlsInteraction>()); It leads me to think that the methods with optional parameters might be wrapped another way or maybe just wrapped without making the parameters optional for the time being. I don't find it highly inconvenient, but others might. The other thing is that the Gio::TlsCertificate Glib::ByteArray type properties are don't seem to be accessible. For example, a call to the Gio::TlsDatabase::lookup_certificates_issued_by() passing a certificate's "certificate" property using an expression such as "certifiate->property_certificate()" would trigger a compile error such as: In file included from ../glib/glibmm/propertyproxy_base.h:25:0, from ../glib/glibmm/propertyproxy.h:25, from ../glib/glibmm/objectbase.h:24, from ../glib/glibmm/wrap.h:26, from ../glib/glibmm/containerhandle_shared.h:26, from ../glib/glibmm/arrayhandle.h:23, from ../glib/glibmm.h:91, from ../gio/giomm.h:23, from giomm_tls_client/main.cc:1: ../glib/glibmm/value.h: In instantiation of ‘static GType Glib::Value<Glib::RefPtr<T_CppObject> >::value_type() [with T = Glib::ByteArray; GType = long unsigned int]’: ../glib/glibmm/propertyproxy.h:172:3: required from ‘T Glib::PropertyProxy_ReadOnly<T>::get_value() const [with T = Glib::RefPtr<Glib::ByteArray>]’ ../glib/glibmm/propertyproxy.h:124:30: required from ‘Glib::PropertyProxy_ReadOnly<T>::operator Glib::PropertyProxy_ReadOnly<T>::PropertyType() const [with T = Glib::RefPtr<Glib::ByteArray>; Glib::PropertyProxy_ReadOnly<T>::PropertyType = Glib::RefPtr<Glib::ByteArray>]’ giomm_tls_client/main.cc:123:78: required from here ../glib/glibmm/value.h:232:55: error: ‘get_base_type’ is not a member of ‘Glib::ByteArray’ ../glib/glibmm/value.h: In static member function ‘static GType Glib::Value<Glib::RefPtr<T_CppObject> >::value_type() [with T = Glib::ByteArray; GType = long unsigned int]’: ../glib/glibmm/value.h:232:58: error: control reaches end of non-void function [-Werror=return-type] cc1plus: all warnings being treated as errors make[2]: *** [giomm_tls_client/main.o] Error 1 make[2]: Leaving directory `/usr/src/jhbuild-sources/glibmm/tests' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/usr/src/jhbuild-sources/glibmm/tests' make: *** [check-recursive] Error 1 For now, the optional parameters can be easily fixed. I'd have to look a little further into the above error. -- José _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
