search

feenkcom / gtoolkit

Glamorous Toolkit is the Moldable Development environment. It empowers you to make systems explainable through experiences tailored for each problem.
https://gtoolkit.com
MIT License
1.08k stars 46 forks source link

Shortcuts do not work on Linux #9

Closed deech closed 5 years ago

deech commented 6 years ago

I can bring up the GT Playground screen via the menu but I am unable to inspect expressions. I tried 1 + 1. and Object new. just like in the regular Playground followed by Ctrl-i but that didn't work. I also tried Ctrl-o, Ctrl-P, Alt-o, Super-o and Ctrl-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 the Spotter with Shift-Return when GtPlayground is in focus.

girba commented 6 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.

deech commented 6 years ago

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.

girba commented 6 years ago

Ok, good point. Thanks for testing. We will look at it.

girba commented 5 years ago

This should be fixed now:

deech commented 5 years ago

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}.

gtplayground

girba commented 5 years ago

You should be able to do it now. Could you try?

deech commented 5 years ago

I am now unable to run the Metacello snippet. gtoolkit-test

girba commented 5 years ago

Hmm. Do you load this in a fresh folder?

deech commented 5 years ago

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.

girba commented 5 years ago

What operating system and what Pharo image are you using?

deech commented 5 years ago

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.

girba commented 5 years ago

Aha. Great. So, we can close this issue which is about loading, and move the conversation to #11?

girba commented 5 years ago

I will close the issue as it seems to be resolved.

girba commented 5 years ago

A piece of information about this bug. There is an inconsistency in Mac and Linux VMs when it comes to keyboard events:

akgrant43 commented 5 years ago

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.

akgrant43 commented 5 years ago

It's also working as expected in the GT Playground.

girba commented 5 years ago

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?

akgrant43 commented 5 years ago

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)

akgrant43 commented 5 years ago

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

girba commented 5 years ago

Thanks a lot for the investigation, @akgrant43!

@syrel what do you think?

syrel commented 5 years ago

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:

Space

(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.

Shift

(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.

Cmd (readme)

(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

akgrant43 commented 5 years ago

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

syrel commented 5 years ago

@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 😬

akgrant43 commented 5 years ago

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

j-brant commented 5 years ago

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;
girba commented 5 years ago

The VM fix was integrated: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1b837f94e96b93cb4d117ccdd010825d76dcde57

akgrant43 commented 5 years ago

Hi @j-brant ,

Thanks for finding this!

I can confirm that it solves the problem on Ubuntu 16.04.

Thanks again, Alistair

nodrygo commented 5 years ago

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__

akgrant43 commented 5 years ago

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)
nodrygo commented 5 years ago

yes this come when quit or save&quit save alone work fine so not too much important

thank for the very pleasant GT

akgrant43 commented 5 years ago

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).

girba commented 5 years ago

The shortcuts should now work on Linux. Download the image+vm from: https://dl.feenk.com/gt/GToolkitLinux64.zip

girba commented 5 years ago

The saving problem is already reported in #8