Closed deech closed 5 years ago
We used until now Cmd+g
for evaluate and go. We now also have Cmd+i
(update the code).
We are currently in a transition phase in which the Morphic and the Bloc world co-exist. Spotter is part of the Morphic world. When the focus is in the Bloc world, the key bindings remain in the Bloc world. This is expected and not a bug. The situation will get clearer once all tools will be implemented in the Bloc world.
Thanks for your quick response, since I don't have Cmd
on Linux I tried Alt-g
, Super-g
and Ctrl-g
just in case and none worked, they all just printed a red g
next to the expression.
Ok, good point. Thanks for testing. We will look at it.
This should be fixed now:
Unfortunately I just loaded from Github on a fresh 6.1 image and I still get it. I tried both Ctr-{D,G}
and Ctrl-Shift-{D,G}
.
You should be able to do it now. Could you try?
I am now unable to run the Metacello
snippet.
Hmm. Do you load this in a fresh folder?
I just loaded it from scratch with a fresh image and I'm unfortunately getting the same result as that screenshot from 4 days ago.
What operating system and what Pharo image are you using?
Pharo 6.1 - 64-bit(tech preview)
and Manjaro Linux 4.14.68-1
. To clarify loading from Metacello worked but I'm still not able to evaluate an expression in the Playground.
Aha. Great. So, we can close this issue which is about loading, and move the conversation to #11?
I will close the issue as it seems to be resolved.
A piece of information about this bug. There is an inconsistency in Mac and Linux VMs when it comes to keyboard events:
keyDown:
events for keys like shift
, ctrl
or meta
when I press the corresponding keys, whilekeyDown:
events for ctrl
when we release the key I'm not seeing this behaviour (Ubuntu 16.04).
Adding logging to:
Shows them being called at the expected times, i.e. as the ctrl key is being pressed and released.
How did you test it?
I should add, this is in a normal image. I'll check in the GTPlayground.
It's also working as expected in the GT Playground.
Our issue is at a lower level then Morphic.
@syrel used logging statements in HandMorph>>#generateKeyboardEvent:
. It appears that it is not called when we press a modifier key on Linux.
It's also working as expected in the GT Playground What do you mean by this? The new Playground is working as expected? In what way?
Hi Doru,
It's also working as expected in the GT Playground
What do you mean by this? The new Playground is working as expected? In what way?
I initially tested the events in an image without the GT alpha loaded, assuming that the issue would be down near the VM. That's when I wrote the initial message saying key events are working as expected.
Then I thought that maybe the GT playground was taking a different path, so went back and added the logging to the image with GT alpha loaded, and the event logging was the same, i.e. the keyUp and keyDown events are working as I would expect.
The modifier keys still aren't being recognised in the GT playground, but they are getting through to Morph>>handleKey[Down/Up].
@syrel used logging statements in HandMorph>>#generateKeyboardEvent:. It appears that it is not called when we press a modifier key on Linux.
If I add:
Stdio stderr
<< 'generate: ';
<< evtBuf printString;
lf.
to the start of HandMorph>>#generateKeyboardEvent:, pressing and releasing the ctrl key gives:
generate: #(2 12539244 251 1 6 0 0 1) generate: #(2 12539426 63 2 0 0 0 1) generate: #(2 12539765 251 1 6 0 0 1) generate: #(2 12539931 63 2 0 0 0 1) generate: #(2 12540260 251 1 6 0 0 1) generate: #(2 12540447 63 2 0 0 0 1)
Hi Doru,
Just a bit of progress on my side: I can see that the BlEventListener is being given the Ctrl-G event (BlEventListener>>handleEvent:) and that the event is never being consumed (BlKeystrokeEvent(BlEvent)>>consumed: true is never being sent).
HTH, Alistair
Thanks a lot for the investigation, @akgrant43!
@syrel what do you think?
Hi @akgrant43,
Thank you for looking into the keyboard events. However, I think you didn't notice what the actuall problem is.
Indeed, the keyboard events for shift
are sent but the question is when they are sent. We state that they are not sent when we press the shift button, but instead when we release it. This is a very important and crucial difference that does not let us to have simple and clear shortcut handling in Bloc on linux. In Bloc by design we assume that whenever a key is pressed - we get a keydown event (hence it has down in it), right after that for printable characters we get keystroke (or input) event that gets resent every X seconds depending on OS settings and finally when user releases her finger we get keyup event. Unfortunately this does not happen for keys like shift, alt and ctrl while perfectly works for regular keys like A, M, Z.
To prove the point I recorded videos that show this inconsistent behaviour:
(Youtube.com) Keyboard / Space in slow-motion it is clearly visible that the first event is sent as soon as I press the space button, then the second event is the keystroke and the last one is keyup when I release the space.
(Youtube.com) Keyboard / Shift there is no event being sent when I press the shift button, however we instantly get both keydown and keyup as soon as I release the button.
(Youtube.com) Keyboard / Cmd Long now it starts to be even more interesting. If I press and hold Cmd key long enough the events are never sent. Consider the case when I press and hold it for the shorter amount of time: (Youtube.com) Keyboard / Cmd Short the behaviour is the same as for shift, both events are sent when I release the button.
To conclude, this inconsistent behaviour prevents us from having cross-platform uniform shortcut implementation based in Keys not on Characters as it is implemented in Morphic. And we think that instead of hacking and adapting Bloc to this behaviour we should rather concentrate on the support of native windows through OSWindow (SLD2) and fixing this issue on VM side 😃
@eliotmiranda @girba
Hi @syrel ,
Thanks for your reply and clarification, however either I'm not able to duplicate the behaviour you're seeing, or I'm misunderstanding something.
If I add:
Stdio stderr
print: Time now;
<< ' ';
<< type;
<< ' ';
<< evtBuf printString;
lf;
flush.
to HandMorph>>generateKeyboardEvent: (after type has been set), and then press and release the Control, Shift and Alt keys in sequence, holding each down for a count of 3, I get:
9:10:40.479029 am keyDown #(2 4768590 251 1 6 0 0 1)
9:10:42.922001 am keyUp #(2 4771032 63 2 0 0 0 1)
9:10:46.360151 am keyDown #(2 4774521 255 1 5 0 0 1)
9:10:49.094662 am keyUp #(2 4777255 63 2 0 0 0 1)
9:10:51.712177 am keyDown #(2 4779823 247 1 12 0 0 1)
9:10:54.69724 am keyUp #(2 4782858 247 2 8 0 0 1)
From this I hope you can see that for all three buttons:
If I do the same for the space bar:
9:12:30.994936 am keyDown #(2 4879106 32 1 0 32 0 1)
9:12:30.995695 am keystroke #(2 4879106 32 0 0 32 0 1)
9:12:31.444765 am keyDown #(2 4879605 32 1 0 32 0 1)
9:12:31.445525 am keystroke #(2 4879605 32 0 0 32 0 1)
9:12:31.474569 am keyDown #(2 4879635 32 1 0 32 0 1)
9:12:31.475012 am keystroke #(2 4879635 32 0 0 32 0 1)
9:12:31.506148 am keyDown #(2 4879666 32 1 0 32 0 1)
9:12:31.506808 am keystroke #(2 4879666 32 0 0 32 0 1)
9:12:31.536745 am keyDown #(2 4879697 32 1 0 32 0 1)
9:12:31.537134 am keystroke #(2 4879697 32 0 0 32 0 1)
9:12:31.56789 am keyDown #(2 4879730 32 1 0 32 0 1)
9:12:31.56831 am keystroke #(2 4879730 32 0 0 32 0 1)
9:12:31.59838 am keyDown #(2 4879758 32 1 0 32 0 1)
9:12:31.598883 am keystroke #(2 4879758 32 0 0 32 0 1)
9:12:31.628889 am keyDown #(2 4879789 32 1 0 32 0 1)
9:12:31.629316 am keystroke #(2 4879789 32 0 0 32 0 1)
9:12:31.65922 am keyDown #(2 4879820 32 1 0 32 0 1)
9:12:31.659616 am keystroke #(2 4879820 32 0 0 32 0 1)
9:12:31.690491 am keyDown #(2 4879851 32 1 0 32 0 1)
9:12:31.69092 am keystroke #(2 4879851 32 0 0 32 0 1)
9:12:31.716902 am keyUp #(2 4879877 32 2 0 32 0 1)
What am I misunderstanding?
Thanks again, Alistair
@akgrant43 Interesting 🤣🤣
To be honest I have no idea why it works for you but doesn’t work for multiple other people. We are debugging this for the latest Pharo7 64bit with latest VM on Linux Mint 64bit.
wget -O- https://get.pharo.org/64/alpha+vmLatest | bash
In any case I have a video proof that it doesn’t work in that particular configuration 🤷♂️ I also see that it works in your case, which scares me even more...
Funny stuff 😬
Hi @syrel ,
I downloaded vmLatest and still see the same behaviour.
I'm on Ubuntu 16.04:
$ uname -a
Linux alistair-xps13 4.15.0-39-generic #42~16.04.1-Ubuntu SMP Wed Oct 24 17:09:54 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Linux Mint, if I remember correctly, is typically based on a fairly old version of Ubuntu (not that mine is recent :-)). Maybe there's a change in the kernel or graphics stack?
HTH, Alistair
I have gotten the keyboard shortcuts to work under my Linux Mint installation. There were a few issues. First, the KeyboardKey class was using the wrong key table for Unix. Second, the right Unix key table was missing the right control & alt keys. These were addressed in https://pharo.manuscript.com/f/cases/22769 and have been integrated into the latest Pharo build.
The other issues were VM issues. When you pressed and then released either the control or shift keys, the correct key would be recorded as pressed, but character code $? would be reported when the key was released. This causes the editor to believe the control key was still pressed even after it was released since it never got the key up for the control. The other VM issue was that A-Z keys being pressed when the control was pressed was being reported as character code 1-26 instead of the letters a-z. On the other platforms, they are reported as letters with the control key pressed. On Linux, they were reported with the control key down, but with character codes 1-26. To fix the VM issues, I added some code to the x2sqKeyPlain method in sqUnixX11.c file before the return (https://github.com/j-brant/opensmalltalk-vm/commit/37e3abfe8c7b975fe35d74aa6f2fceec885d0bd2):
if (charCode >= 1 && charCode <= 26) {
/* check for Ctrl-letter that gets translated into charCode 1-26 instead of letters a-z */
KeySym keysym = *symbolic;
if (keysym >= XK_a && keysym <= XK_z)
return (int)'a' + (keysym - XK_a);
if (keysym >= XK_A && keysym <= XK_Z)
return (int)'A' + (keysym - XK_A);
}
if (charCode >= 246 /* XK_Alt_R */ && charCode <= 255 /* XK_Shift_L */) /* hard coded values from translateCode */
/* The shift, ctrl, alt keys shouldn't be translated by the recode below */
return charCode;
The VM fix was integrated: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1b837f94e96b93cb4d117ccdd010825d76dcde57
Hi @j-brant ,
Thanks for finding this!
I can confirm that it solves the problem on Ubuntu 16.04.
Thanks again, Alistair
thank's now Shortcuts are working but after a call to any GT tool the save image fail with
stack page bytes 8192 available headroom 5576 minimum unused headroom 5992 (Segmentation fault) ./pharo-ui : ligne 11 : 8506 Abandon (core dumped)"$DIR"/"pharo-vm/pharo" "$@"
last line of coredump if that help
_C stack backtrace & registers: rax 0x024e7e60 rbx 0x7f3fbf203080 rcx 0x00000003 rdx 0x00000018 rdi 0x7f3fcde732d0 rsi 0x7f3fcde732d0 rbp 0x7f3fbf203428 rsp 0x7fff6e816d18 r8 0x7f3fbf130820 r9 0x00000000 r10 0x00000004 r11 0x7f3fcd41af90 r12 0x7f3fbf2030e0 r13 0x00000000 r14 0x00000001 r15 0x7f3fbf12fc60 rip 0x024ecfc0 *[0x24ecfc0] /home/ygo/pharo/vm7b/pharo-vm/lib/pharo/5.0-201812150909/pharo[0x41b073] /home/ygo/pharo/vm7b/pharo-vm/lib/pharo/5.0-201812150909/pharo[0x41cab5] /lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f3fcd661390] [0x24ecfc0] [0x0] Smalltalk stack dump: 0x7fff6e82cb68 M >primShutdownPlatform 0x7155570: a(n) 0x7fff6e82cbb8 M FFICalloutAPI>function:module: 0x2a269a8: a(n) FFICalloutAPI 0x7fff6e82cbf8 M (Object)>ffiCall: 0x7155570: a(n) 0x7fff6e82cc40 I >primShutdownPlatform 0x7155570: a(n) 0x7fff6e82cc70 M [] in >stop 0x7155570: a(n) 0x7fff6e82ccb0 M BlockClosure>ensure: 0x2a0cc28: a(n) BlockClosure 0x7fff6e82ccf8 I >stop 0x7155570: a(n) 0x7fff6e82cd38 I >shutDown: 0x7155570: a(n) 0x7fff6e82cd70 M ClassSessionHandler>shutdown: 0x72f0568: a(n) ClassSessionHandler 0x7fff6e82cdb0 M [] in WorkingSession>runShutdown: 0xbabe7e0: a(n) WorkingSession 0x7fff6e82cdf8 M [] in WorkingSession>runList:do: 0xbabe7e0: a(n) WorkingSession 0x7fff6e82ce28 M BlockClosure>on:do: 0x2a0c918: a(n) BlockClosure 0x7fff6e82ce70 M [] in WorkingSession>runList:do: 0xbabe7e0: a(n) WorkingSession 0x7fff6e82ceb8 M Array(SequenceableCollection)>do: 0x29ec660: a(n) Array 0x7fff6e82cf00 I WorkingSession>runList:do: 0xbabe7e0: a(n) WorkingSession 0x7fff6e82cf50 I WorkingSession>runShutdown: 0xbabe7e0: a(n) WorkingSession 0x7fff6e82cf98 I WorkingSession>stop: 0xbabe7e0: a(n) WorkingSession 0x7fff6e82cff0 I SessionManager>launchSnapshot:andQuit: 0x2f718e8: a(n) SessionManager 0x7fff6e82d060 I [] in SessionManager>snapshot:andQuit: 0x2f718e8: a(n) SessionManager 0x7fff6e82d0a0 I [] in BlockClosure>newProcess 0x29abeb8: a(n) BlockClosure__
I remember seeing a similar crash when I tried this earlier. Now running a debug VM and attempting to quit gives:
Thread 1 "pharo" received signal SIGSEGV, Segmentation fault.
0x0000000000971590 in ?? ()
(gdb) bt
#0 0x0000000000971590 in ?? ()
#1 0x00007ffff2d2bc43 in nsTHashtable<nsBaseHashtableET<nsISupportsHashKey, nsCOMPtr<nsIAtom> > >::s_ClearEntry(PLDHashTable*, PLDHashEntryHdr*) () from /dev/shm/p7/libMoz2D.so
#2 0x00007ffff2b2c672 in PLDHashTable::~PLDHashTable() () from /dev/shm/p7/libMoz2D.so
#3 0x00007ffff2d29fbf in nsLanguageAtomService::Release() () from /dev/shm/p7/libMoz2D.so
#4 0x00007ffff2ac57b2 in gfxPlatformFontList::~gfxPlatformFontList() () from /dev/shm/p7/libMoz2D.so
#5 0x00007ffff2a5b4b9 in gfxFcPlatformFontList::~gfxFcPlatformFontList() () from /dev/shm/p7/libMoz2D.so
#6 0x00007ffff2a6efab in gfxPlatform::Shutdown() () from /dev/shm/p7/libMoz2D.so
#7 0x000000000054f2d9 in primitiveCalloutWithArgs () at /home/alistair/vmmaker/opensmalltalk-vm/src/plugins/SqueakFFIPrims/X64SysVFFIPlugin.c:5825
#8 0x00000000004b65ec in primitiveExternalCall () at /home/alistair/vmmaker/opensmalltalk-vm/spur64src/vm/gcc3x-cointerp.c:76885
#9 0x00000000004478bc in slowPrimitiveResponse () at /home/alistair/vmmaker/opensmalltalk-vm/spur64src/vm/gcc3x-cointerp.c:22362
#10 0x000000000043d3e3 in executeNewMethod () at /home/alistair/vmmaker/opensmalltalk-vm/spur64src/vm/gcc3x-cointerp.c:17485
#11 0x000000000043b72d in ceSendsupertonumArgs (selector=21330936, superNormalBar=0, rcvr=15817424, numArgs=1) at /home/alistair/vmmaker/opensmalltalk-vm/spur64src/vm/gcc3x-cointerp.c:16558
#12 0x0000000000a0010f in ?? ()
#13 0x0000000000000000 in ?? ()
(gdb) print printCallStack()
0x7ffffffbc528 M >primShutdownPlatform 0x74bb1e0: a(n)
0x7ffffffbc578 M FFICalloutAPI>function:module: 0xf033e8: a(n) FFICalloutAPI
0x7ffffffbc5c8 I (Object)>ffiCall: 0x74bb1e0: a(n)
0x7ffffffbc610 I >primShutdownPlatform 0x74bb1e0: a(n)
0x7ffffffbc640 M [] in >stop 0x74bb1e0: a(n)
0x7ffffffbc680 M BlockClosure>ensure: 0xee9f70: a(n) BlockClosure
0x7ffffffbc6c8 I >stop 0x74bb1e0: a(n)
0x7ffffffbc708 I >shutDown: 0x74bb1e0: a(n)
0x7ffffffbc740 M ClassSessionHandler>shutdown: 0x75ae4a8: a(n) ClassSessionHandler
0x7ffffffbc780 M [] in WorkingSession>runShutdown: 0x73ffe90: a(n) WorkingSession
0x7ffffffbc7c8 M [] in WorkingSession>runList:do: 0x73ffe90: a(n) WorkingSession
0x7ffffffbc7f8 M BlockClosure>on:do: 0xee9c60: a(n) BlockClosure
0x7ffffffbc840 M [] in WorkingSession>runList:do: 0x73ffe90: a(n) WorkingSession
0x7ffffffbc888 M Array(SequenceableCollection)>do: 0xee8500: a(n) Array
0x7ffffffbc8d0 I WorkingSession>runList:do: 0x73ffe90: a(n) WorkingSession
0x7ffffffbc920 I WorkingSession>runShutdown: 0x73ffe90: a(n) WorkingSession
0x7ffffffbc968 I WorkingSession>stop: 0x73ffe90: a(n) WorkingSession
0x7ffffffbc9c0 I SessionManager>launchSnapshot:andQuit: 0x14718e8: a(n) SessionManager
0x7ffffffbca30 I [] in SessionManager>snapshot:andQuit: 0x14718e8: a(n) SessionManager
0x7ffffffbca70 I [] in BlockClosure>newProcess 0xea9d08: a(n) BlockClosure
$1 = void
(gdb)
yes this come when quit or save&quit save alone work fine so not too much important
thank for the very pleasant GT
I had a quick look at the VM crash mentioned in issue #9. MozServices class>>start basically does:
[ self primStartServices.
self primStartGfxConfig.
OSPlatform current mozSettings export.
self primStartPlatform ]
while MozServices class>>stop does:
[ self primShutdownServices.
self primShutdownPlatform.
self primStartGfxConfig ]
Normally services are stopped in the reverse order in which they are started. If the order in #stop is changed to be the reverse of #start the crash doesn't occur. I don't understand the Moz library at all, so someone with more knowledge should look at this (if you're interested).
The shortcuts should now work on Linux. Download the image+vm from: https://dl.feenk.com/gt/GToolkitLinux64.zip
The saving problem is already reported in #8
I can bring up the
GT Playground
screen via the menu but I am unable to inspect expressions. I tried1 + 1.
andObject new.
just like in the regularPlayground
followed byCtrl-i
but that didn't work. I also triedCtrl-o
,Ctrl-P
,Alt-o
,Super-o
andCtrl-Return
.OTOH the URL evaluator works great, when I click the Down Arrow I can see the Content Inspector, so maybe there is some issue with keyboard vs. mouse entry?
I notice some of the GtPlayground docs mention
Cmd-o
and I'm running Linux so maybe that's the issue?Another issue is that
GtPlayground
swallows keyboard shortcuts, so for instance I can't bring up theSpotter
withShift-Return
whenGtPlayground
is in focus.