Apache OpenOffice (AOO) Bugzilla – Issue 20080
Object Bar changes causes rest of window to shift
Last modified: 2004-05-10 10:30:59 UTC
I notice this in the Drawing tool: when I select or deselect line objects the drawing area shifts up and down by what appears to be 1 pixel. It appears that the Object Bar for lines is 1 pixel shorter than other Object Bars, so when a line is selected the drawing area and the Main Toolbar increase height to compensate (shifting their contents up accordingly). The location of the status bar, overall window size, and the line of tabs/scroll/buttons under the drawing area (don't know what that line is called) do not shift. I am seeing this on 1.1rc3 on Windows 2000. I have verified this also happens in 1.0.3.1 on Solaris 8 (Sparc). I believe I saw it also on RC2 and RC1 on Windows, but I dont' have a handy way to double-check. I believe I also saw this on RC2 and RC3 on Linux, but again it's not in front of me at the moment. I would be happy to check other versions and platforms upon request, but it might take me a day or two to have a chance. I see this when I select lines (single lines or polygons). The object bar for no-selection, text, and rectangles are consistent (my drawings don't tend to include anything else). The only configuration changes to the drawing tool from the out-of-the-box configuration is setting a 0.25" grid, 3 points per, visible, snap on, guides on, 15-degree rotation snap. Note: I refer to a 1-pixel shift; please take the value of '1' to mean 'I believe it's 1 but it could be a small number'. I keep my screen at a high resolution so I can't clearly tell if it is exaclty a 1-pixel change or if it's slightly larger.
Additional info: it appears to be specifically the Bezier object bar. If I delesect "edit points" so that bar doesn't come up, I don't then get the shift.
Sorry, but this is not reproducible her. Would it be possible to attach screenshots of the two states to have a direct comparison where there is something missing? Thanks in advance.
Created attachment 9695 [details] Screenshot with no selection
Created attachment 9696 [details] Line object selected. Note difference in height of bezier bar
I have messed with the case a little more. If I add any drop-box to the bezier bar (e.g. line style) it then matches the height of the other bars. This holds true even if the drop-box is hidden. Only with the out-of-the-box defaults does it show the problem. Hence my new workaround: adding line style and color controls to the bezier bar. :-)
Set to new.
Reassigned to Christian. I still cannot reproduce this. But according to the screenshots the problem is there. Do you have any idea where this might come from? Thanks.
I can't reproduce this either, I played a bit with different font heights but for no avail. Carsten, do you have an idea? Or will this be no problem with the complete toolbar rework?
I cannot reproduce this problem either. The toolbar uses the heighest element to calculate its height. This looks like a problem with fonts. Kenneth can you please gives us more information about your system, like graphics card, which graphics card driver, desktop resolution. Did you change something in the options dialog that is connected to fonts, like OpenOffice-Fonts-Apply replacement?
As discussed: The sfx2 based layout manager only retrieves the height of every toolbar. The height is used to calculate the remaining size of the document window. You made proposal to also use the font size to calculate a generic toolbars size.
Font-wise there are two things I tend to do: - If the platform doesn't have an Arial font (i.e. non-Windows), I copy the Arial fonts from my win2k machine to whatever machine I'm using (on my Sun box the main program is installed as network install, and I use spadmin to pull in the fonts there). - Under the Config menu, in Text Document -> Basic Fonts I make all the defaults Arial. - I use Arial fonts for my drawings. For that, I evidently need to reselect it each time I restart the program (I didn't see a way to set a permanent default font in the draw program). [Nearly everyone I work with is a Windows/Office user; Arial seems to be in the "least common denominator" available on all their machines]. WRT machine configurations, here are the two machines on/under my desk. I can reliably reproduce the problem on either of them: 1. Dell P4/2GHz, 1GB RAM, Quadro 2 graphics, 1600x1200x32bppx85Hz, Windows 2000 SP2, OOo 1.1-rc3 2. Sun Ultra 2, 2x400MHz Ultrasparc II, 1GB RAM, Creator graphics (not Creator 3D), 1280x1024x24bppx76Hz, Solaris 8, KDE 3.1.1, OOo 1.0.3.1 Pretty much all that's common is between the KVM switch and the chair. :-) I would be happy to post my config files themselves if someone would kindly tell me which files they are. I will also continue to try to further characterize the problem. I'd be happy to run any tests.
Update: The released 1.1 version still has this issue under Windows 2000. It does not exhibit it under Solaris (both machines are the same as I described earlier). One thought ... on both these machines I've gone from version 1.0.3 to 1.0.3.1. On the Windows box I went through several of the 1.1RCs. Many moons ago on the Windows box I even had StarOffice 5.2. When I installed the released 1.1 I went on a search'n'destroy to remove all traces of old files, configs, and so on. On Solaris I know I got 'em all. On Windows things get tucked into so many corners I sincerely doubt I truly got everything - the registry for instance is largely a mystery to me, so if something was put there and uninstall (from add/remove programs) didn't take it out that might be affecting me. I did need to go through and redo my preferred Options settings but I surely don't know what other baggage might be around. So since others can't reproduce it, my [ignorant] hypothesis is that some ancient configuration trash was lying around interfering with something in the current installation. Like I said earlier, adding something with a drop-box to the Bezier bar eliminates the problem. Having line color/style/width there is handy anyhow, so ... :-) p.s. Excellent work, all!
The problem is that a toolbar that contains listboxes is slightly higher than one that only contains buttons. As mentioned above, I will try to make the fontsize part of the calculation of the toolbar height.
due to the new toolbar concept in OOo 2.0 (see: http://specs.openoffice.org/ui_in_general/toolbar_concept/openoffice_org_toolbar_spec.sxw ) this behaviour cannot occur anymore. toolbars will never be exchanged in place but new toolbars will appear instead.
closing