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.
