genode

History

Norman Feske eba9c15746 Follow practices suggested by "Effective C++" The patch adjust the code of the base, base-<kernel>, and os repository. To adapt existing components to fix violations of the best practices suggested by "Effective C++" as reported by the -Weffc++ compiler argument. The changes follow the patterns outlined below: * A class with virtual functions can no longer publicly inherit base classed without a vtable. The inherited object may either be moved to a member variable, or inherited privately. The latter would be used for classes that inherit 'List::Element' or 'Avl_node'. In order to enable the 'List' and 'Avl_tree' to access the meta data, the 'List' must become a friend. * Instead of adding a virtual destructor to abstract base classes, we inherit the new 'Interface' class, which contains a virtual destructor. This way, single-line abstract base classes can stay as compact as they are now. The 'Interface' utility resides in base/include/util/interface.h. * With the new warnings enabled, all member variables must be explicitly initialized. Basic types may be initialized with '='. All other types are initialized with braces '{ ... }' or as class initializers. If basic types and non-basic types appear in a row, it is nice to only use the brace syntax (also for basic types) and align the braces. * If a class contains pointers as members, it must now also provide a copy constructor and assignment operator. In the most cases, one would make them private, effectively disallowing the objects to be copied. Unfortunately, this warning cannot be fixed be inheriting our existing 'Noncopyable' class (the compiler fails to detect that the inheriting class cannot be copied and still gives the error). For now, we have to manually add declarations for both the copy constructor and assignment operator as private class members. Those declarations should be prepended with a comment like this: /* * Noncopyable */ Thread(Thread const &); Thread &operator = (Thread const &); In the future, we should revisit these places and try to replace the pointers with references. In the presence of at least one reference member, the compiler would no longer implicitly generate a copy constructor. So we could remove the manual declaration. Issue #465		2018-01-17 12:14:35 +01:00
..
main.cc	Follow practices suggested by "Effective C++"	2018-01-17 12:14:35 +01:00
README	os: generalize xray trigger component	2017-11-09 12:18:42 +01:00
target.mk	os: generalize xray trigger component	2017-11-09 12:18:42 +01:00

README

The "global-key-handler" component transforms a stream of nitpicker input
events to state reports. The states and the ways of how the user input affects
the states is configurable. Examples for such states are the system-global
capslock and numlock states, or the nitpicker X-ray mode activated by a global
secure-attention key. The configuration looks as follows:

! <config>
!   <bool name="xray" initial="no"/>
! 
!   <press   name="KEY_F1" bool="xray" change="on"/>
!   <release name="KEY_F1" bool="xray" change="off"/>
!   <press   name="KEY_F2" bool="xray" change="toggle"/>
! 
!   <report name="xray" delay_ms="125">
!     <hovered domain="panel"/>
!     <bool name="xray"/>
!   </report>
! </config>

A '<bool>' node declares a boolean state variable with the given name and its
initial value (default is "no"). There may by any number of such variables.

The '<press>' and '<release>' nodes define how key events affect the state
variables. Each of those nodes refers to a specific state variable via the
'bool' attribute, and the operation as the 'change' attribute. Possible
'change' attribute values are "on", "off", and "toggle".

The '<report>' node defines a state-dependent report with the name as
specified in the 'name' attribute. The report-generation rate can be
artificially limited by the 'delay_ms' attribute. If specified, the report is
not issued immediately on a state change but after the specified amount of
milliseconds. The '<report>' node contains a number of conditions. Whenever
one of those conditions is true, a report of the following form is generated:

! <xray enabled="yes"/>

Otherwise, the report's 'enabled' attribute has the value "no". Possible
conditions are '<bool>' and '<hovered>'. The '<bool>' condition is true if the
named boolean state variable has the value true. The '<hovered>' condition is
true if the currently hovered nitpicker client belongs to the domain as
specified in the 'domain' attribute. The latter information is obtained from a
ROM module named "hover", which correponds to nitpicker's hover reports.

To use the global-keys-handler in practice, one needs to configure the
nitpicker GUI server such that the press/release events of the global keys of
interest are routed to the global-keys-handler. This can be achieved by
nitpicker's '<global-key>' configuration nodes. For example:

! <global-key name="KEY_F1" label="global_keys_handler -> input" />
! <global-key name="KEY_F2" label="global_keys_handler -> input" />