Non-blocking questions and comments:
mev::make_event(MirInputDeviceId(android_event->getDeviceId()), kev->getEventTime(), - kev->getMac(), + {std::begin(cookie), std::end(cookie)}, mia::mir_keyboard_action_from_android(kev->getAction(), kev->getRepeatCount()), kev->getKeyCode(), kev->getScanCode(),
Why do we need to create a "std::vector<uint8_t>" temporary from a blob (called "cookie"!)? What stops make_event taking a blob const&?
~~~~
+ MirCookie() = delete;
What advantage is there for disabling default construction?
+#include "cookie.h"
We usually write the full path in public headers. Vis:
#include "mir/cookie/cookie.h"
+ * \return A unique_ptr Authority
I don't think it useful to mention unique_ptr in the doc comment. (And you don't do it consistently.)
« Back to merge proposal
Non-blocking questions and comments:
mev::make_ event(MirInputD eviceId( android_ event-> getDeviceId( )),
kev->getEventT ime(), cookie) , std::end(cookie)}, keyboard_ action_ from_android( kev->getAction( ), kev->getRepeatC ount()) ,
kev->getKeyCod e(),
- kev->getMac(),
+ {std::begin(
mia::mir_
kev->getScanCode(),
Why do we need to create a "std::vector< uint8_t> " temporary from a blob (called "cookie"!)? What stops make_event taking a blob const&?
~~~~
+ MirCookie() = delete;
What advantage is there for disabling default construction?
~~~~
+#include "cookie.h"
We usually write the full path in public headers. Vis:
#include "mir/cookie/ cookie. h"
~~~~
+ * \return A unique_ptr Authority
I don't think it useful to mention unique_ptr in the doc comment. (And you don't do it consistently.)