Den 2014-12-18 11:57, Klaus Rudolph skrev:Me neither. I'm Swedish.Hi Kjell, thanks for your respond! I got already this and some more hints from Damon Chaplin. By digging through all these underlying functionality I got now some minimal experience how signal distribution works in gtk. But the great picture is still missing. I think the software is great but the documentation have a lot of black regions :-). Maybe you have some spare time to answer some questions, maybe I am able to write some little text for the docs later ( but I am not a native English speaker!). Both libsigc and glib have signalling systems. They are totally separated. It might get a bit confusing in glibmm and gtkmm, because they use other parts of libsigc, e.g. sigc::trackable. Signals in glibmm and gtkmm correspond to signals in glib and gtk+.Maybe you can comment the following points for me?: One of the things I wonder about: In gdk there is no way to simply say emit() to a signal. libsigc has this functionality and for a user it is very mysterious to understand that gdk event is not a child of libsigc signals. On toplevel view it looks nearly the same, but under the hood it is more or less two different ways of signal distribution. On the gtkmm side there is a lack of functionality I think, maybe only for the documentation, but the missing signal_emit_by_name() method for widget is one point of this domain. As you've seen by now there are emit functions in glib. I don't know why none of them have been wrapped in a C++ method in glibmm. If it shall be added, I think the most natural location is in the Glib::SignalProxy classes. Then you could emit a signal with a call such as bool handled = widget->signal_button_press_event().emit(event); If you like, you can file a bug in Bugzilla and suggest it should be added. I don't know if there is a good reason for not doing it. Have you seen the gtkmm tutorial?The next thing is the "missing big picture" which I have found no docs on it. Where are events from x are catched and how will they be routed through gdk and gtk. Which widget/window will "see" the signal/event and how will it processed until it reaches the element which has the focus? From other gui frameworks I know 2 totally different ways: 1) A signal distribution instance "know" which element has the focus and all signals will be distributed to the focused element. 2) All signals processed through the whole tree of elements like: root-window -> first embedded window -> maybe a frame of elements -> element witch focus .... an so on. Each of these elements can catch the event and "say" I have processed it. If not, it goes through the chain of elements until it reaches the last one. In this way every element in the chain can do some kind of event/signal filtering, maybe for catching key-press events or what else. For me it is not clear in which way signals/events, especially these coming from X, are processed in gtk. https://developer.gnome.org/gtkmm-tutorial/stable/index.html The Keyboard Events chapter and the Signals appendix have a lot of information about signals. Help with the documentation would be most welcome.My next question arises as I try to forward own signals ( for touch events not supported in goocanvas I tried to make mouse-events from touch events and reinject them in the signal distribution. But I found out, that signal_emit_by_name will send the event/signal only to the addressed widget/window. So this function is not the entry point to the signal distribution logic which pass the signals from X up to the different widgets. I digg a bit in the sources ( widget.c and others ) to find how it works. But a lot of C-Macro code, especially for generating enums makes it a bit hard to walk through the code :-). ctags was not able to get a full tag list for a source code walk. So I tried to compile all the things from scratch... OK, after 5 hours of downloading things with the jhbuild tool I stopped the tool because my disk space run out ;). Ok, this is the moment to buy a normal disk ( I only run on a small partition on a external hd , which is not a good idea for buil ding the things myself). What I really miss is some documentation about the internal structures of the code and the general architecture. Maybe a reduced call graph for event processing would be a great help ( I think not only for me:-) ). I know that writing code is much cooler then writing documentation. But I as a user need so much time by reverse engineering the code and I believe that this is frustrating many other users also. So maybe I could help to write some docs if you give me the technical informations and the first setup of how docs are written/formatted and which tools are supported. Maybe a simple call graph with plantUML can help a lot? So if I can help a little bit, let me know. But remember: I am not a native speaker and all must be translated to "real English" :-) Regards Klaus The gtkmm-documentation package contains the gtkmm tutorial and the example programs it refers to. It can be downloaded and built with jhbuild. (Use make check to build the example programs.) The text is stored in one big XML file. It's converted to html by Docbook. There are probably special editors you can use for the XML file, but so far I've used gedit. Kjell |