Hello,
I downloaded a VM (64 bit Cog Spur Windows) and a fresh trunk image separately and have not changed any mouse button settings yet (swap mouse buttons preference is on and neither 1 button mouse nor 3 button mouse are selected in the VM preferences menu). My notebook does not have a middle "mouse" button and the right button currently does a blue click (opens the halo). In this default setting, is there any way to do a yellow click? I get the morph menu with ctrl+left click and in list morphs and on the world I can invoke the menu with the Esc key, but I did not find a modifier+button combination that would work universally to emulate a yellow click. Have I missed it? After disabling swap mouse buttons, right click becomes a yellow click. But when the preference is on, both right click and alt+left click produce a blue click. So with a two button mouse it seems that nothing is actually swapped, but one button is unavailable altogether... A simple solution would be to turn the preference off by default. Kind regards, Jakob |
Hi Jakob, do: "HandMorph showEvents: true" then do CTRL+RED/LEFT. You will see that you get, in fact, a yellow click. I think that there is code that checks for "control pressed" first to show the different menu. So, we do emulate that yellow-click in the VM, but we keep the "control pressed"-flag. So, the event state is different, even though you get "event yellowButtonPressed = true" both times. To sum up some prior thoughts on this topic: 1) The VM should not provide this single-button-mouse behavior but the image should. 2) The event filters to simulate those yellow/blue clicks are already possible in the image. We do it with mouse-wheel vs. CTRL+up/down already. 3) A good transformation for CTRL+RED in such a single-button-mouse mode would be YELLOW and not CTRL+YELLOW. Anyway, this is not an easy fix or decision to make. :-) Best, Marcel
|
Hi Marcel,
On Sun, Apr 22, 2018 at 11:24 PM, Marcel Taeumel <[hidden email]> wrote:
What would be relatively straight-forward is to add an image property flag alongside the ones in the image flag word such as "floats in platform order", "processPreemptionYields", etc in vm parameter 48. This flag would tell the VM not to do any event modifications (or at least no mouse button swapping). And then we could at least experiment with allowing the image to perform event modification, making this a preference, etc, before some fine day in the future, transitioning away from VM support for event modification in a major release. Thoughts?
_,,,^..^,,,_ best, Eliot |
Hi Tim, it is already in place to convert CTRL+UP/DOWN into MouseWheelEvents. See HandMorph >> #initForEvents HandMorph >> #filterEvent:for: HandMorph >> #generateMouseWheelEvent:direction: Would be nice if the VM would actually deliver mouse-wheel events. See: EventSensor >> #processMouseWheelEvent: EventSensorConstants class >> #initialize Would be VERY EASY to provide a similar conversion for CTRL+RED clicks if needed for single-button mice. Best, Marcel
|
> On 24-04-2018, at 10:55 PM, Marcel Taeumel <[hidden email]> wrote: > > > Would be nice if the VM would actually deliver mouse-wheel events. See: Well, indeed. You might argue that it would be nice for the VM to deliver the rawest event data possible and do all the work in the image, which might even be possible these days. There's plenty of potential for event systems that expect (rapidly) returned values or work via some variant of callback etc to cause 'fun'. Waaaaay back, ParcPlace started a project to drop the VM doing anything with event input and do it all via the contemporary equivalent of FFI. As a general concept it showed a lot of promise and quite a lot of work was done; as is so often the case it got dropped for some reason (I don't know why). It's sometimes interesting to contemplate being able to drop all the event and window (and preferably all the other OS) handling in the VM and move it up to the image. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: XI: Execute Invalid op-code |
Hi Tim, the VM does deliver "the rawest data possible" for most events. For mouse-wheel events, we lose the scroll-delta (or acceleration), though. And left/right wheeling from the MightyMouse. :-) Best, Marcel
|
> On 26-04-2018, at 12:09 AM, Marcel Taeumel <[hidden email]> wrote: > the VM does deliver "the rawest data possible" for most events. For mouse-wheel events, we lose the scroll-delta (or acceleration), though. And left/right wheeling from the MightyMouse. :-) Take a look at ioProcessEvents() and related code and tell me that with a straight face! We do huge amounts of mangling of incoming events before queuing them up for the image to read. If we were passing raw stuff to the image it would be all in the image, with OS specific classes to do the work. It can be done - has been done - but it isn't trivial. The earliest Squeaks had a very narrow channel to the VM and we had to do a great deal of messing around to get it to work for non-Mac systems, a lot of which we really ought not have done. But that was 20 years ago; the sad part is how little of that we've improved. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: SDP: Search and Destroy Pointer |
Of course there has to be a generic representation to account for OS specifics. It's a trade off. There is always a compromise. We extract meaningful data, put it in an array and let the Squeak image handle the object representation for it. That's as raw as you can and should get. Just my two cents. :-) Best, Marcel
|
> On 27-04-2018, at 1:52 AM, Marcel Taeumel <[hidden email]> wrote: > > Of course there has to be a generic representation to account for OS specifics. Actually there really doesn't (well, unless we count "there's this stuff in memory") need to be any abstraction within the *VM* layer. There doesn't even have to be a primitive to get the event data, not in the sense of primitiveFetchAbstractedEventDataAsMyKindOfArray. It is quite possible to make an ffi call (or maybe using Alien would be smarter) to fetch the OS event data and then process it entirely in the image. Yes, there may be a number of other ffi calls to pass some of it back to the OS for certain things. Yes, some OS's do very strange stuff. Actually, strike that - every bit of stuff I can remember about handling these things is a litany of ridiculous coding. There is/was an existence proof in the ancient 'Van Gogh' project from mid-90's ParcPlace. There were plenty of problems - especially back then Windows was ... deranged about this stuff. NT was actually quite reasonable IIRC (which given it is nearly 25 years ago may be a poor bet) and Mac OS wasn't too bad. OS/2 was in the picture as well, and I think that was seen as quite nice for this purpose. Even though I had a sorta-working RISC OS HPS back then it wasn't included in the project :-( The abstraction can be much higher than the untouchable VM if you want it to be. > It's a trade off. There is always a compromise. We extract meaningful data, put it in an array and let the Squeak image handle the object representation for it. Yes, trade-offs are where we have to look most of the time. The current arrangement has the advantage that you can (in theory and in most cases, in reality) make your new vm and process OS events in the VM and pass the array up and an image will (mostly) work on your new machine. That's good and has been very valuable. A downside is that any new OS event stuff will almost certainly require new VMs, whereas the 'Van Gogh' model would be fixable with a simple image update. It's a similar picture to much other OS interface. We currently have an ancient and somewhat creaky file interface with an assortment of added stuff that could all do with cleaning. It relies on a very narrow interface through the ANSI/Posix C lib, which was ok for initial creating of the platforms vms but isn't all that well suited to anything. We could perfectly reasonably create more platform supportive filing system access with ffi/alien calls. Again, an existence proof stems from ancient work, in this case by (mostly)Eliot & I back in the late 1980s when we had an ffi-equivalent based file interface for RISC OS that used raw OS SWI calls and meant that Eliot was able to write image level code that allowed us to read DOS discs on a machine that had a wildly different native disc data format. All we need is a boat-load of money to support changing everything..... tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Out there where the buses don't run. |
Free forum by Nabble | Edit this page |