Primtive 91/primCursorLocPut:
Locked
 
|
Hey everyone,
I was looking for a way to set the OS cursor position from Squeak and found primitive 91 (see screenshots), which used to do exactly that (also according to the blue book). Now it instead returns whether a pixel depth is supported by the display. Has an alternative for setting the cursor position been implemented? If not, what would be the correct way of re-adding that functionality? Taking over another primitive number? I read that some people resorted to using custom FFI, but I feel like it could be worth the effort to properly reintegrate the functionality. Usecases: for example in Photoshop you often have number inputs on the far right side of your monitor. These support clicking and dragging for changing the value. However, the cursor will almost immediately hit the right edge of the screen. To prevent this, the cursor position will keep being reset to the center of the slider element while the user is dragging. Further, games often use mouse input as a relative number, rather than absolute, by forcing the cursor to the center of screen after each frame and only taking the movement between each frame. This is most commonly seen in games with first person perspective. Thank you for any pointers! Best, Tom  Screenshot from 2019-12-07 11-16-13.png (31K) Download Attachment Screenshot from 2019-12-07 11-19-50.png (121K) Download Attachment |
Re: Primtive 91/primCursorLocPut:
|
|
I have to admit that I'm horrified that we still have the long-deadEventSensor>primSupportCurosorLocPut: method in the system - and not even deprecated! Clearly we need to remove the stupid prim call and I suppose we should be kind and merely deprecate some senders. Mind you that includes several moderately important methods in MVC-land (Controller>>#centerCursorInView, which is used by ControlManager>>#scheduled:from: and FillInTheBlank>>#show:, for example). Sigh. Well spotted! > On 2019-12-22, at 10:34 PM, Tom Beckmann <[hidden email]> wrote: > > Usecases: for example in Photoshop you often have number inputs on the far right side of your monitor. These support clicking and dragging for changing the value. However, the cursor will almost immediately hit the right edge of the screen. To prevent this, the cursor position will keep being reset to the center of the slider element while the user is dragging. > Further, games often use mouse input as a relative number, rather than absolute, by forcing the cursor to the center of screen after each frame and only taking the movement between each frame. This is most commonly seen in games with first person perspective. Surely the logic here is to keep the value of the last read (hardware) cursor position and then subtract it from the position next time around? And, of course, save that new position for the next cycle etc. You can set the HandMorph to use a suitable Form during the time you are doing this; probably something non-visible? Take a look at senders of HandMorph>>#showTemporaryCursor: for some ideas. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Fractured Idiom:- ICH LIEBE RICH - I'm really crazy about having dough |
Re: Primtive 91/primCursorLocPut:
|
|
In reply to this post by Tom Beckmann
Hi Tom, Hi Tim, Hi Ron, On Sun, Dec 22, 2019 at 10:34 PM Tom Beckmann <[hidden email]> wrote:
As Tim says we must remove, or at least reimplement primCursorLockPut: to say it is moo longer implemented ASAP.
Indeed, but not in the default VM. Qwaq/Teleplace/3D ICC extended the HostWindowPlugin: primitiveSetCursorPositionX:Y: #if TerfVM EXPORT(sqInt) primitiveSetCursorPosition(void) { ... result = ioSetCursorPositionXY(x, y); and implementationsfor ioSetCursorPositionXY exist in the Term VM source for some platforms. iOS :-( platforms//iOS/plugins/HostWindowPlugin/sqMacHostWindow.m sqInt ioSetCursorPositionXY(long x, long y) { return -1; } Unix :-) platforms//unix/vm-display-X11/sqUnixX11.c static long display_ioSetCursorPositionXY(long x, long y) { if (!XWarpPointer(stDisplay, None, DefaultRootWindow(stDisplay), 0, 0, 0, 0, x, y)) return -1; XFlush(stDisplay); return 0; } Windows :-) (but only in the Term VM sources in platforms/win32/plugins/HostWindowPlugin/sqWin32HostWindowPlugin.c). This needs to be ported). #if TerfVM sqInt ioSetCursorPositionXY(sqInt x, sqInt y) { return SetCursorPos(x,y) ? 0 : -1; } I'm pretty sure Ron has no issues with the Perf VM code getting integrated. And I think all those #if TermVM qualifiers can (and should) be discarded. So what we really need are a) an implementation for iOS Cocoa, and b) someone to put the energy into integrating the code, given that Vincent Blondeau extended HostWin dowPlugin with support for setting the window icon. SO the Term and opensmalltalk code has diverged a little.
You don't have to justify. primCursorLocPut: is essential GUi functionality.
_,,,^..^,,,_ best, Eliot |
Re: Primtive 91/primCursorLocPut:
|
|
Dear Elliot, dear all, do you have some insights or docs pages on how the HostWindowPlugin fits into the big picture at the moment? Trying DisplayHostWindow>>#examplePaint in Squeak trunk primtiveError's for me at the moment and I don't know what it should do exactly either. I always assumed it was meant to spawn additional windows, but never actually saw that in action. Only knowing the unix platform opensmalltalk code a little, my gut feeling would have led me to place primCursorLocPut: implementations in there, in one of the display plugins. To my understanding this would mean that we would have to occupy a new numbered VM primitive, as it used to be. Is that correct? Is this the desirable way? Or is the purpose of the HostWindowPlugin to supersede the platform's own window code? Thank you for the insights! Tom On Mon, Dec 23, 2019 at 8:28 PM Eliot Miranda <[hidden email]> wrote:
|
Re: Primtive 91/primCursorLocPut:
|
|
Hi Tom, On Mon, Dec 23, 2019 at 11:56 AM Tom Beckmann <[hidden email]> wrote:
The HostWindowPlugin is an internal plugin in the Squeak and Pharo VMs (at theist the opensmalltalk Pharo VMs). So one can rely on it being present. The HostWIndowPlugin is not the same as a host window facility where Morphic windows can be launched in native windows. Instead the HostWindowPlugin gives access to the host window in which the main Squeak desktop runs. For example, Terf uses it at login to resize the window into a login dialog sized window.
No. The plumbing for the various display plugins on Unix is via a struct that includes functions such as ioSetCursorPositionXY. See SqDisplay.h. So the issue is independent of needing a primitive number. I like to use primitive numbers for core Smalltalk and VM facilities and think that using HostWindowPliugin is entirely appropriate for primCursorLocPut: functionality.
As I understand it, the HostWindowPlugin's role is in providing additional control beyond e.g. the beDisplay primitive.
_,,,^..^,,,_ best, Eliot |
Re: Primtive 91/primCursorLocPut:
|
|
In reply to this post by Tom Beckmann
> On 2019-12-23, at 11:56 AM, Tom Beckmann <[hidden email]> wrote: > > Dear Elliot, dear all, > > do you have some insights or docs pages on how the HostWindowPlugin fits into the big picture at the moment? Right now the HostWindowPlugin is almost unused. It was written ... crikey, 15 years ago, as part of the sophie text/media-editor project with the intention of finally quieting the constant whines about how Squeak had to do host windows & menus etc or it would immediately fail and die away. Guess how many people actually did anything once we had the ability to open many host windows and draw in them? Think of a very round number.... Having said that, some of the functionality is integrated into the core of the vm; the main (only!) window is at least in some platforms part of the host window list. The prims for finding and setting window sizes, positions and decoration stuff is used I think. Setting the window label can be done with it. It needs better integration into the vm generally. It is my claim that no window should be created until (and unless!) something is displayed, which would make headless scripting/server operation considerably simpler. It's how I always had it working on the RISC OS vm. At one point in the deep past there were some issues that apparently made that not practical for Windows but I think even microsoft have managed to move past that now. > Trying DisplayHostWindow>>#examplePaint in Squeak trunk primtiveError's for me at the moment and I don't know what it should do exactly either. I always assumed it was meant to spawn additional windows, but never actually saw that in action. It is supposed to work and indeed did at some point. So far as I can see both linux & mac have the HostWindowPlugin loaded, each has the right class logged as active but both fail to create a new window. Taking a quick look at the vm code I think both ought to be working. Evidently I'm wrong... > > Only knowing the unix platform opensmalltalk code a little, my gut feeling would have led me to place primCursorLocPut: implementations in there, in one of the display plugins. To my understanding this would mean that we would have to occupy a new numbered VM primitive, as it used to be. Is that correct? Is this the desirable way? Or is the purpose of the HostWindowPlugin to supersede the platform's own window code? Hmm, sort of not. A prim to set cursor position could go anywhere in the vm. I'd say the host window plugin would be sensible because yes, it really ought to be where all the host window stuff goes. Even if one put it in the core vm it need not use a primitive number; we can have named prims there too. As an aside, I'd really like the keyboard input code to move to the HostWindow plugin too. But then there is a huge stack of cleanups I think need doing... It needs to be able to fail because (IIRC) some windowing systems don't allow it. Personally I'd be very careful about using it; anything that yanks my 'attention point' away from where I've put it is usually unwelcome. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Never do card tricks for the group you play poker with. |
Re: Primtive 91/primCursorLocPut:
|
|
In reply to this post by Eliot Miranda-2
> On 2019-12-23, at 2:34 PM, Eliot Miranda <[hidden email]> wrote: > > As I understand it, the HostWindowPlugin's role is in providing additional control beyond e.g. the beDisplay primitive. John & I very definitely wrote it to provide multiple host windows... and it worked. Just none of the people loudly proclaiming it was essential ever did anything to actually use it. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim "Both.." said Pooh, as the guillotine came down |
Re: Primtive 91/primCursorLocPut:
|
|
In reply to this post by Eliot Miranda-2
On Mon, Dec 23, 2019 at 2:27 PM Eliot Miranda <[hidden email]> wrote:
Agreed! Feel free to integrate it! Happy Holidays Everyone! Ron
|
|
|
In reply to this post by timrowledge
On Tue, 24 Dec 2019 at 06:44, tim Rowledge <[hidden email]> wrote: > > Right now the HostWindowPlugin is almost unused. It was written ... crikey, 15 years ago, as part of the sophie text/media-editor project with the intention of finally quieting the constant whines about how Squeak had to do host windows & menus etc or it would immediately fail and die away. > > Guess how many people actually did anything once we had the ability to open many host windows and draw in them? Think of a very round number.... > > Having said that, some of the functionality is integrated into the core of the vm; the main (only!) window is at least in some platforms part of the host window list. The prims for finding and setting window sizes, positions and decoration stuff is used I think. Setting the window label can be done with it. > > It needs better integration into the vm generally. It is my claim that no window should be created until (and unless!) something is displayed, which would make headless scripting/server operation considerably simpler. It's how I always had it working on the RISC OS vm. IIUC, Pharo has taken this to the extreme of having no windowing calls from the VM. i.e. In theory, "ALL" host windowing operations are done from the Image via FFI, but I've yet to familiarize myself with the details to determine how pure that statement is. I'm not sure how that interacts with the HostWindowPlugin. I'll ask. cheers -ben |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |