On Aug 14, 2013, at 4:05 AM, Igor Stasenko <[email protected]> wrote:
> On 14 August 2013 00:57, Torsten Bergmann <[email protected]> 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. >
