The Battle for Wesnoth  1.17.0-dev
dispatcher.cpp
Go to the documentation of this file.
1 /*
2  Copyright (C) 2009 - 2021
3  by Mark de Wever <koraq@xs4all.nl>
4  Part of the Battle for Wesnoth Project https://www.wesnoth.org/
5 
6  This program is free software; you can redistribute it and/or modify
7  it under the terms of the GNU General Public License as published by
8  the Free Software Foundation; either version 2 of the License, or
9  (at your option) any later version.
10  This program is distributed in the hope that it will be useful,
11  but WITHOUT ANY WARRANTY.
12 
13  See the COPYING file for more details.
14 */
15 
16 #define GETTEXT_DOMAIN "wesnoth-lib"
17 
19 
21 #include "gui/core/log.hpp"
22 
23 namespace gui2
24 {
25 namespace event
26 {
27 /***** dispatcher class. *****/
28 
30  : mouse_behavior_(all)
31  , want_keyboard_input_(true)
32  , signal_queue_()
33  , signal_mouse_queue_()
34  , signal_keyboard_queue_()
35  , signal_touch_motion_queue_()
36  , signal_touch_gesture_queue_()
37  , signal_notification_queue_()
38  , signal_message_queue_()
39  , connected_(false)
40  , hotkeys_()
41 {
42 }
43 
45 {
46  if(connected_) {
48  }
49 }
50 
52 {
53  assert(!connected_);
54  connected_ = true;
55  connect_dispatcher(this);
56 }
57 
58 bool dispatcher::has_event(const ui_event event, const event_queue_type event_type)
59 {
60 #if 0
61  const bool res = dispatcher_implementation::has_handler(*this, event_type, event);
62  std::cerr << "Event '" << event << " '" << (res ? "found" : "not found") << "in queue\n";
63  return res;
64 #else
65  return dispatcher_implementation::has_handler(*this, event_type, event);
66 #endif
67 }
68 
69 bool dispatcher::fire(const ui_event event, widget& target)
70 {
71  assert(is_general_event(event));
72  switch(event) {
76 
79  &event_executor::wants_mouse_middle_double_click, signal_function>(this, &target);
80 
83  &event_executor::wants_mouse_right_double_click, signal_function>(this, &target);
84 
85  default:
86  return fire_event<signal_function>(event, this, &target);
87  }
88 }
89 
90 bool dispatcher::fire(const ui_event event, widget& target, const point& coordinate)
91 {
92  assert(is_mouse_event(event));
93  return fire_event<signal_mouse_function>(event, this, &target, coordinate);
94 }
95 
96 bool dispatcher::fire(const ui_event event,
97  widget& target,
98  const SDL_Keycode key,
99  const SDL_Keymod modifier,
100  const std::string& unicode)
101 {
102  assert(is_keyboard_event(event));
103  return fire_event<signal_keyboard_function>(event, this, &target, key, modifier, unicode);
104 }
105 
106 bool dispatcher::fire(const ui_event event, widget& target, const point& pos, const point& distance)
107 {
108  assert(is_touch_motion_event(event));
109  return fire_event<signal_touch_motion_function>(event, this, &target, pos, distance);
110 }
111 
112 bool dispatcher::fire(const ui_event event, widget& target, const point& center, float dTheta, float dDist, uint8_t numFingers)
113 {
114  assert(is_touch_gesture_event(event));
115  return fire_event<signal_touch_gesture_function>(event, this, &target, center, dTheta, dDist, numFingers);
116 }
117 
118 bool dispatcher::fire(const ui_event event, widget& target, const SDL_Event& sdlevent)
119 {
120  assert(is_raw_event_event(event));
121  return fire_event<signal_raw_event_function>(event, this, &target, sdlevent);
122 }
123 
124 bool dispatcher::fire(const ui_event event, widget& target, const std::string& text, int32_t start, int32_t len)
125 {
126  assert(is_text_input_event(event));
127  return fire_event<signal_text_input_function>(event, this, &target, text, start, len);
128 }
129 
130 bool dispatcher::fire(const ui_event event, widget& target, void*)
131 {
132  assert(is_notification_event(event));
133  return fire_event<signal_notification_function>(event, this, &target, nullptr);
134 }
135 
136 bool dispatcher::fire(const ui_event event, widget& target, const message& msg)
137 {
138  assert(is_message_event(event));
139  return fire_event<signal_message_function>(event, this, &target, msg);
140 }
141 
143 {
144  hotkeys_[id] = function;
145 }
146 
148 {
150 
151  if(itor == hotkeys_.end()) {
152  return false;
153  }
154 
155  itor->second(dynamic_cast<widget&>(*this), id);
156 
157  /* NOTE: hotkey events used to return bool to indicate was-handled status. However,
158  * every single usecase was returning true and cluttering up the code. I changed
159  * the signature to return void, but if there's ever a need to restore the bool
160  * retval on the hotkey functions, this is where it should be handled.
161  *
162  * -- vultraz, 2017-11-27
163  */
164  return true;
165 }
166 
168 {
170 }
171 
173 {
174  dispatcher.connect_signal<LEFT_BUTTON_CLICK>(signal);
175 }
176 
178 {
179  dispatcher.disconnect_signal<LEFT_BUTTON_CLICK>(signal);
180 }
181 
183 {
185 }
186 
188 {
189  dispatcher.connect_signal<NOTIFY_MODIFIED>(signal);
190 }
191 
193 {
194  // TODO: evaluate whether draw events need go in this queue position.
195  dispatcher.connect_signal<DRAW>(signal, dispatcher::front_child);
196 }
197 
198 } // namespace event
199 
200 } // namespace gui2
201 
202 /**
203  * @page event_dispatching Event dispatching.
204  *
205  * @section introduction-event_dispatching Introduction
206  *
207  * This page describes how the new event handling system works, since the
208  * system is still work in progress it might be out of date with the actual
209  * code. It also contains some ideas that might change later on. Some parts are
210  * explained in the interface and will be integrated in this document later.
211  *
212  * Since the event handling code hasn't been cast in stone yet some scenarios
213  * for solving the problem are discussed first and then the solution that is
214  * chosen in more detail.
215  *
216  * After SDL has generated and event it needs to be turned into an event which
217  * the widgets can use.
218  *
219  * @section handling_solution The implementation solutions.
220  *
221  * For the event handling we use a few use case scenarios and show the possible
222  * solutions.
223  *
224  * @subsection sample The sample window
225  *
226  * In our samples we use this sample window with the following components:
227  * - a window W
228  * - a container C
229  * - a button B
230  *
231  * These are arranged accordingly:
232  * @code
233  *
234  * ---------------------
235  * |W |
236  * | |
237  * | ----------------- |
238  * | |C |^| |
239  * | | |-| |
240  * | | ---------- |#| |
241  * | | |B | | | |
242  * | | ---------- | | |
243  * | | |-| |
244  * | | |v| |
245  * | ----------------- |
246  * | |
247  * ---------------------
248  *
249  * @endcode
250  *
251  * @subsection scenarios Possible scenarios
252  *
253  * The scenarios are:
254  * - An event that is wanted by none.
255  * - A mouse down event that should focus C and set the pressed state in B.
256  * - A mouse wheel event, which first should be offered to B and if not handled
257  * by B should be handled by C.
258  *
259  * @subsection all_queues Pass the event through all queues
260  *
261  * In this solution the event will be passed through all possible queues and
262  * tries sees where the event sticks. This following sections describe how the
263  * events are tried for this usage scenario.
264  *
265  * @subsubsection unhandled-all_queues Unhandled event
266  *
267  * - W pre child
268  * - C pre child
269  * - B pre child
270  * - W child
271  * - C child
272  * - B child
273  * - W post child
274  * - C post child
275  * - B post child
276  *
277  * @subsubsection mouse_down-all_queues Mouse down
278  *
279  * - W pre child
280  * - C pre child -> set focus -> !handled
281  * - B pre child -> set pressed state -> handled
282  *
283  * @subsubsection mouse_wheel-all_queues Mouse wheel
284  *
285  * - W pre child
286  * - C pre child
287  * - B pre child -> We can't scroll so ignore
288  * - W child
289  * - C child
290  * - B child
291  * - W post child
292  * - C post child -> Scroll -> handled
293  *
294  * @subsection chain Pass the events in a chain like fashion
295  *
296  * In this solution the events are send to the pre- and post queue of all but
297  * the last possible widget and to the child of the last widget. The pre queue
298  * will be send from top to bottom, the post queue from bottom to top.
299  *
300  * @subsubsection unhandled-chain Unhandled event
301  *
302  * - W pre child
303  * - C pre child
304  * - B child
305  * - C post child
306  * - W post child
307  *
308  * @subsubsection mouse_down-chain Mouse down
309  *
310  * - W pre child
311  * - C pre child -> set focus -> !handled
312  * - B child -> set pressed state -> handled
313  *
314  * @subsubsection mouse_wheel-chain Mouse wheel
315  *
316  * - W pre child
317  * - C pre child
318  * - B child -> We can't scroll so ignore
319  * - C post child -> Scroll -> handled
320  *
321  * @subsection evaluation Evaluation
322  *
323  * When using the first solution it's possible to drop the child queue since
324  * everything falls in pre or post. But there is a scenario that's a bit ugly
325  * to solve with the first solution:
326  *
327  * Assume there is a listbox with toggle panels and on the panel there are a
328  * few buttons, the wanted behavior is:
329  * - if clicked on the panel it should toggle, which may or may not be allowed.
330  * - if clicked on a button in the panel, we want to make sure the panel is
331  * selected, which again may or may not be allowed.
332  *
333  * With solution 2 it's rather easy:
334  *
335  * Click on panel:
336  * - W pre child
337  * - C child -> Test whether we can toggle -> handled, halt = !toggled
338  *
339  * Click on button in panel:
340  * - W pre child
341  * - C pre child -> Test whether we can select -> handled = halt = !selected
342  * - B child -> do button stuff -> handled
343  *
344  * Since for the different clicks, different queues are triggered it's easy to
345  * add a different handler there.
346  *
347  * With solution 1:
348  *
349  * Click on panel:
350  * - W pre child
351  * - C pre child -> handler 1 -> if last in queue -> solution 2 C child
352  *
353  * Click on button in panel:
354  * - W pre child
355  * - C pre child -> handler 2 -> if !last in queue -> solution 2 C pre child
356  * - B pre child -> do button stuff -> handled
357  *
358  * Not that different from solution 2, the two handlers are installed in the C
359  * pre event. But we need to manually check whether we're really the last,
360  * which means the code to check whether there are more handlers at a lower
361  * level is needed for both solutions. In solution 1 this test needs to be done
362  * twice versus once in solution 2. Also the fact that the queues for the
363  * events are processed in reverse order on the way back sounds more
364  * initiative.
365  *
366  * @section processing_raw_events Processing the raw events.
367  *
368  * This section describes how the events generated by SDL are send as our own
369  * events to the various widgets. The first step in sending an event is to
370  * decode it and send it to a registered dispatcher.
371  *
372  * - gui2::event::sdl_event_handler handles the SDL events.
373  * - gui2::event::dispatcher has the registered dispatchers.
374  *
375  * In general a dispatcher is a window which then needs to send this event to
376  * the widgets. The dispatcher is just a simple part which fires events and
377  * finds a handler for the event. This is not to the liking of most widgets,
378  * they don't want to handle raw events but get a polished and clean event. No
379  * button up and down and then try to figure out whether it needs to act as if
380  * it was clicked upon, no simply op and down to change the appearance and a
381  * click event to do the clicking actions. And don't even try to convince a
382  * widget to determine whether this up event was a single or double click.
383  * Widgets like to sleep with nice dreams and not having nightmares where SDL
384  * events haunt them.
385  *
386  * In order to remedy that problem there's the gui2::event::distributor
387  * class, it's the class to do the dirty job of converting the raw event into
388  * these nice polished events. The distributor is in general linked to a window,
389  * but a widget can install it's own distributor if it needs to know more of the
390  * raw events as still left in the polished events. At the time of this writing
391  * no widget needs this feature, but the toggle panel might need it.
392  *
393  * After the distributor has polished the event and send it on its way to the
394  * widget the dispatcher needs to make sure the event is properly dispatched to
395  * the widget in question and also notify its parents by means of the previously
396  * described event chain.
397  *
398  * @subsection sdl_event Get the SDL events
399  *
400  * The first step in event handling is getting the events in the first place.
401  * Events are generated by SDL and placed in a queue. The Wesnoth code processes
402  * this queue and thus handles the events. The part which does the first
403  * handling isn't described here since it's (secretly) intended to be replaced
404  * by the @ref gui2::event::sdl_event_handler class. Instead we directly jump to this
405  * class and explain what it does.
406  *
407  * The main handling function is @ref gui2::event::sdl_event_handler::handle_event which
408  * as no real surprise handles the events. The function is a simple multiplexer
409  * which lets other subfunctions to the handling of specific events.
410  *
411  * @todo Describe drawing and resizing once the code is stable and working as
412  * wanted in these areas.
413  *
414  * @subsubsection handler_mouse Mouse motion events
415  *
416  * If a dispatcher has captured the mouse it gets the event, no questions asked.
417  * If not it goes through all dispatchers and finds the first one willing to
418  * accept the mouse event.
419  *
420  * This means a mouse event is send to one dispatcher.
421  *
422  * @subsubsection handler_mouse_button_down Mouse button down events
423  *
424  * Turning the mouse wheel on a mouse generates both an down and up event. It
425  * has been decided to handle the wheel event in the button up code so wheel
426  * events are here directly dropped on the floor and forgotten.
427  *
428  * The other buttons are handled as if they're normal mouse events but are
429  * decoded per button so instead of a button_down(id) you get button_down_id.
430  *
431  * @subsubsection handler_mouse_button_up Mouse button up events
432  *
433  * The mouse wheel event is handled as if it's a keyboard event and like the
434  * button_down they are send as wheel_id events.
435  *
436  * The other mouse buttons are handled the same as the down buttons.
437  *
438  * @subsubsection handler_keyboard Keyboard events
439  *
440  * There are three types of keyboard events, the already mentioned mouse wheel
441  * events, the key down and key up event. When a key is pressed for a longer
442  * time several key down events are generated and only one key up, this means
443  * the key up is rather useless. Guess what, the multiplexer already drops that
444  * event so we never get it.
445  *
446  * If the keyboard event is a mouse wheel event it's directly send to the
447  * dispachting queue; either the dispatcher that captured the keyboard or the
448  * last dispatcher in the queue.
449  *
450  * If the event is a real keyboard action it's first tried as hotkey. In order
451  * to do so the target dispatcher is first determined, either the dispatcher
452  * that captured the keyboard or the last dispatcher in the queue. Then it's
453  * tried whether a hotkey and whether the hotkey can be processed. If the
454  * hotkey isn't processed the keyboard event is send to the dispatcher as
455  * normal keyboard event.
456  *
457  * The hotkey processing will have several queues (to be implemented in 1.9):
458  * - global hotkeys that always work eg toggling fullscreen mode.
459  * - main screen hotkeys, these work when one of the dialogs is shown without
460  * other dialogs on top of them. These hotkeys are for example
461  * preferences. The main screens are:
462  * - title screen
463  * - game
464  * - editor
465  * - mp lobby
466  * - map screen hotkeys, these work when a map is shown eg toggle grid. The
467  * screens are:
468  * - game
469  * - editor
470  * - local hotkeys, these are hotkeys that only work in a specific dialog eg
471  * recruit unit only works in the game screen.
472  *
473  * The queues are processed in from bottom to top in the list above, this
474  * allows an item to use a hotkey but have another handler function. Eg
475  * preferences in the editor might open another preferences dialog.
476  *
477  * @todo The hotkeys need to be implemented like above in 1.9.
478  *
479  * @todo This might change in the near future.
480  *
481  * @subsection distributor Event polishing and distribution
482  *
483  * The event distributor has the job to find the widget that should receive the
484  * event and which event(s) to send from a single event. In general an event is
485  * first send to the widget as-is, sending the raw events allows other
486  * distributors to be nested between this distributor and the intended target
487  * widget. Or the intended widget might not really be the intended widget but
488  * another distributor that wants to dispatch the event internally.
489  *
490  * However in the common cases this raw event isn't handled and the distributor
491  * needs to send the polished events. In the following sections the details of
492  * the conversion from raw to polished is described, it intentionally lacks the
493  * part of sending the raw events as well since it adds no value.
494  *
495  * A widget can capture the mouse, which means all mouse events are send to this
496  * widget, regardless where the mouse is. This is normally done in a mouse down
497  * event (for a button) so all events following it are send to that widget.
498  *
499  * @subsection mouse_motion Mouse motion
500  *
501  * This section describes the conversion from a raw mouse motion to the polished
502  * events it can generate:
503  * - @ref gui2::event::MOUSE_ENTER "MOUSE_ENTER"
504  * - @ref gui2::event::MOUSE_LEAVE "MOUSE_LEAVE"
505  * - @ref gui2::event::MOUSE_MOTION "MOUSE_MOTION"
506  *
507  * When the mouse is captured that widget will only receive motion events.
508  *
509  * If not captured the code checks whether the widget underneath the mouse is
510  * the same widget as at the last motion if event. If so that widget gets a
511  * motion event.
512  * If not the widget that before was underneath the mouse pointer (if any) gets
513  * a leave event and the widget newly underneath the mouse pointer (if any) gets
514  * an enter event.
515  *
516  * @subsection mouse_button Mouse buttons
517  *
518  * The mouse button code is a bit more complex and is separated in the various
519  * events to be send.
520  *
521  * @subsubsection mouse_button_down Mouse button down
522  *
523  * Some things start simple, so does the event of pressing down a mouse button.
524  * All it does is send the event to the widget as one of the following events:
525  * - @ref gui2::event::LEFT_BUTTON_DOWN "LEFT_BUTTON_DOWN"
526  * - @ref gui2::event::MIDDLE_BUTTON_DOWN "MIDDLE_BUTTON_DOWN"
527  * - @ref gui2::event::RIGHT_BUTTON_DOWN "RIGHT_BUTTON_DOWN"
528  *
529  * @todo Validate the code it seems a down event with a captured mouse doesn't
530  * really work as wanted. (Rare case but should work properly.) In general the
531  * mouse event handling needs testing to see whether the proper events are send
532  * all the time.
533  *
534  * @subsubsection mouse_button_up Mouse button up
535  *
536  * Simplicity ends here.
537  *
538  * @todo Document further.
539  *
540  * @subsubsection mouse_click Mouse click
541  *
542  * So the button up event has asked for mouse click, now we need to test whether
543  * the click will be a click or a double click. A double click is generated when
544  * the same widget is clicked twice in a short time and causes the following
545  * events:
546  * - @ref gui2::event::LEFT_BUTTON_DOUBLE_CLICK "LEFT_BUTTON_DOUBLE_CLICK"
547  * - @ref gui2::event::MIDDLE_BUTTON_DOUBLE_CLICK "MIDDLE_BUTTON_DOUBLE_CLICK"
548  * - @ref gui2::event::RIGHT_BUTTON_DOUBLE_CLICK "RIGHT_BUTTON_DOUBLE_CLICK"
549  *
550  * Otherwise one of the following single clicks is generated:
551  * - @ref gui2::event::LEFT_BUTTON_CLICK "LEFT_BUTTON_CLICK"
552  * - @ref gui2::event::MIDDLE_BUTTON_CLICK "MIDDLE_BUTTON_CLICK"
553  * - @ref gui2::event::RIGHT_BUTTON_CLICK "RIGHT_BUTTON_CLICK"
554  *
555  * @subsubsection double_click To double click or not to double click
556  *
557  * Wait a second, a widget has a field whether or not it wants a double click
558  * for a certain mouse button and now I see that it's bluntly ignored by the
559  * distributor. Indeed the distributor doesn't care about what the widget wants,
560  * it does what it wants and leaves the sorting out what's wanted to the
561  * dispatcher.
562  *
563  * The problem is that in the chain events are send to one widget that may not
564  * be interested in a double click, but another widget in the chain is. There
565  * are several solutions to this problem:
566  * -# Sending a click followed by a double click.
567  * -# Sending a click with a tag field that it actually is a double click.
568  * -# Send a double click and turn it into a click if the double click is
569  * unwanted.
570  *
571  * The first solution has the disadvantage that a toggle panel likes a click and
572  * double click, the first click selects the second deselects and now the
573  * deselected panel gets a double click. When the panel now checks whether it's
574  * selected it's not and might take the wrong action upon it.
575  *
576  * The second option is possible but would be rather intrusive in the code,
577  * since it would generate another event signature. Adding a signature just for
578  * this special case seemed a bit too much effort vs. gain. Also the widget
579  * needs to check whether a click is a click or a double click and choose a
580  * different code path for it. This in turn would mean a signal handler
581  * secretly might handle two events and lowers the transparency of the code.
582  *
583  * The third option also adds some special case handling but the scope is
584  * limited and only one part knows about the tricks done.
585  *
586  * The last option has been chosen and the dispatcher build the event chain and
587  * while building the chain it looks whether the widget wants the double click
588  * or not. It does this test by looking at the wants double click function and
589  * not test for a handler. The double click test function is made for this
590  * purpose and depending on the handler might again do the wrong thing.
591  * (A certain toggle panel might not want to do something on a double click but
592  * also not being deselected upon a double click. The latter to keep the UI
593  * consistent, a double click on a toggle panel might execute a special function
594  * or not, but always keep the panel selected. (That is if the panel can be
595  * selected.))
596  */
Define the common log macros for the gui toolkit.
dispatcher_callback_func< const SDL_Keycode, const SDL_Keymod, const std::string & > signal_keyboard_function
Callback function signature.
Definition: dispatcher.hpp:220
Base class for event handling.
Definition: dispatcher.hpp:307
constexpr bool is_message_event(const ui_event event)
Helper for catching use error of dispatcher::connect_signal.
Definition: dispatcher.hpp:149
void register_hotkey(const hotkey::HOTKEY_COMMAND id, const hotkey_function &function)
Registers a hotkey.
Definition: dispatcher.cpp:142
See LEFT_BUTTON_CLICK.
Definition: handler.hpp:77
bool fire_event_double_click(dispatcher *dsp, widget *wgt, F &&... params)
An SDL key down event.
Definition: handler.hpp:84
dispatcher_callback_func< void * > signal_notification_function
Callback function signature.
Definition: dispatcher.hpp:255
Base class for all widgets.
Definition: widget.hpp:49
See LEFT_BUTTON_DOUBLE_CLICK.
Definition: handler.hpp:78
See LEFT_BUTTON_CLICK.
Definition: handler.hpp:70
static bool has_handler(dispatcher &dispatcher, const dispatcher::event_queue_type queue_type, ui_event event)
A helper to test whether dispatcher has an handler for a certain event.
constexpr bool is_general_event(const ui_event event)
Helper for catching use error of dispatcher::connect_signal.
Definition: dispatcher.hpp:47
std::enable_if_t< is_general_event(E)> disconnect_signal(const signal_function &signal, const queue_position position=back_child)
Disconnect a signal for callback in set_event.
Definition: dispatcher.hpp:523
static void msg(const char *act, debug_info &i, const char *to="", const char *result="")
Definition: debugger.cpp:110
dispatcher_callback_func<> signal_function
Callback function signature.
Definition: dispatcher.hpp:198
constexpr bool is_touch_motion_event(const ui_event event)
Helper for catching use error of dispatcher::connect_signal.
Definition: dispatcher.hpp:109
bool has_event(const ui_event event, const event_queue_type event_type)
Definition: dispatcher.cpp:58
Generic file dialog.
Definition: field-fwd.hpp:23
Sent by a widget to notify others its contents or state are modified.
Definition: handler.hpp:89
The message callbacks hold a reference to a message.
Definition: message.hpp:45
std::function< void(widget &dispatcher, hotkey::HOTKEY_COMMAND id)> hotkey_function
Hotkey function handler signature.
Definition: dispatcher.hpp:290
void connect()
Connects the dispatcher to the event handler.
Definition: dispatcher.cpp:51
constexpr bool is_keyboard_event(const ui_event event)
Helper for catching use error of dispatcher::connect_signal.
Definition: dispatcher.hpp:99
void connect_signal_notify_modified(dispatcher &dispatcher, const signal_notification_function &signal)
Connects a signal handler for getting a notification upon modification.
Definition: dispatcher.cpp:187
EXIT_STATUS start(const std::string &filename, bool take_screenshot, const std::string &screenshot_filename)
Main interface for launching the editor from the title screen.
Definition: editor_main.cpp:30
void connect_signal_mouse_left_click(dispatcher &dispatcher, const signal_function &signal)
Connects a signal handler for a left mouse button click.
Definition: dispatcher.cpp:172
Periodic redraw request.
Definition: handler.hpp:50
bool execute_hotkey(const hotkey::HOTKEY_COMMAND id)
Executes a hotkey.
Definition: dispatcher.cpp:147
constexpr bool is_mouse_event(const ui_event event)
Helper for catching use error of dispatcher::connect_signal.
Definition: dispatcher.hpp:72
void disconnect_dispatcher(dispatcher *dispatcher)
Disconnects a dispatcher to the event handler.
Definition: handler.cpp:898
This file contains the definitions for the gui2::event::message class.
void connect_dispatcher(dispatcher *dispatcher)
Connects a dispatcher to the event handler.
Definition: handler.cpp:891
constexpr bool is_touch_gesture_event(const ui_event event)
Helper for catching use error of dispatcher::connect_signal.
Definition: dispatcher.hpp:119
void connect_signal_mouse_left_double_click(dispatcher &dispatcher, const signal_function &signal)
Connects a signal handler for a left mouse button double click.
Definition: dispatcher.cpp:182
std::string id
Text to match against addon_info.tags()
Definition: manager.cpp:215
bool wants_mouse_right_double_click() const
std::map< hotkey::HOTKEY_COMMAND, hotkey_function > hotkeys_
The registered hotkeys for this dispatcher.
std::enable_if_t< is_general_event(E)> connect_signal(const signal_function &signal, const queue_position position=back_child)
Connect a signal for callback in set_event.
Definition: dispatcher.hpp:506
bool connected_
Are we connected to the event handler.
A left mouse button double click event for a widget.
Definition: handler.hpp:64
Holds a 2D point.
Definition: point.hpp:24
hotkey_list hotkeys_
Definition: hotkey_item.cpp:41
bool wants_mouse_left_double_click() const
void connect_signal_pre_key_press(dispatcher &dispatcher, const signal_keyboard_function &signal)
Connects the signal for &#39;snooping&#39; on the keypress.
Definition: dispatcher.cpp:167
void disconnect_signal_mouse_left_click(dispatcher &dispatcher, const signal_function &signal)
Disconnects a signal handler for a left mouse button click.
Definition: dispatcher.cpp:177
constexpr bool is_raw_event_event(const ui_event event)
Helper for catching use error of dispatcher::connect_signal.
Definition: dispatcher.hpp:161
bool fire(const ui_event event, widget &target)
Fires an event which has no extra parameters.
Definition: dispatcher.cpp:69
constexpr bool is_notification_event(const ui_event event)
Helper for catching use error of dispatcher::connect_signal.
Definition: dispatcher.hpp:131
map_location coordinate
Contains an x and y coordinate used for starting positions in maps.
constexpr bool is_text_input_event(const ui_event event)
Helper for catching use error of dispatcher::connect_signal.
Definition: dispatcher.hpp:171
See LEFT_BUTTON_DOUBLE_CLICK.
Definition: handler.hpp:71
bool wants_mouse_middle_double_click() const
A left mouse button click event for a widget.
Definition: handler.hpp:63
std::string::const_iterator iterator
Definition: tokenizer.hpp:25
ui_event
The event send to the dispatcher.
Definition: handler.hpp:48
void connect_signal_on_draw(dispatcher &dispatcher, const signal_function &signal)
Connects a signal handler for a callback when the widget is drawn.
Definition: dispatcher.cpp:192