[Vm-dev] Removing most of the windowing code

[Igor Stasenko]

+10000000000000000000000000000000

amen to that.

especially this:
>I am also planning on making a standard interface for embedding the VM in
an application, at least as a static library. With this new building
system, this seems to be easy to do.

This is a holy grail!!!
Go, Ronie, Go!!!



On 24 November 2016 at 09:24, Esteban Lorenzano <estebanlm at gmail.com> wrote:

>
> Hi Ronie,
>
> First, this is super cool! I want this to happen since a lot of time :)
> Second, observation below
>
> On 24 Nov 2016, at 08:12, Ronie Salgado <roniesalg at gmail.com> wrote:
>
> Hello,
>
> I am working on removing most of windowing code from the VM, and in trying
> to unify the platform specific code of the VM. In the MinimalistHeadless
> branch of https://github.com/ronsaldo/opensmalltalk-vm I made the
> following changes:
>
> - Unified standard CMake building scripts for Unixes. I hate autoconf. I
> want to use them in Windows too.
>
>
> you cannot unilaterally do this.
> I hate autoconf too, but in VM list we have a general agreement on how to
> manage the VM build process, and unless you manage to convince the rest of
> people working there (and specially Eliot, who works there more than the
> rest), you have literally zero chance this will be adopted (and then, your
> work will be a general lose of time…).
> In any case, you have my vote :)
>
> - Refactoring the Unix entry points. I am trying to remove a lot of code
> for simplfying stuff.
> - Null window driver for true headless.
> - Optional SDL2 based traditional display backend for compatibility
> reasons, and because the extra Morphic worlds using OSWindow are a bit
> unstable.
>
> So far I managed to run a standard Pharo 6 image using this custom VM in
> Linux. Windows and Mac are coming next. Hopefully this is going to fix the
> problems with duplicated events when using OSWindow in Windows.
>
>
> this is sooo super :)
>
>
> I am also planning on making a standard interface for embedding the VM in
> an application, at least as a static library. With this new building
> system, this seems to be easy to do.
>
>
> even more super :)
>
> where can I see the code?
>
> Esteban
>
>
> BTW. When I tried the minimalistic Pharo image, in a completely headless
> VM, I got the following error:
>
> [ "Ugh .... now this is a biggie - a system that does not support
>         any of the display depths at all."
> Smalltalk
>     logError:
>         'Fatal error: This system has no support for any display depth at
> all.'
>     inContext: thisContext.
> Smalltalk quitPrimitive    "There is no way to continue from here" ] in
> DisplayScreen>>findAnyDisplayDepth
> DisplayScreen>>findAnyDisplayDepthIfNone:
> DisplayScreen>>findAnyDisplayDepth
> DisplayScreen>>setExtent:depth:
> DisplayScreen class>>startUp
>
> As a workaround, I am doing the following for ioHasDisplayDepth with the
> null driver:
>
> sqInt ioHasDisplayDepth(sqInt depth)
> {
>     return true;
> }
>
> In DisplayScreen class >> startUp we have the following:
> startUp  "DisplayScreen startUp"
>     Display setExtent: self actualScreenSize depth: Display nativeDepth.
>     Display beDisplay
>
> Does it make sense, to always trying to create a display in startup time?
>
> Best regards,
> Ronie
>
>
>
>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161124/c509b97d/attachment.html>