SFML community forums
General => General discussions => Topic started by: Critkeeper on June 17, 2015, 03:39:33 am
-
of ints.
This isn't a request or a complaint, and it doesn't need to be since this is just General Discussion.
I'm just curious. I want to understand the reasoning behind the design decisions of SFML, since I regard it as one of the cleanest libraries I have ever seen; I hope that by understanding the reasons behind various design decisions I can pull some of that good hygiene into my own work.
namespace sf
39 {
44 class Event
45 {
46 public:
47
52 struct SizeEvent
53 {
54 unsigned int width;
55 unsigned int height;
56 };
57
62 struct KeyEvent
63 {
64 Keyboard::Key code;
65 bool alt;
66 bool control;
67 bool shift;
68 bool system;
69 };
70
75 struct TextEvent
76 {
77 Uint32 unicode;
78 };
79
84 struct MouseMoveEvent
85 {
86 int x;
87 int y;
88 };
89
95 struct MouseButtonEvent
96 {
97 Mouse::Button button;
98 int x;
99 int y;
100 };
101
109 struct MouseWheelEvent
110 {
111 int delta;
112 int x;
113 int y;
114 };
115
120 struct MouseWheelScrollEvent
121 {
122 Mouse::Wheel wheel;
123 float delta;
124 int x;
125 int y;
126 };
127
133 struct JoystickConnectEvent
134 {
135 unsigned int joystickId;
136 };
137
142 struct JoystickMoveEvent
143 {
144 unsigned int joystickId;
145 Joystick::Axis axis;
146 float position;
147 };
148
154 struct JoystickButtonEvent
155 {
156 unsigned int joystickId;
157 unsigned int button;
158 };
159
164 struct TouchEvent
165 {
166 unsigned int finger;
167 int x;
168 int y;
169 };
170
175 struct SensorEvent
176 {
177 Sensor::Type type;
178 float x;
179 float y;
180 float z;
181 };
182
187 enum EventType
188 {
189 Closed,
190 Resized,
191 LostFocus,
192 GainedFocus,
193 TextEntered,
194 KeyPressed,
195 KeyReleased,
196 MouseWheelMoved,
197 MouseWheelScrolled,
198 MouseButtonPressed,
199 MouseButtonReleased,
200 MouseMoved,
201 MouseEntered,
202 MouseLeft,
203 JoystickButtonPressed,
204 JoystickButtonReleased,
205 JoystickMoved,
206 JoystickConnected,
207 JoystickDisconnected,
208 TouchBegan,
209 TouchMoved,
210 TouchEnded,
211 SensorChanged,
212
213 Count
214 };
215
217 // Member data
219 EventType type;
220
221 union
222 {
223 SizeEvent size;
224 KeyEvent key;
225 TextEvent text;
226 MouseMoveEvent mouseMove;
227 MouseButtonEvent mouseButton;
228 MouseWheelEvent mouseWheel;
229 MouseWheelScrollEvent mouseWheelScroll;
230 JoystickMoveEvent joystickMove;
231 JoystickButtonEvent joystickButton;
232 JoystickConnectEvent joystickConnect;
233 TouchEvent touch;
234 SensorEvent sensor;
235 };
236 };
237
238 } // namespace sf
See the (x,y) pairs everywhere? Why not use sf::Vect ?
-
We wouldn't be able to dump all those event types into a union as is done now with sf::Event. Only trivial classes/structs (basically classes/structs without defined constructors) are allowed to be made part of a union, and sf::Vector has a constructor which goes ahead and initializes its data members. Replacing x and y with sf::Vectors would make the event structs non-trivial and the union would no longer compile.
Accessing any of those x or y members right after you instantiate an sf::Event struct returns you undefined values. Doing the same right after you instantiate an sf::Vector will always return 0.
-
Could there not be a bespoke vector structure for the pairs here? It would increase the consistency.
There are other instances of inconsistent usage of pairs vs vectors. Things like Image's create() and getPixel(), and VideoMode()'s constructor require you to break a vector down into its component parts before passing as parameters. Not that it's hard but it's inconsistent. If the vector you wish to pass is returned from a function, it can require creating a temporary vector to avoid the function being called twice - once for each component.
I know that adding overloads for vectors could be considered 'bloating' the interface but shouldn't the vectors be considered the original/standard format and the separate component parameters as the overloads (which obviously can't be removed until v3 because of breaking old code).
I didn't mean to mini-rant. It seemed like a relatively appropriate subject but I suppose it may be considered slightly off-topic as it's not directly about Events.
-
Last I checked all "inconsistencies" have their reason. ;)