Apache OpenOffice (AOO) Bugzilla – Issue 80387
Objects with invisible border cannot be selected/moved with mouse
Last modified: 2013-02-07 22:39:28 UTC
Steps to reproduce: 1. Insert a rectangle. By default it has blue fill-in color and black border. 2. Now move the mouse over its border. Whenever the mouse is not on one of the six "handles", the pointer turns into a cross (made of four arrows). You can click anywhere on/inside the rectangle and move it by dragging it. 3. Now edit the rectangle to make the border invisible. You can still move the rectangle as before. 4. Now restore the border, and make the fill color invisible. Now you cannot click inside the rectangle to select it: You have to click near the border to select and move it. 5. Finally, make both border and the fill color invisible. Although you are aware where the rectangle is, you cannot pick it with mouse. You can not move it also. The only way is to throw (draw) a lasso around the object. But this method is impossible if you have multiple such invisible text boxes, and you want to select some particular objects from those. (Note that in Impress the Navigator does not help you select the desired objects, as in case of Writer). Desired: Although the rectangle is invisible to the naked eye, OOo should be able to "see it". Sample is attached.
Created attachment 47346 [details] Demonstrates how selection is impossible when border/fill color are invisible
You can traverse the objects with the tab key. To see a drawing object in the navigator you have to name it. It would be nice, if such invisible objects could be caught more easily, especially if they are created by accident.
It's an enhancement. Please have a look to cws navorder. In my mind this fix this enhancement.
Raindrops ->Ragina: Sorry - None of your observations/workarounds make much sense to me. **** @transparency by accident: When created, the rectangles are NOT transparent. The user has to MAKE them transparent by changing their properties. Such transparent text finds many uses in animations, where they are usually kept overlapping on some other image. In short, this is NEVER by accident, but by design. So Impress MUST be able to handle them. *** @using TABs to select a image: Using TAB is absolutely unworkable solution if you are trying to pick more than one objects (out of several present on the slide). And even if I am trying to select just one image, why should I go TAB, TAB, TAB, TAB... till I reach the desired rectangle? I may easily overshoot may target, in which case I may have to start all over again! *** @naming objects to see them in Navigator: Why should we have to name objects just to see them in Navigator? That's needless hard work! After all, we are not getting any benefits by naming them. In comparison, in Calc a named range can be used in a formula. What use does this named rectangle/arrow/image have in Impress? We are not proposing to turn this into a chess game, are we? There we have "move White Queen to D4". Similarly, in Impress we can say "move FIDO (a rectangle that we have lovingly named) upward by 0.675 cm" :D **** OK if you absolutely need the names, let Impress itself provide dummy names. (Do not ask the users to do this job.) An example template is- Image type + sequence of creation. e.g. rect005, arrow024, etc. Note that Impress automatically gives (arbitrary) names when we apply custom animation to any object. Apparently it maintains an internal list. Why not show it in the Navigator? Allow user to rename these generic names if he wants. (But I guess that only a few people would ever want to name their rectangles in this whole wide world.) ***** I can raise enhancement issues if you want..
Raindrops -> Bettina. I found that Issue 15297 (which is referred to YOU) actually suggests that Writer's Navigator should automatically take up the filename of the graphic. The Impress Navigator too must follow the same logic: 1. Provide automatic names to all shapes/graphics; and 2. In case of inserted graphics, put the filename in brackets. I am raising a separate issue (Issue 80549) for this, as I found no existing issue for this.