Apache OpenOffice (AOO) Bugzilla – Issue 3813
Object moves when I click
Last modified: 2013-02-07 22:13:07 UTC
When you select an object in edit points mode it moves be the distance the UI changes size. The UI changes size to accomidate different icon sizes. It is very difficult to tell if this has happened until I look later and find the object has moved.
Created attachment 1308 [details] Watch carefully how one click moves the window and the object.
Reassigned to Wolfram.
Sorry, but I was not able to reproduce the bug. I have tested on 641c and 641d. Any further hints how to reproduce? Otherwise I have to close it. By the way: thanks for attaching those avi files! They make it quite convenient to understand the bug.
OK. Did some investigating. It has to do with the windows fonts. I was able to duplicate on my NT machine at home on 642 as well. If you right click on the desktop and select properties. Then pick the appearance tab. For the most dramatic affect select the "Windows Extra large" setting and Apply. Now you'll see that the text in the line styles, etc. add pixels to the height of the icon bar.
Yes, now I have it!! The edit points mode must be active so the points are marked when I click on the object with the select tool. Reassigned to Armin.
Reason is that indeed the draw object bar has different sizes in default mode and in point mode. Following scenario: MouseDown -> Object gets selected, since it is not known how long the user will hold the button or how far he will move the móuse, a drag interaction is started. At the same time the object gets selected. Selecting the object moves the draw object bar to the point mode. That again changes the visible area, thus a redraw is executed. That redraw is the standard redraw from SFX and - if the size differs enough - make the running drag action think the object was moved a bit. Releasing the mousebutton ends the drag action which moves the object since the delta distance (for not moving small distances on simply klicking) was moved. AW->MBA: What can be done here?
My idea is to prevent the toolbox from being shrinked when its content is exchanged.
@CD: IIRC this will not happen anymore with the new toolbar concept, because it always uses an area of fixed size.
.
Should be automatically fixed with the implementation of our new toolbar concept.
CD: Our new toolbar and docking design allows that toolbars have different heights/width. So this problem is now not a bug but a inescapable part of this feature. It has been requested by many people that comboboxes uses the system font size, even if the size is bigger than normal. The size of a toolbar depends on the elements inside the toolbar.
CD: I there are no objections I will close this issue.
It sounds like to me this problem will now be noticed by even more people. That is anyone that has accessability problems and require large menu fonts. So it seems to me that you would be leaving an obvious/annoying problem that affects those who have the most difficult time coping with it. If you know that toolbar is growning a particular amount then you should be able to trap this and compensate. just my 2c.
CD->CJ: Can you please check if we can change something in our concept to support skiani.
I propose the following. Toolbars can have different heights, but with the following exectpions. - Toolbars docked in one row shall provide same heights - Toolbars changing its content caused by different contexts shall always have the max. needed height. This assures that the toolbar heights does not jump.
Created attachment 16565 [details] toolbars with different heights
I propose the following. Toolbars can have different heights, but with the following exectpions. 1. Toolbars docked in one row shall provide same heights 2. Toolbars changing its content caused by different contexts shall always have the max. needed height. This assures that the toolbar heights does not jump. CD: My comments to your proposed solution: 1. The current implementation has full support for it. 2. This is technically impossible to implement. Think about the situation that you have a row where one toolbar is docked without a combobox. Now a context sensitive toolbar with a combobox docks behind this toolbar. We have to extended the row height to fulfill point 1! This will violate 2. As we want to support toolbars with different heights point 2 is not possible. CD: I would propose to use this "defect" for the next meeting to discuss other solutions. CD->skiani: I am not sure what you mean with "able to trap this and compensate". Can you please explain your idea. We thought about a solution that the applications don't move the content of the document, but this is also not possible. There are applications like Draw which uses a dynamic zoom factor. We have different requirements which are sometimes very difficult to combine into one solution. CD->CJ: Please take over until we have decided about a final solution.
I guess what I ment by trap was a fix to the specific situation. I'm not sure I'm really qualified to provide a specific fix. But, it seems that if you know that icons are about to change because of a selection you are going to make then the exact mouse location (relative to the page/scale before the icon change) could be held constant. In other words move the mouse point to compensate. An alternative would be to keep the page from moving when the icons change, i.e. if the menu bar gets bigger just have it overlap the page more or less such that the page does not move. I don't know if that helps or not.
CJ: Changed taget milestone to OO.o Later