John Levon <[EMAIL PROTECTED]> writes:
| Interesting that the wishlist thread on comp.lang.c++.moderated
| was talking about the exact same problem I had with
| key_state/mouse_state
>
| A further refinement might be a typedef int button; in mouse_state
| to clearly separate state vs. event of a mouse button, but it's not
| worth it right now.
>
| OK to commit ?
It looks a lot better, but why the enum values in all CAPS?
I'd like to see that reserved for macros/defines
and why include config.h here:
--- src/kbsequence.h 21 Mar 2002 17:25:10 -0000 1.10
+++ src/kbsequence.h 25 May 2002 03:54:41 -0000
@@ -12,9 +12,13 @@
#pragma interface
#endif
-#include <vector>
+#include <config.h>
+
+#include "frontends/key_state.h"
#include "LString.h"
+#include <vector>
+
class kb_keymap;
And the formatting of:
+mouse_button::state x_button_state(unsigned int button)
+{
+ mouse_button::state b = mouse_button::NONE;
+ switch (button) {
+ case Button1: b = mouse_button::BUTTON1; break;
+ case Button2: b = mouse_button::BUTTON2; break;
+ case Button3: b = mouse_button::BUTTON3; break;
+ case Button4: b = mouse_button::BUTTON4; break;
+ case Button5: b = mouse_button::BUTTON5; break;
+ default: // FIXME
+ break;
+ }
+ return b;
+}
+
please break the lines.
(goes for the next two functions as well)
(I try to stay with the rule: one statement, one line)
btw. what er the benefits of doing it this way:
+namespace mouse_button {
+
+ enum {
+ NONE = 0, //< no buttons held
+ BUTTON1 = 1, //< mouse button 1 pressed
+ BUTTON2 = 2,
+ BUTTON3 = 4,
+ BUTTON4 = 8,
+ BUTTON5 = 16
+ };
+
+ typedef int state;
+}
+
instead of using a named enum?
(except that you loosen up the type checking)
PS. Sorry for beeing this pain...
--
Lgb
