View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0011775 | Scribus | Usability | public | 2013-10-09 21:21 | 2025-11-09 12:41 |
| Reporter | pygmee | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | x86 | OS | Debian | OS Version | wheezy |
| Product Version | 1.5.0svn | ||||
| Target Version | 1.6 milestone | ||||
| Summary | 0011775: Link tool unexpected offset | ||||
| Description | When using the new link tool by clicking on the text overflow box (bottomright of the frame), it happens that when drawing the next frame it is placed a bit on the left and lower of the mouse position. May bu just a cursor position pb but worth to be verified. This happens even if snap to items is on. | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
|
|
The link tool mouse pointer icon includes a little '+' that displays where the active pointing place is supposed to be. Alas, when clicking, the active place is not the '+' but at some distance on the left of the bottom left of the mouse pointer. It is as far left of the bottom left of the mouse pointer as the width of the mouse pointer itself seems to be. I remember i had the same type of issue with the 'import vector file' mouse pointer ; after a long discussion, we understood that the issue was also the active place in the mouse pointer icon that is used to specify the exact x,y for the action to be undertaken. As far as i remember, the active place for the vector import is the exact center of the mouse pointer, instead of being the upper left corner as expected. This is a bad place since there is no '+' marker there and the icon is not transparent at all... |
|
|
would it be enough to change the pointer image by adding a '+' at the right position ? |
|
|
it could do the trick, but i'm not sure since i dont know what is the today exact shape of the pointer image file including the invisible points, and how the acting position is transfered depending on the mouse position. To sum it up, main isssue is that x,y desired code action place are not x,y code click values, due to specific pointer's shapes. Solution can be to change pointer as you propose, or to adjust offset accordingly to pointer, or best would be both so as to achieve : 1- use pointers image where the x,y action place is obvious : a clear arrow or a '+' sign ensure this well. 2- use pointers image pointers where the canvas can be well seen closely around the action place (that is there should be lot of transparencies around the action place in the icon pointer). 3- improve how the acting xy position is transfered to the action, depending on the mouse position and depending on where is the action desired place in the pointer's image. Depending on the image, it might require adding or substracting some x,y offsets to the click position. As a consequence of 1 and 2, the link image is ok, but the 'import vector' icon is not, since it is a glob of pixels with no pointing part and no transparencies around clicking part. As a consequence of 3, the action code has to apply some dx,dy offset (depending on the pointer's shape) to the x,y received from the click event. |
|
|
Reminder sent to: JLuc When you get a moment, can you test and see if this is still an issue? I'm having some trouble understanding this report. |
|
|
Trouble is : the mouse pointer is not a pointer. It is a misleading complex shape with no clear and unambiguous pointing pixel + scribus code itself is misled. For more see comment my previous comment http://bugs.scribus.net/view.php?id=11775#c30717 |
|
|
The cursor seems now to be perfectly centered under the middle of the + at the top right of the new cursor. |
|
|
A long time passed ! I tested again and placement issues happen today again with scribus 1.6.4 1) before clicking the red cross at the bottom right of the existing overflowed frame - when the pointer hovers the red cross, it is a black hand shaped. - this is strange because black hands are used to change the size of the frame (move the bottom right corner) - there is no visible sign that clicking will activate a "create new frame" feature. it's not clear when clicking enables this feature exactly. Sometime it does, sometimes not, sometimes it enables to move the corner. One has to know that this is possible and be used to click in the right place. 2) when clicking - before clicking the red cross, the pointer is a black hand that has to hide hover the red cross - when clicking the red cross, the cursor jumps up and right. Jump distance is the height and width of the cursor - the + in the middle of the new pointer shape is even higher since it is up half pointer's height 3) when clicking a place for the new frame - the cursor jumps again left and down by the same distance but opposite direction : left and down - the cursor is now an arrow again - that arrow points exactly to the left top angle of the new shape : that is very comfortable and refreshing ! I'm not sure what happen under the hood so the description is uneasy, but here are possible improvements : - avoid the 2 position jumps - OR choose pointer shapes that dont lead to that jumpy rendering / feeling - OR keep the jumps but choose pointer shapes that point toward an identical=non-jumping point - OR (unsure) jump much further, so there is no ambiguïty ? - AND (= 0017677) before the first click, when hovering the red cross, change pointer when the click actualy triggers the new frame creation. One more issue : - when clicking the red cross, the black hand cursor jumps and becomes a new 2+frames pointer - when i dont move the pointer and click rightaway, an error pops and say "you cant link a frame to itself" because the jump position is too close to the first frame - when i close that error, the pointer has become a black hand (instead of the 2+frames pointer it was before), but keeps behaving as the 2+frames pointer |
|
|
JLuc, I have a hard time following your descriptions. Are they related to this ticket? If not, are they rather related to 0017677 ? I have the feeling that at least some of the are. Also the black hand, seems to be the cursor for moving a frame, when it is selected... If your issues are not part of this ticket, I'd prefer to close this and track them in new ticket or in the one I've linked above (if they matches what I describe in there). |
|
|
1) 2) and 3) describe chronological states of the user experience when using the link frame tool, and describe what happens / what is to be seen. What difficulties do you have understanding or reproducing these steps ? It looks quite very much a detailed version of the ticket text « When using the new link tool by clicking on the text overflow box (bottomright of the frame), it happens that when drawing the next frame it is placed a bit on the left and lower of the mouse position. » When taken precisely, this is point 3 of my description. But the same "placement" issue appears in step 2) also. However - one of the mentioned items is a dupe of 0017677 (it is stated in the text) -- the rest isn't. Should i remove it ? - the last paragraph ("One more issue") is related to the "link frame tool" but is not related to the original ticket. I mentionned it here because this is all about usability of the "link frame tool". Should i post a new report for it and remove it ? |
|
|
This tickets seems to be about the mouse cursor. My issues with your list, is that I don't get what is a bug and what is a bug, what a description of the current behavior, what are steps to reproduces, and what are wishes. I would prefer, if you create new tickets for issues that are not in 0017677 so that we can close this and fix bugs one after the other. |
|
|
Allready answered : « 1) 2) and 3) describe chronological states of the user experience when using the link frame tool, and describe what happens / what is to be seen ». ALL these are usability issues but you call them bugs if you wish. The fourth paragraphe is labelled as "possible improvements". It's a description of the behaviour that would feel "easy to use", "normal", "not buggy", "easy to grasp" . It can also be called "wishes". |
|
|
So here is a new report : 0017682 as a refreshed dupe of this page's issue And here is a new report 0017683 for a truly new report in my previous comment |
|
|
The original issue is solved. Other issues have been moved to specific tickets. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-10-09 21:21 | pygmee | New Issue | |
| 2013-10-10 21:18 | JLuc | Note Added: 0030710 | |
| 2013-10-11 07:05 | pygmee | Note Added: 0030716 | |
| 2013-10-11 07:47 | JLuc | Note Added: 0030717 | |
| 2013-10-11 07:47 | JLuc | Note Edited: 0030717 | |
| 2013-10-11 07:58 | JLuc | Note Edited: 0030717 | |
| 2013-10-11 08:04 | JLuc | Note Edited: 0030717 | |
| 2013-10-11 08:38 | JLuc | Note Edited: 0030717 | |
| 2013-10-11 11:07 | JLuc | Note Edited: 0030717 | |
| 2015-11-24 01:11 | Kunda | Note Added: 0037622 | |
| 2015-11-24 11:43 | JLuc | Note Added: 0037641 | |
| 2015-11-24 11:43 | JLuc | Note Edited: 0037641 | |
| 2015-11-24 12:41 | JLuc | Note Edited: 0037641 | |
| 2015-11-24 13:22 | JLuc | Note Edited: 0037641 | |
| 2015-11-24 13:27 | JLuc | Patch | => No |
| 2015-11-24 13:27 | JLuc | Additional Information Updated | |
| 2015-11-24 13:27 | Kunda | Target Version | => 1.6 milestone |
| 2015-11-24 13:27 | Kunda | Additional Information Updated | |
| 2015-11-24 13:27 | Kunda | Status | new => confirmed |
| 2015-11-24 13:35 | JLuc | File Added: issue11613 updated 2015 11 24.patch | |
| 2015-11-24 13:35 | JLuc | File Deleted: issue11613 updated 2015 11 24.patch | |
| 2015-11-25 00:37 | Kunda | Relationship added | child of 0002407 |
| 2025-11-08 18:06 | ale | Relationship added | related to 0017677 |
| 2025-11-08 18:13 | ale | Note Added: 0053197 | |
| 2025-11-08 18:13 | ale | Tag Attached: #tobeclosed | |
| 2025-11-08 18:56 | JLuc | Note Added: 0053203 | |
| 2025-11-08 18:58 | JLuc | Note Edited: 0053203 | |
| 2025-11-08 19:06 | JLuc | Note Edited: 0053203 | |
| 2025-11-08 19:07 | JLuc | Note Edited: 0053203 | |
| 2025-11-08 19:08 | JLuc | Note Edited: 0053203 | |
| 2025-11-08 19:08 | JLuc | Note Edited: 0053203 | |
| 2025-11-08 19:10 | JLuc | Note Edited: 0053203 | |
| 2025-11-08 19:12 | JLuc | Note Edited: 0053203 | |
| 2025-11-08 19:14 | JLuc | Note Edited: 0053203 | |
| 2025-11-08 19:16 | JLuc | Note Edited: 0053203 | |
| 2025-11-08 20:36 | ale | Note Added: 0053229 | |
| 2025-11-08 20:59 | JLuc | Note Added: 0053230 | |
| 2025-11-08 21:02 | JLuc | Note Edited: 0053230 | |
| 2025-11-08 21:03 | JLuc | Note Edited: 0053230 | |
| 2025-11-08 21:03 | JLuc | Note Edited: 0053230 | |
| 2025-11-08 21:04 | JLuc | Note Edited: 0053230 | |
| 2025-11-08 21:04 | JLuc | Note Edited: 0053230 | |
| 2025-11-08 21:09 | JLuc | Note Edited: 0053230 | |
| 2025-11-08 21:10 | JLuc | Note Edited: 0053230 | |
| 2025-11-08 21:54 | JLuc | Note Edited: 0053230 | |
| 2025-11-09 08:39 | ale | Note Added: 0053234 | |
| 2025-11-09 09:05 | JLuc | Note Added: 0053235 | |
| 2025-11-09 09:21 | JLuc | Note Added: 0053236 | |
| 2025-11-09 09:31 | JLuc | Note Edited: 0053236 | |
| 2025-11-09 09:32 | JLuc | Note Edited: 0053236 | |
| 2025-11-09 09:32 | JLuc | Note Edited: 0053236 | |
| 2025-11-09 12:41 | ale | Tag Detached: #tobeclosed | |
| 2025-11-09 12:41 | ale | Status | confirmed => closed |
| 2025-11-09 12:41 | ale | Resolution | open => no change required |
| 2025-11-09 12:41 | ale | Note Added: 0053237 |