Bug 55846

Apologies that some fields in the bug description are incomplete, due to user (i.e. MY) typing error!

Those fields should read:

Current behavior:
When the Formatting toolbar is positioned/docked horizontally, the Font Size drop-down list expands correctly. When docked vertically, the Font Size drop-down list does not expand at all.

Expected behavior:
The Font Size drop-down list should expand whether the Formatting toolbar is vertically or horizontally positioned/docked.

Platform (if different from the browser):
Windows XP Pro SP3

[Reproducible] with "LibreOffice 3.6.3.2” German UI/ German Locale [Build-ID: 58f22d5]" on German WIN7 Home Premium (64bit) 

Problem is not limited to Writer, same with Calc and DRAW.

Not a new problem, inherited from OOo (I checked OOo 3.1.1)

In horizontal toolbar position a selector for font size is visible, in vertical position a 'Font Size'  icon is visible what does nothing.

Something what works fine with "LibreOffice 3.6.3.2” German UI/ German Locale [Build-ID: 58f22d5]" on German WIN7 Home Premium (64bit): 
Font Name selector In horizontal toolbar position a selector for font name is visible, in vertical toolbar position an icon ix visible, clicking it will open the Font dialog. 

An acceptable solution for the problem here would be to open the same dialog as the 'Font Name', a perfect slution would be to make appear w size selection box as we see in the horizontal toolbar.

The acceptable solution should be an easy hack.

I believe we should not have easy hacks without code pointers. :-)

I believe that's the "FontSizeBox" http://opengrok.libreoffice.org/search?q=&project=core&defs=FontSizeBox

I think this function do something http://opengrok.libreoffice.org/xref/core/svx/source/tbxctrls/tbunocontroller.cxx#361

Created attachment 73365 [details]
Findbar's dropbox isn't shown neither

Same behavior when the find bar is set to the left/right side vertically. See attached image.

Al: So what you are searching for is controlled in method ImplToolItem::GetSize(), in file vcl/source/window/toolbox2.cxx:

        if ( mpWindow && bHorz )
        {
            // get size of item window and check if it fits
            // no windows in vertical toolbars (the default is mbShowWindow=sal_False)
            Size aWinSize = mpWindow->GetSizePixel();
            if ( !bCheckMaxWidth || (aWinSize.Width() <= maxWidth) )
            {
                aSize.Width()   = aWinSize.Width();
                aSize.Height()  = aWinSize.Height();
                mbShowWindow = sal_True;
            }
            else
            {
                if ( mbEmptyBtn )
                {
                    aSize.Width()   = 0;
                    aSize.Height()  = 0;
                }
            }
        }

If you remove the bHorz above, and make sure that the code always execute 'mbShowWindow = sal_True' above (removing the width condition), you'll see the controls even in the horizontal toolbars.

The problem is though that their width will not adapt; will you be able to find out how to fix that, or do you need more pointers?

Hope that helps :-)

*** Bug 52518 has been marked as a duplicate of this bug. ***

*** Bug 45948 has been marked as a duplicate of this bug. ***

IMHO there are a few potential fixes for this bug - whereby we launch the right dialog + tab for these icons when they are in left docked mode.

We already have a mode where we can make 'fat / wide' toolbar which can be docked on the left - simply by re-sizing it's edge. IMHO it adds nothing useful to enforce that and/or make the toolbar by default waste a ton of screen real-estate / h-space by making it as wide as the maximum width of an embedded combo / selection widget. If we want to compact the toolbar we can already do that by manual re-sizing as discussed :-)

Of course - IMHO the most ideal outcome is to popup the selection widget neatly next to the button when it is pressed so that we don't get this dialog thrash, but a neat toolbar experience when it is clicked.

AFAICS Faisal's link was good for that.

Let's not keep bugs assigned for too long without any indication of progress.

Back to NEW as bug lost owner.

In order to limit the confusion between ProposedEasyHack and EasyHack and to make queries much easier we are changing ProposedEasyHack to NeedsDevEval.

Thank you and apologies for the noise

*** Bug 87411 has been marked as a duplicate of this bug. ***