Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0002406 [Squeak] VM minor always 12-24-05 03:10 05-27-08 18:35
Reporter wiz View Status public  
Assigned To tim
Priority normal Resolution won't fix  
Status closed   Product Version
Summary 0002406: Set cursor position primitive does not work and has not in some time.
Description The primitive for setting the cursor has not worked in some time
the primitive number (91 I think) duplicates the number used by some other function.

There are times when this ability would really come in useful. (E.G. setting the actual cursor position to the "temporary position" ). On my iMac the system clips the actual cursor when it would go off screen. This means when using a temporary cursor there are some portions of the actual screen that can not be reached.
Additional Information I brought this up on the mailing list a while back. And Tim mentioned that Squeak does not encourage the programing of a UI that allows the cursor to jump around. All well and good. Design issues should be solved at a different level than UI capabilities. The cursor position should be within the programmers control. And for that it needs to work in the VM.

This is a request that it be made to work. Thanks.
Attached Files  MouseMoveEnh-wiz.4.cs [^] (8,784 bytes) 03-04-08 07:52

- Relationships

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

related to 0006594new  [Fix] [Enh] A better way to handle Balloon-Fill adjustments 
related to 0006973new  [Enh] better MouseMoveEvent interaction with a targetPoint 
child of 0006671closed tim Build VMMaker for 3.9 

- Notes
(0011890 - 353 - 365 - 365 - 365 - 365 - 365)
bert
03-01-08 13:23

This is not as simple as it sounds - platforms differ in what events are reported when you set the cursor position.

Perhaps an equally (or more) useful primitive would be to freeze the cursor in place (so that it cannot leave the window) and enable reporting relative mouse movements? Not sure how simple that would be to implement for each platform.
 
(0011902 - 1264 - 1372 - 1372 - 1372 - 1372 - 1372)
wiz
03-04-08 07:52
edited on: 03-04-08 07:56

Hi Bert,

I stand by what I asked for. It was once a thing you could do and I don't quite understand why it should be difficult, even across platforms.

Still, Whether this can happen or not is up to the vm guru's and tim was nice enough to assign it to himself.

I did make my peace with not having this available. The key was inside the image to teach MouseMoveEvent to be a little smarter.

What I was aiming for was a way to get targets to respond to mouse movements rather than follow the cursor.

So MouseMoveEvent move: targetPoint returns an point displaced by the movement of the mouse. This solves two problems. It allows constraints to be placed on the targetPoint after the mouse action (e.g. keep it within its owners bounds.) and it eliminates the need for a target offset (which would need to be continually updated.) At each move you can start fresh with the current target position. This give the target object a very lively feel.

In practice I use MouseMoveEvent moveAndTug: targetPoint which adds a small tug in the direction of the actual cursor to the mouse movement.

Uploaded is MouseMoveEnh-wiz.4.cs which is a current version of this code and the code it depends on.

It was created in 3.9 but should work in 3.8 .

 
(0011903 - 113 - 113 - 113 - 113 - 113 - 113)
bert
03-04-08 11:32

Could you add a small morphic example demonstrating this? I can't quite imagine what you're trying to accomplish.
 
(0011906 - 572 - 650 - 650 - 757 - 757 - 757)
wiz
03-05-08 05:05

Hi Bert,

Ha, Here I go slimming down the change set to just the relevant parts and here you want the full demo. :-)

see the related project 0006594 for an example in use.

We are getting somewhat off topic for this report which is vm focused.

I planned on adding more reports to cover the UI aspects of some of my recent enhancments. I've been in a creation phase and need to find time for a organizing and packaging phase to get to reports.

Reports are always more interesting to do when interest is there.


Yours in curiosity and service, --Jerome Peace
 
(0011907 - 233 - 245 - 245 - 352 - 352 - 352)
bert
03-05-08 09:27

I downloaded FunSqueak3.10alpha.7105.zip as suggested in 0006594 but could not find a #hasMoved method, or deltaVectors etc.

As for the VM focus of this report - I still do not have a clear high-level picture of what you want to do.
 
(0011909 - 809 - 896 - 896 - 896 - 896 - 896)
wiz
03-07-08 00:04

Hi Bert,

Thanks for your interest.

>As for the VM focus of this report - I still do not have a clear high-level picture of what you want to do.

I wanted to ask for the setCursor primitive to be made to work again.

I did not know what issues that would raise. And I thought and still think that it would serve squeak better to allow the user to dicide it he/she will use it than to have the vm decide he/she can't.

If there are specific problems related to doing that across systems then I hoped those who knew about them would report the particulars here so that those problems could be addressed.

Beyond reporting the problem and patiently waiting for others to respond (and answering their questions), I have no other abilities to affect the outcome.

Yours in service, -- Jerome Peace
 
(0011911 - 1151 - 1185 - 1185 - 1185 - 1185 - 1185)
bert
03-07-08 06:31

Well, we implemented this using FFI and found differing behavior regarding events generated by forcefully moving the cursor across platforms (Win/Mac/X11). You would have to specify exactly what you need here (e.g., the move primitive itself should not generate any mouse events). Then you would lobby for this on the vm-dev list, where presenting a real use case would be helpful instead of "I just want it".

In the case where we needed it, we did not actually want to move the cursor to some random place on screen. We instead used it as a work-around to emulate relative mouse events unlimited by the screen bounds, the actual cursor was blanked. That is why I am suggesting to think about your actual, high-level needs rather than asking for a primitive that is basically useless in itself.

And it's not as if the VM developers would deprive you of this (after all, you could implement it yourself, via FFI or VM modification). But you are asking real people to invest real time into some unspecified and, so far, unneeded functionality. Time spent better on some actual need, like the ability to enable relative motion events I suggested.
 
(0011912 - 2239 - 2461 - 2461 - 2567 - 2567 - 2567)
wiz
03-10-08 00:05

Hi Bert,

There are three phases to creation.

Inception, implementation and deployment (or not).

I set out at the inception phase because it seems to me squeak should not have a limitation as silly as not being able to put the cursor where you want it.

I don't have vm skills yet and so my report is as far as I've gotten with this.

The Os will stop the cursor at the edge of the screen is the reason why the limitation hurts.

The problem is now in an implementation phase though you are asking me to make a critical decision as to wheter it should be stopped here.

I don't know. I haven't gotten far enough into the implementation details to make a deployment (or not) decision.

What did the old primitive DO?

What precisely were the problems you ran into cross-platform that prevented you from creating the new one?

The original impetus for this request was the fill menu items.
Cursor was at the menu selecting move origin or move direction. Then the cursor was acting as the (out of place) origin or direction. What I had wanted was to start moving the fill parameters from where they were.

And it was precisely the os-stops-the-cursor-at-the-screens edge problem that prevented me from using a large target offset to represent the difference. There would be dead spots and murphy's law says they would turn up where you least wanted them.

The report is from two years and one season ago. My original emails probably start a year furthur back than that.

The work around for fills (0006973) is relatively recent. And it can probably be employed most of the time I would have needed the cursor to move. (If the cursor gets to far away I can just stop a move action, move the cursor back over the object and restart).

Does this mean the setCursor: is no longer needed? I don't know. It is no longer as urgent to me as before.

Still, I don't consider the reimplementation of #setCursor: worth closing at this point. Worth problems prove their worth by fighting back. You seem to have found some fight I didn't expect in this one.

Why not write up what you found to be problems. Then put this issue on a back burner for a while?

Hth,

Yours in curiosity and service, --Jeorme Peace
 

- Issue History
Date Modified Username Field Change
12-24-05 03:10 wiz New Issue
06-02-06 20:49 tim Status new => assigned
06-02-06 20:49 tim Assigned To  => tim
09-14-07 04:01 tim Relationship added child of 0006671
02-25-08 18:32 hyi Issue Monitored: hyi
02-25-08 18:32 hyi Issue End Monitor: hyi
03-01-08 13:23 bert Note Added: 0011890
03-04-08 07:52 wiz Note Added: 0011902
03-04-08 07:52 wiz File Added: MouseMoveEnh-wiz.4.cs
03-04-08 07:56 wiz Note Edited: 0011902
03-04-08 11:32 bert Note Added: 0011903
03-05-08 04:51 wiz Relationship added related to 0006594
03-05-08 05:05 wiz Note Added: 0011906
03-05-08 09:27 bert Note Added: 0011907
03-07-08 00:04 wiz Note Added: 0011909
03-07-08 00:33 wiz Relationship added related to 0006973
03-07-08 06:31 bert Note Added: 0011911
03-10-08 00:05 wiz Note Added: 0011912
05-27-08 18:35 tim Status assigned => closed
05-27-08 18:35 tim Resolution open => won't fix


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
88 total queries executed.
52 unique queries executed.
Powered by Mantis Bugtracker