Currently it is only possible to maximize Squeak by using the button in the MainDockingBar (it is not possible by using the green button on the window what is slightly unexpected but ok).
The fullscreen I get is a Squeak that looks like a typical Mac fullscreen but has several drawbacks:
* it is not a new desktop with only the app, but consumes the current desktop
* if you change desktop you get strange behaviour with the dock appearing
* if you use a second monitor and have a Squeak in fullscreen on your first you get a black background stretched over the whole second monitor
The expected behaviour for fullscreen would be a native Mac OS fullscreen.
(@ronsaldo someone mentioned to me that is due to the new metalshaders)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/407
Tim Johnson reported a problem with 32b Linux builds:
http://forum.world.st/Linux-Squeak-VM-X11-keyboard-changes-td5099584.html
Pressing ctrl-d now acts like debugIt instead of doIt like in the 64b. Ctrl-p also stopping working.
I did a bisection of all versions in https://bintray.com/opensmalltalk/vm/cog/ and narrowed down the problem to
good squeak.cog.spur_linux32x86_201811272342.tar.gz
bad squeak.cog.spur_linux32x86_201812301551.tar.gz
The error is consistent on both 18231 and the oldest 18221 released image for 32b VM but does not appear with 64b VMs.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/396
On Linux Mint Sylvia, I could not play sounds (e.g. ``SampledSound beep``). This occurred in the newest SWA VM build of Squeak.
Underlying problem seems to be that the Linux sound libraries for PulseAudio are not linked correctly.
(Maybe this is the same as #118)
With @krono I found this workaround:
``
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.0 LD_LIBRARY_PATH=/home/user/Dokumente/SWA2018.app/Contents/Linux-i686/bin/../lib/squeak/5.0-201810071412:/lib/x86_64-linux-gnu:/lib:/usr/lib/x86_64-linux-gnu:/usr/lib: /home/user/Dokumente/SWA2018.app/Contents/Linux-i686/bin/../lib/squeak/5.0-201810071412/squeak -vm-sound-pulse /home/user/Dokumente/SWA2018.app/Contents/Resources/SWA2018.image
``
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/360
on /build.linux32x86/pharo.cog.spur/build I run ./mvm and get
make[3]: *** No rule to make target '/usr/lib/i386-linux-gnu/libssl.so', needed by 'libgit2.so.0.25.1'. Stop.
I worked around it by running sudo ln -s /lib/i386-linux-gnu/libssl.so.1.0.0 /usr/lib/i386-linux-gnu/libssl.so but shouldn't be necessary as libssl is downloaded and built by the script.
The same happens with libcrypto
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/210
Seems to be something strange with the B3DAcceleratorPlugin on 32-bit macos. The pharo libB3DAcceleratorPlugin.dylib fails to link missing:
createOpenGLTextureLayerHandle
destroyOpenGLTextureLayerHandle
getMainWindowOpenGLContext
setOpenGLTextureLayerContent
The Squeak one links, but apparently against Metal, which isn't going to work since Metal is 64-bit only (or so I've been told).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/385
Building from the latest sources on the Cog branch, I see the attached image when loading various images using various OSX builds. I have tried the 64-bit Pharo, Squeak and newspeak builds with their associated images. I see some variation of the attached image below. If I rollback the source to the 201901172323 tag, I am able to build and load an image and see the window as expected.
<img width="811" alt="Screen Shot 2019-04-23 at 6 47 51 PM" src="https://user-images.githubusercontent.com/32800969/56627814-3fea6280-65fc-1…">
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/392
There is code that transforms the presumably latin-1 key value into approximately MacRoman encoding in platforms/win32/vm/sqWin32Window.c
I let the archeologists debate if this code dates from Jurassic period or more distant paleozoic era, all I know is that we pay for what we don't buy...
Thus I propose to entirely remove that piece of code and disentangle a bit the spaghetti keyboard handling.
We indeed do not need this extra level of complexity anymore, images do not use macRoman encoding for a long time
On the contrary, images have to undo the translation by sending `macToSqueak` message in various subclasses of `KeyboardInputInterpreter`.
For the transition period, old images running on new VMs, or new images running on old VMs, might encounter a few hickups while interpreting non ASCII characters in case of exotic `KeyboardInputInterpreter`. That won't be the case of main `UTF32InputInterpreter` since it mostly uses the utf32 code passed through `eventBuffer sixth` position rather than keyValue passed thru `eventBuffer third`, except for some CTRL+key for which the keyValue is more-than-often < 128, and thus unaffcted by the proposed change.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/401