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.