[Pharo-dev] The point of extending NativeBoost-Win32 more than neccessary?

Stéphane Ducasse stephane.ducasse at inria.fr
Wed Aug 14 01:53:26 EDT 2013


On Aug 14, 2013, at 4:05 AM, Igor Stasenko <siguctua at gmail.com> wrote:

> On 14 August 2013 00:57, Torsten Bergmann <astares at 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.
> 





More information about the Pharo-dev mailing list