On Tue, 2013-03-26 at 11:50 +0100, Murray Cumming wrote:
> On Tue, 2013-03-26 at 11:30 +0100, Murray Cumming wrote:
> > Well, they are listed as "derived Interfaces", because they "require"
> > the GTlsConnection type. Or, in other words, it is a "Prerequisite".
> > See
> > the G_DEFINE_INTERFACE() lines. Looking at all these made me notice
> > some
> > similar things we should fix some time:
> > https://git.gnome.org/browse/glibmm/commit/?id=c43ced750b04b8ae0556e8dfe317a4dbb6da327f
> >
> > For GTlsConnection it's a bit odd, because GTlsConnection is not an
> > interface, though GTlsClientConnection and GTlsServerConnection are. I
> > guess the glib developers are aware of the oddness of this, having
> > consciously chosen to give their interfaces some default
> > implementation.
>
> Some more thoughts:
>
> I think we generally only want to represent the "preequisite" as a C++
> inheritance when it's an interface depending on an interface. When it's
> an interface requiring an actual type then it doesn't seem useful to us.
>
> For instance:
> * GtkActionAble requires GtkWidget (rather than the default GObject).
> We have a TODO to add Actionable as a base class of _all_ derived
> Widgets, because they _implement_ that base interface.
>
> * GtkAppChooser requires GtkWidget (rather than the default GObject)
> AppChooserButton derives from, and implements, GtkAppChooser.
>
> * GtkFileChooser requires GtkWidget (rather than the default GObject)
> GtkFileChooserDialog derives from, and implements GtkFileChooser.
I see. I think I understand now. For an interface, most likely it will
not do much good to derive from a type that it requires if that type is
not an interface.
>
> Now, TlsClientConnection (an interface) requires TlsConnection (not an
> interface), so we could choose to treat this like GtkFileChooser
> requiring GtkWidget. To decide, I think we need to see how the types are
> used polymorphically, if at all.
>
> But I don't actually see any use of any of these types in the rest of
> the API, so it's hard for me to judge. I am tempted to not wrap them for
> now.
I could find no examples either. I had tried to write my own (based on
what the C API's TLS Overview description section explains) which I'm
attaching, but I didn't get far (I only get an exception). I guess it's
fine not to wrap these either until it is more clear how they can be
used.
--
José
#include <giomm.h>
#include <iostream>
#include <cstdlib>
int main(int, char**)
{
Gio::init();
std::vector< Glib::RefPtr<Gio::InetAddress> > inet_addresses =
Gio::Resolver::get_default()->lookup_by_name("www.google.com");
for(unsigned i = 0; i < inet_addresses.size(); i++)
{
std::cout << "Address #" << i << ": " << inet_addresses[i]->to_string() <<
"." << std::endl;
Glib::RefPtr<Gio::Socket> socket =
Gio::Socket::create(Gio::SOCKET_FAMILY_IPV4, Gio::SOCKET_TYPE_STREAM,
Gio::SOCKET_PROTOCOL_TCP);
Glib::RefPtr<Gio::InetSocketAddress> address =
Gio::InetSocketAddress::create(inet_addresses[i], 443);
socket->connect(address);
if(!socket->is_connected())
{
std::cout << "Could not connect socket to " <<
address->get_address()->to_string() << "." << std::endl;
continue;
}
Glib::RefPtr<Gio::TcpConnection> conn = Glib::RefPtr<Gio::TcpConnection>::cast_dynamic(Gio::SocketConnection::create(socket));
if(conn && conn->is_connected())
{
std::cout << "Successfully established connection to " <<
address->get_address()->to_string() << ":" << address->get_port() <<
"." << std::endl;
try
{
Glib::RefPtr<Gio::TlsClientConnection> tls_connection =
Gio::TlsClientConnection::create(conn, address);
}
catch (const Gio::TlsError& error)
{
std::cout << "Exception caught: " << error.what() << "." << std::endl;
return EXIT_FAILURE;
}
conn->close();
}
}
return EXIT_SUCCESS;
}
_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
