The point of extending NativeBoost-Win32 more than neccessary?
Hi, Torsten, all i greatly appreciate your help and contribution, so don't take my critics as destructive , please :) The main reason for NativeBoost-Win32 package existence is to contain minimal necessary platform-dependent things, which would allow to support NativeBoost functionality. But you adding more and more things, which not strictly related to NB per se, but more like general accessibility to system etc. The test question what should and what should not belong to this package is: 'will NB run without it or not?'. So, try answering this question for classes and methods like: NBWin32Shell NBWin32Point etc. Please, do not misunderstand: i would certainty prefer such (and many other) things to be easily accessible, and working , when i need them. But to my thinking they are not belong to NB core, and should be moved to separate package (or project?). We should decide where, because if we keep going like that, eventually NativeBoost-Win32 will cover whole Win32 API and will make us responsible for maintaining it, something which i frankly don't have time nor resources to do. P.S. yes, i guilty that i started this by adding classes like NBWin32Window and couple more. But that was serving more as examples and minimal support for NBOpenGL to create offscreen window & opengl context. That was a mistake.. and we should not continue like that. -- Best regards, Igor Stasenko.
Hi Igor, I dont see this neither as "destructive" nor as "critics", especially since: - you initially started to add things to NB that were more or less API wrappers instead of real Core NB functionality ;) - I see the same risk for overloading NB and wanted to start the same discussion next time we meet on Skype. In the long term the distinction just by having different categories (core vs OS specific) will also in my opinion only be a workaround in need for better modularization or one/many separate platform specific projects As you know I already suggested to refactor tests to separate OS dependent stuff from core tests and I have more ideas for better modularization with the same idea of moving this to independent projects. I would suggest: 1. NB really just includes the core functionality of an external interface (FFI), including the support for calls and callbacks. Other projects can then build on top of it and it helps to keep it small for the Pharo image. 2. We pull out the OS specific stuff (for instance Win32) into real own project to provide more native API functionality. Such an API wrapper project is then not part of NB and therefore also not part of the standard Pharo image. We can make it accessible via a Configurations that are easily loadable from the config browser. I will do that as soon as time permits. 3. If others jump onto the bandwagon and put their API bindings for their favorite OS/platform (GTK, Linux, Mac, ...) we may later be able to implement/abstract a common layer API that depending on the loaded OS code provides native functionality but still allows platform independence of calling code. I mean something similar to SWT in Eclipse if you know what I'm talking about. In pseudocode this would mean to have: OSWindow new open while this is just a facade and dependent on the OS and loaded native support the underlying Win32, Mac or Linux API's for opening a Window are used. Regarding last changes/commits: As you will see in the repo I merged Stefs and your version of core and added #= to compare external handles. Will also write a test for it when theres the next minute. I also "bloated" or "enhanced" (depending on POV) it with more wrappers for Win32 (POINT, window functions, Process, Threads) which I will soon move to an own project on STHub so we can safely remove it from NB. Just be a little bit patient for the next possible time slot. Two wishes from my side if there is a timeslot/minute on your side: I would really appreciate a working example for opening a native Window as you started with NBWin32Window. Since a callback for the window procedure is required it would serve as a good example for callbacks too. It would also help if the proper marshalling for the WideStrings could be provided since this would allow to use more API's and even implement a COM binding. You wanted to check if the methods necessary for the marshalling were removed or have to be implemented... Thx T.
On 14 August 2013 00:57, Torsten Bergmann <astares@gmx.de> wrote:
Hi Igor,
I dont see this neither as "destructive" nor as "critics", especially since:
- you initially started to add things to NB that were more or less API wrappers instead of real Core NB functionality ;)
- I see the same risk for overloading NB and wanted to start the same discussion next time we meet on Skype. In the long term the distinction just by having different categories (core vs OS specific) will also in my opinion only be a workaround in need for better modularization or one/many separate platform specific projects
As you know I already suggested to refactor tests to separate OS dependent stuff from core tests and I have more ideas for better modularization with the same idea of moving this to independent projects.
I would suggest:
1. NB really just includes the core functionality of an external interface (FFI), including the support for calls and callbacks. Other projects can then build on top of it and it helps to keep it small for the Pharo image.
2. We pull out the OS specific stuff (for instance Win32) into real own project to provide more native API functionality. Such an API wrapper project is then not part of NB and therefore also not part of the standard Pharo image. We can make it accessible via a Configurations that are easily loadable from the config browser. I will do that as soon as time permits.
3. If others jump onto the bandwagon and put their API bindings for their favorite OS/platform (GTK, Linux, Mac, ...) we may later be able to implement/abstract a common layer API that depending on the loaded OS code provides native functionality but still allows platform independence of calling code. I mean something similar to SWT in Eclipse if you know what I'm talking about. In pseudocode this would mean to have:
OSWindow new open
while this is just a facade and dependent on the OS and loaded native support the underlying Win32, Mac or Linux API's for opening a Window are used.
Regarding last changes/commits: As you will see in the repo I merged Stefs and your version of core and added #= to compare external handles. Will also write a test for it when theres the next minute.
I also "bloated" or "enhanced" (depending on POV) it with more wrappers for Win32 (POINT, window functions, Process, Threads) which I will soon move to an own project on STHub so we can safely remove it from NB. Just be a little bit patient for the next possible time slot.
Good to know that we are aligned in our vision.
Two wishes from my side if there is a timeslot/minute on your side: I would really appreciate a working example for opening a native Window as you started with NBWin32Window. Since a callback for the window procedure is required it would serve as a good example for callbacks too. It would also help if the proper marshalling for the WideStrings could be provided since this would allow to use more API's and even implement a COM binding.
Window callbacks is ones that very tricky (and ones which usually most important ones). Because they called not at the moment when you call some external function, but at the moment when VM handling events (during interrupt).
You wanted to check if the methods necessary for the marshalling were removed or have to be implemented...
Yes, i will check, but i suspect it don't exists :)
Thx T.
-- Best regards, Igor Stasenko.
On Aug 14, 2013, at 4:05 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 14 August 2013 00:57, Torsten Bergmann <astares@gmx.de> wrote:
Hi Igor,
I dont see this neither as "destructive" nor as "critics", especially since:
- you initially started to add things to NB that were more or less API wrappers instead of real Core NB functionality ;)
- I see the same risk for overloading NB and wanted to start the same discussion next time we meet on Skype. In the long term the distinction just by having different categories (core vs OS specific) will also in my opinion only be a workaround in need for better modularization or one/many separate platform specific projects
As you know I already suggested to refactor tests to separate OS dependent stuff from core tests and I have more ideas for better modularization with the same idea of moving this to independent projects.
I would suggest:
1. NB really just includes the core functionality of an external interface (FFI), including the support for calls and callbacks. Other projects can then build on top of it and it helps to keep it small for the Pharo image.
2. We pull out the OS specific stuff (for instance Win32) into real own project to provide more native API functionality. Such an API wrapper project is then not part of NB and therefore also not part of the standard Pharo image. We can make it accessible via a Configurations that are easily loadable from the config browser. I will do that as soon as time permits.
3. If others jump onto the bandwagon and put their API bindings for their favorite OS/platform (GTK, Linux, Mac, ...) we may later be able to implement/abstract a common layer API that depending on the loaded OS code provides native functionality but still allows platform independence of calling code. I mean something similar to SWT in Eclipse if you know what I'm talking about. In pseudocode this would mean to have:
OSWindow new open
while this is just a facade and dependent on the OS and loaded native support the underlying Win32, Mac or Linux API's for opening a Window are used.
Regarding last changes/commits: As you will see in the repo I merged Stefs and your version of core and added #= to compare external handles. Will also write a test for it when theres the next minute.
I also "bloated" or "enhanced" (depending on POV) it with more wrappers for Win32 (POINT, window functions, Process, Threads) which I will soon move to an own project on STHub so we can safely remove it from NB. Just be a little bit patient for the next possible time slot.
Good to know that we are aligned in our vision.
Two wishes from my side if there is a timeslot/minute on your side: I would really appreciate a working example for opening a native Window as you started with NBWin32Window. Since a callback for the window procedure is required it would serve as a good example for callbacks too. It would also help if the proper marshalling for the WideStrings could be provided since this would allow to use more API's and even implement a COM binding.
Window callbacks is ones that very tricky (and ones which usually most important ones). Because they called not at the moment when you call some external function, but at the moment when VM handling events (during interrupt).
You wanted to check if the methods necessary for the marshalling were removed or have to be implemented...
Yes, i will check, but i suspect it don't exists :)
Thx T.
-- Best regards, Igor Stasenko.
participants (3)
-
Igor Stasenko -
Stéphane Ducasse -
Torsten Bergmann