Hi all, > That's reasonable. In this case I've got the impression that Klaus is > trying to implement a workaround for shortcomings in goocanvas. > Goocanvas does not handle touch events properly, and Klaus wants to > "convert" touch events to button press events. Klaus, correct me if I'm > wrong. If I'm right, the shortcomings in goocanvas should be fixed. I > don't know much about goocanvas and goocanvasmm. It may be hard to do. >
Yes, my need is actually to work around the missing implementation of touch support in goocanvasmm. But resending maybe converted signals/events can also help to fix bugs in the implementation. There is a bug in goocanvas which makes goocanvas hard to use if you open a dialog from a event send to a goocanvas item. There is something mysterious in pointer grabbing which can not so easily fixed by other workarounds. Sending a key release event manually helps here a lot. I agree that wasting an interface with internals is not a good idea if 99% of all usecases could be covered by a well designed smaller interface. On the other hand I believe that a emit() function for a signal/event should be part of a well designed interface, especially because of the analogy of glib and libsigc++. From the users view a single implementation for signal handling would be the smallest interface :-) But I know the problem of historic implementations and braking interfaces... Actually going down on c level from c++ is a work around which is not very easy for me. gtk is quite new to me and reading all the glib/gtk/gtkmm and all related docs is a lot work. And there are a lot of undocumented features which a user must use on this way. So I give my voto for a emit() function :-) Regards Klaus _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
