Hi. I look at dev version of Bloc and have questions about events. There is duplicated hierarchy of OSEvent and BlEvent. For example for OSKeyDownEvent and OSMouseButtonPressEvent there are same events from Block: BlKeyDownEvent and BlMouseDownEvent. Bloc of course add many new events like BlDragEvent and BlDblClickEvent. But why we not manage all events equally? why we need this distinction? Also I was so much surprized about keyboard modifiers. In OS there is OSStateModifiers with smart boolean states like leftShiftPressed, leftAltPressed which are decoded from integer bits of raw SDL event. And in Bloc it is BlKeyModifiers which are created from OSStateModifier. And here is most amazing thing: BlKeyModifiers encode smart boolean flags about keys back into integer bits. So we have: SDL event int => OSStateModifiers booleans => BlKeyModifiers int Why it is done like this? And currently BlKeyModifiers lost many states from OSStateModifiers.
Hi Denis, Thanks a lot for looking at this! I will let Glenn answer. Cheers, Doru
On Oct 26, 2016, at 11:02 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hi.
I look at dev version of Bloc and have questions about events.
There is duplicated hierarchy of OSEvent and BlEvent. For example for OSKeyDownEvent and OSMouseButtonPressEvent there are same events from Block: BlKeyDownEvent and BlMouseDownEvent.
Bloc of course add many new events like BlDragEvent and BlDblClickEvent. But why we not manage all events equally? why we need this distinction?
Also I was so much surprized about keyboard modifiers. In OS there is OSStateModifiers with smart boolean states like leftShiftPressed, leftAltPressed which are decoded from integer bits of raw SDL event.
And in Bloc it is BlKeyModifiers which are created from OSStateModifier. And here is most amazing thing: BlKeyModifiers encode smart boolean flags about keys back into integer bits. So we have:
SDL event int => OSStateModifiers booleans => BlKeyModifiers int
Why it is done like this? And currently BlKeyModifiers lost many states from OSStateModifiers.
-- www.tudorgirba.com www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
Hi Denis and thanks for looking at this. Yes there is a duplication of the event hierarchy between Bloc and OSWindow. We discussed about the fusion of OSWindow and Bloc events one year ago at INRIA. We made the choice to keep Bloc independent from OSWindow because, among other things: - Bloc allows several windowing backends, for instance we had a morphic windowing backend (no longer maintained today) - OSEvents are too low level to be used directly in Bloc (nothing about source, target, propagation, consumption ...) - OSWindow has to stay low level and independent from high level preoccupations like the Bloc ones - Bloc has to provide an unified and consistent layer on top of underlying libraries The keyboard management is not yet finished in Bloc. numLock and capsLock seems to be missing, thanks for pointing this. Moreover, some keys are also merged like the left & right distinction between ctrl|alt|shift. If this distinction is really needed in the future maybe we will add it. Denis Kudriashov wrote
BlKeyModifiers encode smart boolean flags about keys back into integer bits
I decided to replace all booleans by one integer+masks because it seems to be more lightweight and this integer can be used directly for the hash key. It is just the internal representation and users don't have to care about this integer. If you think that leads to some issues, i'm not against booleans by nature ;). More generally, i think that, to stay consistent, Bloc should not reuse directly (and everywhere) some part of underlying libraries even if sometime these parts seems to match directly. We have to take care about dependencies between layers. The gain was obvious during the migration from Athens to Sparta. Regards, Glenn. ----- Glenn Cavarlé -- View this message in context: http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920239.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi Glenn. Thank's for answer. 2016-10-26 13:29 GMT+02:00 Glenn Cavarlé <glenn.cavarle@gmail.com>:
More generally, i think that, to stay consistent, Bloc should not reuse directly (and everywhere) some part of underlying libraries even if sometime these parts seems to match directly.
I can't take it. Duplication is always bad. There is no reason for it. I think we just don't need OSEvent's. Real low level is SDL events hierarchy. And OSSDL2WindowHandle built OSEvent's from them: OSSDL2WindowHandle>>handleNewSDLEvent: sdlEvent ^ sdlEvent accept: self But we can delegate this processing to osWindow osWindow handleNewSDLEvent: sdlEvent which then will call eventsHandler of given window. And BlOSWindowEventHandler will work directly with SDL event with full access to raw event data. No need for intermediate level.
Denis Kudriashov wrote
I can't take it. Duplication is always bad. There is no reason for it.
I agree, is always bad if there is no real reason to duplicate but i think there is a real argument for Bloc. OSWindow cannot be the only one backend for Bloc so Bloc events cannot be based on OSEvents. We need also a backend for mobile devices with a completely different implementation than the OSWindow one. OSWindow is not adapted for non-window-based platforms like mobiles. For example, on Android, we have to deal with activities and to convert Android events to Bloc events. Denis Kudriashov wrote
And BlOSWindowEventHandler will work directly with SDL event with full access to raw event data. No need for intermediate level
It is interesting only if performances are substantially improved. Because it is also duplication, you duplicates in Bloc the OSWindow conversion code without any added value. Moreover, this does not prevent the duplication of Event hierarchy. OSWindow is already used in other projects and these users will not be happy if we remove OSEvents ;). It is clear that every layer has a cost which should not be neglected. But right now, i think this cost is counterbalanced by the possibility to move transparently on different windowing backends. I'm ok if everybody wants to merge Bloc and OSWindow as a single project but I doubt this is the case. Regards, Glenn. ----- Glenn Cavarlé -- View this message in context: http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920265.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Le 26/10/16 à 16:58, Glenn Cavarlé a écrit :
Denis Kudriashov wrote
I can't take it. Duplication is always bad. There is no reason for it. I agree, is always bad if there is no real reason to duplicate but i think there is a real argument for Bloc. OSWindow cannot be the only one backend for Bloc so Bloc events cannot be based on OSEvents. Why that? We need also a backend for mobile devices with a completely different implementation than the OSWindow one. OSWindow is not adapted for non-window-based platforms like mobiles. For example, on Android, we have to deal with activities and to convert Android events to Bloc events.
So then it means that OSWindowEvents are not useful. But to me this is bloc events that are not needed. I do not get why on android we cannot map android event to OSWindowEvents And do not have duplication in Bloc. We have then SDL events -> OSWindowEvent - Bloc Android event
And BlOSWindowEventHandler will work directly with SDL event with full access to raw event data. No need for intermediate level It is interesting only if performances are substantially improved. Because it is also duplication, you duplicates in Bloc the OSWindow conversion code without any added value. Moreover, this does not prevent the duplication of Event hierarchy. OSWindow is already used in other projects and these users will not be happy if we remove OSEvents ;). who? It is clear that every layer has a cost which should not be neglected. But right now, i think this cost is counterbalanced by the possibility to move transparently on different windowing backends. I'm ok if everybody wants to merge Bloc and OSWindow as a single project but I doubt this is the case.
Regards, Glenn.
----- Glenn Cavarlé -- View this message in context: http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920265.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2016-10-26 17:20 GMT+02:00 stepharo <stepharo@free.fr>:
So then it means that OSWindowEvents are not useful.
Glenn said that OSEvent's has no specific state which needed for Bloc logic. And Bloc events define it: - OSEvents are too low level to be used directly in Bloc (nothing about
source, target, propagation, consumption ...)
Look at keyboard event to compare: OSKeyboardEvent: #(#window #suppressDefaultAction #scanCode #symbol #character #modifiers #position #repeat) BlKeyboardEvent: #(#source #target #currentTarget #timestamp #canBePropagated #consumed #position #screenPosition #modifiers #button #keyValue #charCode #scanCode) Bloc extends it a lot. Glenn has reasons why he not evolved OSWindow classes. But his work is done. And these reasons are not important anymore. We could think about BlEvent as OSEvent version 2.0. So at the end we will just remove "old version".
Hi Stef, stepharo wrote
OSWindow cannot be the only one backend for Bloc so Bloc events cannot be based on OSEvents. Why that?
Because it is OS"Window" and many devices don't have window and sometime don't have SDL too. If tomorrow, OSWindow become something like OSDirectMedia with support for many kind of devices and backends, my answer will be completely different and in this case you will be right. So, right now OSWindow is used in Bloc for what it is, a nice windowing library based on SDL/OpenGL. stepharo wrote
I do not get why on android we cannot map android event to OSWindowEvents And do not have duplication in Bloc.
Maybe it is possible, maybe not, maybe it is just inconsistent with the rest of OSWindow in its current state. Clearly, I don't know and you? In doubt, i prefer to keep the possibility to use another backend. stepharo wrote
So then it means that OSWindowEvents are not useful. But to me this is bloc events that are not needed.
I don't understand what you mean. The question is not what is the more useful event hierarchy. The question is why we cannot use OSWindow events directly in Bloc right now. The answer is: - because many events do not exist in SDL and are consequently not managed by OSWindow. - because OSWindow events are not design to be used in a scene graph - because some information related to the scene graph are missing in the OSWindow event hierarchy. If you want to improve OSWindow in this way, this mean that part of Bloc has to be moved in OSWindow because: - you need a dispatch/handling mechanism - you need a scene graph - you need to generate high-level events (click, drag, focus,...) depending on nodes in the scene graph Personally, if something has to be done, I would prefer the opposite: to move OSWindow in Bloc ;). stepharo wrote
OSWindow is already used in other projects and these users will not be happy if we remove OSEvents ;). who?
I know that Ronie uses OSWindow for Woden. As i said, if everybody is ok, we can merge OSWindow in Bloc and we can just keep the existing BlEvent hierarchy. As explained, it is not a stupid duplication, many things in Bloc events would have no sense in OSWindow events. I would like also to mention that we are discussing about a justified duplication of a hierarchy which have to be changed maybe every 3 years if magically new events are added in SDL... It is known that it i not perfect to duplicate things but it is localized and today i don't have alternative solution that does not includes to redo/brake OSWindow. <joke> But if you have a concrete solution to avoid that and that does not requires 1000 times more developments than updating the "duplicated" hierarchy once in 2 years, i'm on it ! ;) </joke> Regards, Glenn. ----- Glenn Cavarlé -- View this message in context: http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920294.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Hi Glenn Now I understand. So can you copy and paste this mail into the class comment of the BlEvent root. We should really document such design decision. Stef Le 26/10/16 à 19:25, Glenn Cavarlé a écrit :
Hi Stef,
stepharo wrote
OSWindow cannot be the only one backend for Bloc so Bloc events cannot be based on OSEvents. Why that? Because it is OS"Window" and many devices don't have window and sometime don't have SDL too. If tomorrow, OSWindow become something like OSDirectMedia with support for many kind of devices and backends, my answer will be completely different and in this case you will be right. So, right now OSWindow is used in Bloc for what it is, a nice windowing library based on SDL/OpenGL.
stepharo wrote
I do not get why on android we cannot map android event to OSWindowEvents And do not have duplication in Bloc. Maybe it is possible, maybe not, maybe it is just inconsistent with the rest of OSWindow in its current state. Clearly, I don't know and you? In doubt, i prefer to keep the possibility to use another backend.
stepharo wrote
So then it means that OSWindowEvents are not useful. But to me this is bloc events that are not needed. I don't understand what you mean. The question is not what is the more useful event hierarchy. The question is why we cannot use OSWindow events directly in Bloc right now.
The answer is:
- because many events do not exist in SDL and are consequently not managed by OSWindow. - because OSWindow events are not design to be used in a scene graph - because some information related to the scene graph are missing in the OSWindow event hierarchy.
If you want to improve OSWindow in this way, this mean that part of Bloc has to be moved in OSWindow because: - you need a dispatch/handling mechanism - you need a scene graph - you need to generate high-level events (click, drag, focus,...) depending on nodes in the scene graph
Personally, if something has to be done, I would prefer the opposite: to move OSWindow in Bloc ;).
stepharo wrote
OSWindow is already used in other projects and these users will not be happy if we remove OSEvents ;). who? I know that Ronie uses OSWindow for Woden. As i said, if everybody is ok, we can merge OSWindow in Bloc and we can just keep the existing BlEvent hierarchy.
As explained, it is not a stupid duplication, many things in Bloc events would have no sense in OSWindow events. I would like also to mention that we are discussing about a justified duplication of a hierarchy which have to be changed maybe every 3 years if magically new events are added in SDL... It is known that it i not perfect to duplicate things but it is localized and today i don't have alternative solution that does not includes to redo/brake OSWindow.
<joke> But if you have a concrete solution to avoid that and that does not requires 1000 times more developments than updating the "duplicated" hierarchy once in 2 years, i'm on it ! ;) </joke>
Regards, Glenn.
----- Glenn Cavarlé -- View this message in context: http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920294.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2016-10-26 16:58 GMT+02:00 Glenn Cavarlé <glenn.cavarle@gmail.com>:
It is interesting only if performances are substantially improved. Because it is also duplication, you duplicates in Bloc the OSWindow conversion code without any added value.
No. You are not right here. Conversion code for OSEvent=>BlEvent and SDLEvent=>OSEvent is almost same. All events have similar interface to retrieve event data. So it will be quite easy to use SDL directly. And for Bloc it will be improvement because of direct access to real OS state and also performance.
Moreover, this does not prevent the duplication of Event hierarchy.
If you mean SDLEvents vs BlEvent then I would said it is not real duplication. Because SDLEvents are just "transfer objects" - structures from external interface. We just need them to extract raw information from sdl-library. But BlEvents or OSEvents are about modelling such events inside our system. And here we don't need two models.
OSWindow is already used in other projects and these users will not be happy if we remove OSEvents ;).
I doubt that there is anyone accept Morphic. And Morphic also perform stupid conversion to own MorphicEvent's which could be also implemented directly on SDL events without OSEvent's.
2016-10-26 18:21 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com>:
No. You are not right here. Conversion code for OSEvent=>BlEvent and SDLEvent=>OSEvent is almost same. All events have similar interface to retrieve event data.
I mean conversion code in both cases is just stupid creation of new event classes on top of state of original events. No logic behind. (all logic to parse raw bytes are hidden inside sdl-events)
Denis Kudriashov wrote
2016-10-26 18:21 GMT+02:00 Denis Kudriashov <
dionisiydk@
>:
No. You are not right here. Conversion code for OSEvent=>BlEvent and SDLEvent=>OSEvent is almost same. All events have similar interface to retrieve event data.
I mean conversion code in both cases is just stupid creation of new event classes on top of state of original events. No logic behind. (all logic to parse raw bytes are hidden inside sdl-events)
Yes, your are right. What i mean is that it could be interesting if: [ SDLEvent => BlEvent ] is substantially faster than [ SDLEvent => OSEvent => BlEvent ]. If the difference is not significant, i think that does not justify to not benefit from OSWindow abstractions even if sometime they bring nothing more. Regards, Glenn. ----- Glenn Cavarlé -- View this message in context: http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920298.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2016-10-26 19:45 GMT+02:00 Glenn Cavarlé <glenn.cavarle@gmail.com>:
Yes, your are right. What i mean is that it could be interesting if: [ SDLEvent => BlEvent ] is substantially faster than [ SDLEvent => OSEvent => BlEvent ]. If the difference is not significant, i think that does not justify to not benefit from OSWindow abstractions even if sometime they bring nothing more.
If you already thought about Announcements performance and produce optimized alternative then I think it is critical to get events fast. Now we have 10 variables which are decoded from int by bit operations: leftShift rightShift leftAlt rightAlt leftCtrl rightCtrl leftCmd rightCmd capsLock numLock And then Bloc encodes them back to int. So for any event we have 20 operations and it is not just primitive calls. Also OSEvent creation produces own garbage for internal structures which also take time and memory. But for me most important is how maintain both hierarchies. You answer Stef that nothing will change over events during years (nobody invent new one or not often). But such argument could never be valid. Code is used, it could has bugs, it could be improved by itself. People will always need to work with this code, at least to read it. And it is difficult with two hierarchies which are managed by double dispatch. Try to follow how concrete BlEvent is produced. And there is already some problem. I investigated deeply what happens in sdl about modifiers and buttons. It is not easy. But I see that some information becomes lost. And Bloc also not provides full information from original objects (modifiers and buttons). So to fix these issues one needs to modify both hierarchies. First he needs to decide how decode modifiers from SDL and then how to encode them into Bloc bits. And I am sure new issues will be found again and again. It is normal process.
Le 26/10/16 à 20:40, Denis Kudriashov a écrit :
2016-10-26 19:45 GMT+02:00 Glenn Cavarlé <glenn.cavarle@gmail.com <mailto:glenn.cavarle@gmail.com>>:
Yes, your are right. What i mean is that it could be interesting if: [ SDLEvent => BlEvent ] is substantially faster than [ SDLEvent => OSEvent => BlEvent ]. If the difference is not significant, i think that does not justify to not benefit from OSWindow abstractions even if sometime they bring nothing more.
If you already thought about Announcements performance and produce optimized alternative then I think it is critical to get events fast. Now we have 10 variables which are decoded from int by bit operations:
leftShift rightShift leftAlt rightAlt leftCtrl rightCtrl leftCmd rightCmd capsLock numLock
And then Bloc encodes them back to int. So for any event we have 20 operations and it is not just primitive calls. Also OSEvent creation produces own garbage for internal structures which also take time and memory.
But for me most important is how maintain both hierarchies. You answer Stef that nothing will change over events during years (nobody invent new one or not often). But such argument could never be valid. Code is used, it could has bugs, it could be improved by itself. People will always need to work with this code, at least to read it. And it is difficult with two hierarchies which are managed by double dispatch. Try to follow how concrete BlEvent is produced.
And there is already some problem. I investigated deeply what happens in sdl about modifiers and buttons. It is not easy. But I see that some information becomes lost. And Bloc also not provides full information from original objects (modifiers and buttons). So to fix these issues one needs to modify both hierarchies. First he needs to decide how decode modifiers from SDL and then how to encode them into Bloc bits. And I am sure new issues will be found again and again. It is normal process.
So denis you suggest that Bloc uses directly SDLEvents. This would make sense from your analysis.
Something itches me from this discussion. I somehow find myself with Glenn: - should Bloc work with other than SDL/OSWindow? - should SDL/OSWindow work with other than Bloc? Merging the event hierarchy may prevent these two scenarios. And these scenarios are not only really possible: this is what the current scenario is. On one hand SDL and OSWindow work today with Morphic besides Block. On the other hand Bloc is, after all, an external library loaded on top of Pharo. To explain better what I think: - First I have the feeling that BIEvent and OSEvent are not the same thing. They have the same *NAME*. But they model different concepts. What is an event in bloc does not make sense in OSWindow and vice-versa. Why? because OSWindow does not manage widgets nor interactions between them. - Second, I think that this idea of merging these hierarchies means merging layers also, what leads also to our monolithic system. I agree that this may impose some maintenance burden because there is the maintenance of the two layers plus their mapping (e.g., between the low-level events and the high-level events). But otherwise we are tampering the modularity. Now, I liked more the suggestion of making Bloc using SDLEvents directly. But then, wasn't it an idea behind OSWindow that users of OSWindow should be somehow abstracted from the backend behind. And SDL be just a backend? Something like Athens and Cairo. Is SDL meant to work alone or be just a backend for OSWindow? Because if the case is the later, then maybe it makes sense to do the inverse: SDL should generate directly OSEvents and we should not have SDLEvent. And going even further: Is OSWindow used in isolation? e.g., without morphic or bloc. Because then, it the problem is the runtime overhead OSWindow should maybe not reify its events but propose a low level event handler mechanism where we could have MorphicOSWindowEventHandler
keyEvent: ... mouseEvent: ...
BlocOSWindowEventHandler
keyEvent: ... mouseEvent: ...
And each framework generates its own events from low level SDL data. No event transformations, less duplications, and both Bloc and Morphic are plugged on top of OSWindow but not really strongly coupled to it. -------- Original Message --------
Le 26/10/16 à 20:40, Denis Kudriashov a écrit :
2016-10-26 19:45 GMT+02:00 Glenn Cavarlé <glenn.cavarle@gmail.com <mailto:glenn.cavarle@gmail.com>>:
Yes, your are right. What i mean is that it could be interesting if: [ SDLEvent => BlEvent ] is substantially faster than [ SDLEvent => OSEvent => BlEvent ]. If the difference is not significant, i think that does not justify to not benefit from OSWindow abstractions even if sometime they bring nothing more.
If you already thought about Announcements performance and produce optimized alternative then I think it is critical to get events fast. Now we have 10 variables which are decoded from int by bit operations:
leftShift rightShift leftAlt rightAlt leftCtrl rightCtrl leftCmd rightCmd capsLock numLock
And then Bloc encodes them back to int. So for any event we have 20 operations and it is not just primitive calls. Also OSEvent creation produces own garbage for internal structures which also take time and memory.
But for me most important is how maintain both hierarchies. You answer Stef that nothing will change over events during years (nobody invent new one or not often). But such argument could never be valid. Code is used, it could has bugs, it could be improved by itself. People will always need to work with this code, at least to read it. And it is difficult with two hierarchies which are managed by double dispatch. Try to follow how concrete BlEvent is produced.
And there is already some problem. I investigated deeply what happens in sdl about modifiers and buttons. It is not easy. But I see that some information becomes lost. And Bloc also not provides full information from original objects (modifiers and buttons). So to fix these issues one needs to modify both hierarchies. First he needs to decide how decode modifiers from SDL and then how to encode them into Bloc bits. And I am sure new issues will be found again and again. It is normal process.
So denis you suggest that Bloc uses directly SDLEvents. This would make sense from your analysis.
Le 27/10/16 à 10:57, Guille Polito a écrit :
Something itches me from this discussion.
I somehow find myself with Glenn: - should Bloc work with other than SDL/OSWindow? - should SDL/OSWindow work with other than Bloc?
Merging the event hierarchy may prevent these two scenarios. And these scenarios are not only really possible: this is what the current scenario is. On one hand SDL and OSWindow work today with Morphic besides Block. On the other hand Bloc is, after all, an external library loaded on top of Pharo.
To explain better what I think:
- First I have the feeling that BIEvent and OSEvent are not the same thing. They have the same *NAME*. But they model different concepts. What is an event in bloc does not make sense in OSWindow and vice-versa. Why? because OSWindow does not manage widgets nor interactions between them.
- Second, I think that this idea of merging these hierarchies means merging layers also, what leads also to our monolithic system. I agree that this may impose some maintenance burden because there is the maintenance of the two layers plus their mapping (e.g., between the low-level events and the high-level events). But otherwise we are tampering the modularity.
Now, I liked more the suggestion of making Bloc using SDLEvents directly.
But then, wasn't it an idea behind OSWindow that users of OSWindow should be somehow abstracted from the backend behind. And SDL be just a backend? Something like Athens and Cairo.
Is SDL meant to work alone or be just a backend for OSWindow? Because if the case is the later, then maybe it makes sense to do the inverse: SDL should generate directly OSEvents and we should not have SDLEvent.
may be. Now I do not think that doing more than two transformations is good.
And going even further: Is OSWindow used in isolation? e.g., without morphic or bloc.
Because then, it the problem is the runtime overhead OSWindow should maybe not reify its events but propose a low level event handler mechanism where we could have
MorphicOSWindowEventHandler
keyEvent: ... mouseEvent: ...
BlocOSWindowEventHandler
keyEvent: ... mouseEvent: ...
And each framework generates its own events from low level SDL data. No event transformations, less duplications, and both Bloc and Morphic are plugged on top of OSWindow but not really strongly coupled to it. may be
Le 26/10/16 à 15:35, Denis Kudriashov a écrit :
Hi Glenn. Thank's for answer.
2016-10-26 13:29 GMT+02:00 Glenn Cavarlé <glenn.cavarle@gmail.com <mailto:glenn.cavarle@gmail.com>>:
More generally, i think that, to stay consistent, Bloc should not reuse directly (and everywhere) some part of underlying libraries even if sometime these parts seems to match directly.
I can't take it. Duplication is always bad. There is no reason for it.
+1
I think we just don't need OSEvent's.
That I'm not sure. Having a nice layer is nice but I do not get why two.
Real low level is SDL events hierarchy. And OSSDL2WindowHandle built OSEvent's from them:
OSSDL2WindowHandle>>handleNewSDLEvent: sdlEvent
^ sdlEvent accept: self
But we can delegate this processing to osWindow osWindow handleNewSDLEvent: sdlEvent
which then will call eventsHandler of given window. And BlOSWindowEventHandler will work directly with SDL event with full access to raw event data. No need for intermediate level.
More generally, i think that, to stay consistent, Bloc should not reuse directly (and everywhere) some part of underlying libraries even if sometime these parts seems to match directly. I do not understand why duplication is a good approach. I would prefer to enhance OSWindowEvents because the low level events are SDLEvents.
We have to take care about dependencies between layers. The gain was obvious during the migration from Athens to Sparta.
I do not see the point.
Regards, Glenn.
----- Glenn Cavarlé -- View this message in context: http://forum.world.st/Bloc-Hierarchy-of-BiEvent-tp4920209p4920239.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (5)
-
Denis Kudriashov -
Glenn Cavarlé -
Guille Polito -
stepharo -
Tudor Girba