BMenuField: allow to use non-fixed size in combination with layout mode

In fixed size mode, the menu field always uses all the available width.
In non-fixed size mode, the menu field will resize itself to be as small
as possible.

With layout, usually the difference isn't noticeable, since the layout
will already try to resize the control to the smallest possible size.
But there are a few cases where it makes a difference, when the layout
is over-constrained and the menu field can't be made as small as
possible. In that case, the menu field would be forced to fill its
allocated space, where we can instead make it a little smaller.

Change-Id: I911d497218a09aab3824865968558df5d4b3cf98
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6076
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>

interface & app_server: Fix missing parentheses near ternary operators.

+ has greater operator precendence than ?, so we need parentheses when
using both in expressions. Both of these look like actual bugs.

Spotted by Clang.

Interface Kit: Remove more non-BControlLook code.

BMenu: Remove _ from protected method _DrawItems

BMenu and friends: style fixes

BMenuBar: style fix: msg => message

MenuPrivate: style fixes

MenuItem: 80 char limit style fix

MenuBar: tiny style fix

Menu: tiny style fix, indentation

Menu: Small refactor

Implement _SetIgnoreHidden() in header
Change on to ignoreHidden
Change on in _SetStickyMode to sticky

_BMCItem_: tiny whitespace style fix

Menu: style fixes, rename msgr => messenger

BMenu: style fix, pointer != NULL

BMenu::Archive rename ret to status

Also check pointer against NULL explicitly

BMenuItem style fixes: rename abbreviation, pointer style

kits/interface: Convert to using Set*UIColor.

Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Patches 0003-0017 from looncraz, unmodified.

re-add the _BMCItem_ class for binary compatibility.

This was removed in hrev17147, because our implementation of BMenuItem
does not uses it anymore. However, we must keep it in order to properly
unarchive BMenuFields that were archived in BeOS.

One application that was crashing because of this is VNCViewer.

BMenuField: style fixes

BMenuField: Draw everything on resize

* The label might be truncated, in which case the entire width needs to be
redrawn when the menu field shrinks or grows.
* Invalidating the border in the parent looked a bit weird. Simplified.

BMCMenuBar: Refactor MakeFocus()

Get rid of unused fRunner variable.

It is very basic now, it just works.

Also, renamed msg to message in MessageReceived() and
declared MakeFocus() above it (alphabetically).

Menu and friends: Style fixes, no functional

... changes intended.

* 80 char limit fixes
* Indentation fixes
* Braces style fixes
* Use ternary operator where appropriate
* Rename menuItem to just item and declare it once outside
the loop
* Omit 3rd param of GetMouse() because it is default
* Rename variables eg state => focused and menu => submenu
* Indent comments below line they apply to
* Reword some comments
* Add some #pragmas

MenuField: enable/disable the menu field when...

the child menu bar or the child menu bar's menu is enabled/disabled.

This means that there is just one status we have to check, the menu
fields, and the child menus agree. This change takes practical form
in the Backgrounds preflet which disables the placement menu when
the image is set to "None", but, only the menu got disabled and not the
parent menu field so the label was erroneously still drawn as enabled.

Don't set MaxContentWidth on the menu bar of a BMenuField

Fixes #9816

It is no longer necessary, or even desirable for us to set the max
content width of the menu bar of a BMenuField now that BMenuItem
truncation and BMenuField sizing are working.

The user may, however, wish to set the max content width of the menu
bar of a BMenuField themselves like so:

menuField->MenuBar()->SetMaxContentWidth(width);

and the Interface Kit will automatically deduct the left and right
margins from the width including the space used by the drop down arrow.

BMenuField: If fixed size always set max content width

When you resize, also set max content width.

Create a SetMaxContentWidth() method that includes the margins.

Resize menu field if below minimum width in auto-size mode

... cancelling the normal item truncation behavior.
This funcationality comes from BeOS R5, we need to reproduce it for
backwards compat. KeymapSwitcher depends on it at least.

Minimum width is 20px, was set in last commit, comes from BeOS R5.

Move constants to BMCPrivate.h and refactor

We use these constants in both MenuField.cpp and BMCPrivate.cpp

Incorporate kMarginWidth into kPopUpIndicatorWidth.

A small code simplication in FrameResized() along with replacing bare numbers
with magic constants.

Refactor _BMCMenuBar_::Draw a bit

Move the comments around, expand on them and an 80 char fix.

Adjust menu field's menu bar height in auto mode

On IRC diver pointed out to me that KeymapSwitcher had a menu field that
was drawing as just a line since my recent change to BMenuField. I did a
little research and discovered that this was because the menu field in
KeymapSwitch was not using the layout APIs and it's frame rect was set to
0 height.

I did a little more research and experimented with menu fields in
BeOS R5. I discovered that in R5 if the menu field is set to auto-size
mode then the menu bar inside ignores the height of the menu field frame
and uses the BMenuBar's preferred height instead.

So, I adjusted the BMenuField code in Haiku accordingly. This should make
Haiku match the behavior of BeOS R5 in auto-size mode. For fixed-size mode
it should also work the same, although some more testing is needed to
see if there are any regressions there.

BMenuField: Fix menu bar resizing in auto-size mode.

Fixes #9753 (for real this time)

Don't resize the menu field when the menu bar resizes, the menu
field stays the same size because we'll need to use it's width to
check when the menu bar width has expanded beyond its width.
Then, if the selected menu item expands the menu bar to a width
greater than the width of the menu field resize it to the menu field
width.

Resize menu field menu bar iff fFixedSize is true

If the menu field is not fixed size than the width of the menu bar
should depend on the menu item contents so just do the default and
get the Bounds() without any extra resizing.

BMCPrivate: Cleanup

Remove no longer needed header includes, most that I recently added
a few that were already there but just aren't needed anymore. Don't
use BPrivate::MenuPrivate namespace.

Put the label truncation code back in BMenuItem.

Just a few commits ago I moved the label truncation code out of
BMenuItem and into BMCMenuBar because the truncation had to happen
outside of BMenuItem. Turns out, that wasn't true so I'm moving the
label truncation back into BMenuItem and removing the _DrawItems()
method from BMCMenuBar.

Note that the code is not a copy of what was there before, but, the
updated version I created for BMCMenuBar. The main difference is that
I use menuPrivate.Padding() instead of GetItemMargins() and I always
use the width of the parent menu frame instead of using fBounds even
if the state is not MENU_STATE_CLOSED. These are changes needed for
BMCMenuBar but should work just as well for a regular BMenu.

Draw truncated menu label in BMCPrivate, fixes #9735

...instead of in BMenuItem and remove the truncation code from BMenuItem.

The label truncation code cannot work in BMenuItem because the super
menu helpfully resizes itself to fit the menu item. So, instead we do the label
truncation in BMCPrivate making sure that BMenuItem there can't expand the
BMCMenuBar because we set the width to fMenuField->_MenuBarWidth()
explicity.

Note that this only truncates the label in BMCMenuField, i.e. the label inside
the menufield, it does nothing to the labels of the menu items in the attached
BMenu or BPopUpMenu which is exactly what we want.

Set some static variables for magic number constants

Rework layout-enabled contructor for BMCMenuBar

Was passing !fixedSize into the view flags of BMenuBar, which made no sense.
Stop doing that, set fixedSize to true instead.

Remove the fixedSize parameter from this contructor, it's too late for that.

Remove pre-ControlLook drawing code in menu classes

Put the BMenuBar initilization on it's own line

Update header comments

Style fixes to BMenu and related classes.

Use be_control_look != NULL everywhere in the Interface Kit.

Should not be a functional change. It is not in the Haiku Coding Guidelines but
I feel like 'if (object != NULL)' is generally preferred to 'if (object)', plus
in this case of be_control_look that is the more common style.

Draw menus using the user chosen colors.

* Cleanup, no functional change.
* Remove superfluous operator=() implementations.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32174 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Only take the popup marker into account if fShowPopUpMarker is true.
* Automatic whitespace cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32173 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fix small style violation.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32172 a95241bf-73f2-0310-859d-f6bbb57e9c96

BMenuField's private menu bar did not take into account the width of the popup indicator when computing its minimum size. Fixes ticket #3635.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32171 a95241bf-73f2-0310-859d-f6bbb57e9c96

The button and menu field draw routines take a background color into account,
which makes the resessed frame blend better with the surroundings. This can
be seen best in Keymap, where a different color is set on some buttons, but
the resessed frame should still be the same across all those buttons.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29716 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed recently introduced regressions with layouted BMenuFields. When passing
fixedSize=true to the private BMenuBar class, it would set the follow mode
in AttachedToWindow() such that BMenu would calculate the minimum width
differently. Also fixes ticket #3606.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29691 a95241bf-73f2-0310-859d-f6bbb57e9c96

Various fixes to BMenuField behavior:
* In layout mode, using a BMenuField directly will make it behave like using
a fixed size BMenuField in non-layout mode. This is open for debate, but
not a change to the previous behavior. When using the Label and MenuBar-
LayoutItems though, the behavior is now changed to be more what one would
expect, ie the BMenuBar part is layouted across the full available width
just like it happens with BTextControls.
* Fixed invalidation of the BMenuBar when it auto-resizes according to picking
another item, and when it is resized due to layout changes.
* Fixed the problem with growing BMenuFields in file panels after changing
folders the first time. The fix is not so nice, but the purpose of setting
the menu item margins is to make sure it renders at the same vertical
offset as the BMenuField label. The better fix would be to change the
calculation of the content location or required margins in the BMenuItem
code... however the BMCPrivate code needs to account for the popup indicator
in the margins so I just kept the fix for the offset there as well.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29650 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented a new look for the Haiku interface controls. It was
overheard that they looked too ninety-ish.
TODO: The code behind this is work in progress. The basic idea
is to extract all drawing code into a new class BControlLook,
of which there is a global instance be_control_look, instantiated
in InterfaceDefs.cpp. At the moment, all the old drawing code is
still there, and the usage of be_control_look is inside if-bodies
checking the instance against NULL. In another words, by not
instanitating be_control_look, you can revert back to the old look.
BControlLook's job is to provide reusable methods for drawing
certain types of frames, backgrounds and labels, so that application
developers can make controls that re-use the same drawing code
as built-in controls and adopt to changes made there. I have added
the notion of "borders". Each of the frame drawing methods can be
made to draw certain borders only, which is supposed to help when
controls shall visually attach. This feature is not fully explored
at all ATM.
TODO: Update BColumnListView header view and BStringItem text
spacing. Update other apps where it makes sense to use BControlLook.
For the moment, only Tracker and LaunchBox are updated. More...
NOTE: The new look is not very radically different, so that existing
apps do not immediately look too ugly or out of place.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29221 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added a comment about the purpose of the code in AttachedToWindow().
* Improved FrameResized(). The "diff" is actually between the new location
of the right side (Frame().right) and the location where it probably was
in the parent before it is resized (fMenuField->Bounds().right - 2).
Could be that this change is wrong, or at least, not yet correct. Will
test on a different machine.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27507 a95241bf-73f2-0310-859d-f6bbb57e9c96

small cleanups


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22964 a95241bf-73f2-0310-859d-f6bbb57e9c96

* make absolutely sure there is no cyclic resizing


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22229 a95241bf-73f2-0310-859d-f6bbb57e9c96

* fixed size layout of BMenuBar on BMenuField in fixed size mode
(needs to account for the parts that the BMenuField draws, ie the shadow
on the right)
* fixed follow mode of BMenuBar in fixed size mode (B_FOLLOW_LEFT_RIGHT)
* don't resize the BMenuField in fixed size mode (endless loop), this should
be more robust anyways, since this endless loop would be triggered if an
application tried to manually resize menuField->MenuBar() in auto resizing
mode
* fixed calculation of the parts that need to be redrawn on resize


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22127 a95241bf-73f2-0310-859d-f6bbb57e9c96

* setting a different menu color with the menu preflet gives now visually
agreeable results (I hope)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21967 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implement _BMCMenuBar_::MaxSize() to override BMenuBar::MaxSize() and limit
the maximum width. The latter supports unlimited maximum width. The
_BMCMenuBar_ draws fine when resized wider than its min/preferred width, but
not the complete "button" area will cause the menu to open when being pressed.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21465 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added a filter to MenuField, so that mousedown messages caught by the inner menubar are redirected to the BMenuField's MouseDown() like happens on beos. That way we can track and invalidate correctly. Implemented Show/HidePopUpMarker

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17613 a95241bf-73f2-0310-859d-f6bbb57e9c96

Invalidate less in BMenuBar::FrameResized() and a bit more in _BMCMenuBar_::FrameResized(), removed unused _BMCItem_

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17417 a95241bf-73f2-0310-859d-f6bbb57e9c96

Enlarged a bit the BMCMenuBar's frame, so that it's drawn more nicely

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16795 a95241bf-73f2-0310-859d-f6bbb57e9c96

* _BMCItem_ is no longer used, but I didn't remove it
yet, just commented it out in BMenuField. As was expected,
nothing changed in any obvious way
* made the _BMCMenuBar_ draw the popup marked. I changed it
a bit, inspired from some mockup I saw, sorry I don't
remember where. I hope you like it (it is easily changed
back if you don't).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16444 a95241bf-73f2-0310-859d-f6bbb57e9c96

Partially reverted to 15464 to have less code duplication, now that the special case is handled in BMenu::CalcFrame()

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15944 a95241bf-73f2-0310-859d-f6bbb57e9c96

Small changes, nothing important

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15942 a95241bf-73f2-0310-859d-f6bbb57e9c96

Yesterday's commit triggered some other visual bugs: hopefully fixed them all. A disabled menufield now doesn't open its associated menu anymore.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15906 a95241bf-73f2-0310-859d-f6bbb57e9c96

menufields should default to B_ITEMS_IN_COLUMN. This fixes the workspaces menu (in Screen) opened at the wrong position. As a consequence of this, I had to change the drawing code a bit

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15892 a95241bf-73f2-0310-859d-f6bbb57e9c96

forgot about the right side extra room for the focus indication

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15464 a95241bf-73f2-0310-859d-f6bbb57e9c96

take care of resizing and cleaning up parent BMenuField in FrameResized(), fixes missing areas in Fonts and most likely other BMenuFields

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15413 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed wrong usage of ConstrainClippingRegion() introduced by myself a couple months ago

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15374 a95241bf-73f2-0310-859d-f6bbb57e9c96

MenuField layouts the menu bar better with respect to fDivider, it aligns better with other controls. fDivider in TextControl is an integer number now, small fix and small cleanup in Menu, Window::InitData takes an optional BBitmap token to construct an offscreen window, fixed PrivateScreen IndexForColor, View prevents being located at fractional coordinates as in R5, BBitmap unlocks its offscreen window since it is never Show()n and needs manual unlocking, fixed Slider offscreen window mode and improved triange thumb drawing, ScrollView would not crash when passing a NULL target just for kicks, the private MenuBar class now implements Draw to draw itself a little differently inside the BMenuField (dark right and bottom side) - though how it currently sets the clipping region prevents the text controls to draw in Playground, needs fixing

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13450 a95241bf-73f2-0310-859d-f6bbb57e9c96

BMenuField


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3542 a95241bf-73f2-0310-859d-f6bbb57e9c96

re-add the _BMCItem_ class for binary compatibility.

This was removed in hrev17147, because our implementation of BMenuItem
does not uses it anymore. However, we must keep it in order to properly
unarchive BMenuFields that were archived in BeOS.

One application that was crashing because of this is VNCViewer.

BMenuField: style fixes

BMenuField: Draw everything on resize

* The label might be truncated, in which case the entire width needs to be
redrawn when the menu field shrinks or grows.
* Invalidating the border in the parent looked a bit weird. Simplified.

BMCMenuBar: Refactor MakeFocus()

Get rid of unused fRunner variable.

It is very basic now, it just works.

Also, renamed msg to message in MessageReceived() and
declared MakeFocus() above it (alphabetically).

Menu and friends: Style fixes, no functional

... changes intended.

* 80 char limit fixes
* Indentation fixes
* Braces style fixes
* Use ternary operator where appropriate
* Rename menuItem to just item and declare it once outside
the loop
* Omit 3rd param of GetMouse() because it is default
* Rename variables eg state => focused and menu => submenu
* Indent comments below line they apply to
* Reword some comments
* Add some #pragmas

MenuField: enable/disable the menu field when...

the child menu bar or the child menu bar's menu is enabled/disabled.

This means that there is just one status we have to check, the menu
fields, and the child menus agree. This change takes practical form
in the Backgrounds preflet which disables the placement menu when
the image is set to "None", but, only the menu got disabled and not the
parent menu field so the label was erroneously still drawn as enabled.

Don't set MaxContentWidth on the menu bar of a BMenuField

Fixes #9816

It is no longer necessary, or even desirable for us to set the max
content width of the menu bar of a BMenuField now that BMenuItem
truncation and BMenuField sizing are working.

The user may, however, wish to set the max content width of the menu
bar of a BMenuField themselves like so:

menuField->MenuBar()->SetMaxContentWidth(width);

and the Interface Kit will automatically deduct the left and right
margins from the width including the space used by the drop down arrow.

BMenuField: If fixed size always set max content width

When you resize, also set max content width.

Create a SetMaxContentWidth() method that includes the margins.

Resize menu field if below minimum width in auto-size mode

... cancelling the normal item truncation behavior.
This funcationality comes from BeOS R5, we need to reproduce it for
backwards compat. KeymapSwitcher depends on it at least.

Minimum width is 20px, was set in last commit, comes from BeOS R5.

Move constants to BMCPrivate.h and refactor

We use these constants in both MenuField.cpp and BMCPrivate.cpp

Incorporate kMarginWidth into kPopUpIndicatorWidth.

A small code simplication in FrameResized() along with replacing bare numbers
with magic constants.

Refactor _BMCMenuBar_::Draw a bit

Move the comments around, expand on them and an 80 char fix.

Adjust menu field's menu bar height in auto mode

On IRC diver pointed out to me that KeymapSwitcher had a menu field that
was drawing as just a line since my recent change to BMenuField. I did a
little research and discovered that this was because the menu field in
KeymapSwitch was not using the layout APIs and it's frame rect was set to
0 height.

I did a little more research and experimented with menu fields in
BeOS R5. I discovered that in R5 if the menu field is set to auto-size
mode then the menu bar inside ignores the height of the menu field frame
and uses the BMenuBar's preferred height instead.

So, I adjusted the BMenuField code in Haiku accordingly. This should make
Haiku match the behavior of BeOS R5 in auto-size mode. For fixed-size mode
it should also work the same, although some more testing is needed to
see if there are any regressions there.

BMenuField: Fix menu bar resizing in auto-size mode.

Fixes #9753 (for real this time)

Don't resize the menu field when the menu bar resizes, the menu
field stays the same size because we'll need to use it's width to
check when the menu bar width has expanded beyond its width.
Then, if the selected menu item expands the menu bar to a width
greater than the width of the menu field resize it to the menu field
width.

Resize menu field menu bar iff fFixedSize is true

If the menu field is not fixed size than the width of the menu bar
should depend on the menu item contents so just do the default and
get the Bounds() without any extra resizing.

BMCPrivate: Cleanup

Remove no longer needed header includes, most that I recently added
a few that were already there but just aren't needed anymore. Don't
use BPrivate::MenuPrivate namespace.

Put the label truncation code back in BMenuItem.

Just a few commits ago I moved the label truncation code out of
BMenuItem and into BMCMenuBar because the truncation had to happen
outside of BMenuItem. Turns out, that wasn't true so I'm moving the
label truncation back into BMenuItem and removing the _DrawItems()
method from BMCMenuBar.

Note that the code is not a copy of what was there before, but, the
updated version I created for BMCMenuBar. The main difference is that
I use menuPrivate.Padding() instead of GetItemMargins() and I always
use the width of the parent menu frame instead of using fBounds even
if the state is not MENU_STATE_CLOSED. These are changes needed for
BMCMenuBar but should work just as well for a regular BMenu.

Draw truncated menu label in BMCPrivate, fixes #9735

...instead of in BMenuItem and remove the truncation code from BMenuItem.

The label truncation code cannot work in BMenuItem because the super
menu helpfully resizes itself to fit the menu item. So, instead we do the label
truncation in BMCPrivate making sure that BMenuItem there can't expand the
BMCMenuBar because we set the width to fMenuField->_MenuBarWidth()
explicity.

Note that this only truncates the label in BMCMenuField, i.e. the label inside
the menufield, it does nothing to the labels of the menu items in the attached
BMenu or BPopUpMenu which is exactly what we want.

Set some static variables for magic number constants

Rework layout-enabled contructor for BMCMenuBar

Was passing !fixedSize into the view flags of BMenuBar, which made no sense.
Stop doing that, set fixedSize to true instead.

Remove the fixedSize parameter from this contructor, it's too late for that.

Remove pre-ControlLook drawing code in menu classes

Put the BMenuBar initilization on it's own line

Update header comments

Style fixes to BMenu and related classes.

Use be_control_look != NULL everywhere in the Interface Kit.

Should not be a functional change. It is not in the Haiku Coding Guidelines but
I feel like 'if (object != NULL)' is generally preferred to 'if (object)', plus
in this case of be_control_look that is the more common style.

Draw menus using the user chosen colors.

* Cleanup, no functional change.
* Remove superfluous operator=() implementations.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32174 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Only take the popup marker into account if fShowPopUpMarker is true.
* Automatic whitespace cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32173 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fix small style violation.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32172 a95241bf-73f2-0310-859d-f6bbb57e9c96

BMenuField's private menu bar did not take into account the width of the popup indicator when computing its minimum size. Fixes ticket #3635.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32171 a95241bf-73f2-0310-859d-f6bbb57e9c96

The button and menu field draw routines take a background color into account,
which makes the resessed frame blend better with the surroundings. This can
be seen best in Keymap, where a different color is set on some buttons, but
the resessed frame should still be the same across all those buttons.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29716 a95241bf-73f2-0310-859d-f6bbb57e9c96

Fixed recently introduced regressions with layouted BMenuFields. When passing
fixedSize=true to the private BMenuBar class, it would set the follow mode
in AttachedToWindow() such that BMenu would calculate the minimum width
differently. Also fixes ticket #3606.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29691 a95241bf-73f2-0310-859d-f6bbb57e9c96

Various fixes to BMenuField behavior:
* In layout mode, using a BMenuField directly will make it behave like using
a fixed size BMenuField in non-layout mode. This is open for debate, but
not a change to the previous behavior. When using the Label and MenuBar-
LayoutItems though, the behavior is now changed to be more what one would
expect, ie the BMenuBar part is layouted across the full available width
just like it happens with BTextControls.
* Fixed invalidation of the BMenuBar when it auto-resizes according to picking
another item, and when it is resized due to layout changes.
* Fixed the problem with growing BMenuFields in file panels after changing
folders the first time. The fix is not so nice, but the purpose of setting
the menu item margins is to make sure it renders at the same vertical
offset as the BMenuField label. The better fix would be to change the
calculation of the content location or required margins in the BMenuItem
code... however the BMCPrivate code needs to account for the popup indicator
in the margins so I just kept the fix for the offset there as well.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29650 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented a new look for the Haiku interface controls. It was
overheard that they looked too ninety-ish.
TODO: The code behind this is work in progress. The basic idea
is to extract all drawing code into a new class BControlLook,
of which there is a global instance be_control_look, instantiated
in InterfaceDefs.cpp. At the moment, all the old drawing code is
still there, and the usage of be_control_look is inside if-bodies
checking the instance against NULL. In another words, by not
instanitating be_control_look, you can revert back to the old look.
BControlLook's job is to provide reusable methods for drawing
certain types of frames, backgrounds and labels, so that application
developers can make controls that re-use the same drawing code
as built-in controls and adopt to changes made there. I have added
the notion of "borders". Each of the frame drawing methods can be
made to draw certain borders only, which is supposed to help when
controls shall visually attach. This feature is not fully explored
at all ATM.
TODO: Update BColumnListView header view and BStringItem text
spacing. Update other apps where it makes sense to use BControlLook.
For the moment, only Tracker and LaunchBox are updated. More...
NOTE: The new look is not very radically different, so that existing
apps do not immediately look too ugly or out of place.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29221 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Added a comment about the purpose of the code in AttachedToWindow().
* Improved FrameResized(). The "diff" is actually between the new location
of the right side (Frame().right) and the location where it probably was
in the parent before it is resized (fMenuField->Bounds().right - 2).
Could be that this change is wrong, or at least, not yet correct. Will
test on a different machine.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27507 a95241bf-73f2-0310-859d-f6bbb57e9c96

small cleanups


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22964 a95241bf-73f2-0310-859d-f6bbb57e9c96

* make absolutely sure there is no cyclic resizing


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22229 a95241bf-73f2-0310-859d-f6bbb57e9c96

* fixed size layout of BMenuBar on BMenuField in fixed size mode
(needs to account for the parts that the BMenuField draws, ie the shadow
on the right)
* fixed follow mode of BMenuBar in fixed size mode (B_FOLLOW_LEFT_RIGHT)
* don't resize the BMenuField in fixed size mode (endless loop), this should
be more robust anyways, since this endless loop would be triggered if an
application tried to manually resize menuField->MenuBar() in auto resizing
mode
* fixed calculation of the parts that need to be redrawn on resize


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22127 a95241bf-73f2-0310-859d-f6bbb57e9c96

* setting a different menu color with the menu preflet gives now visually
agreeable results (I hope)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21967 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implement _BMCMenuBar_::MaxSize() to override BMenuBar::MaxSize() and limit
the maximum width. The latter supports unlimited maximum width. The
_BMCMenuBar_ draws fine when resized wider than its min/preferred width, but
not the complete "button" area will cause the menu to open when being pressed.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21465 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added a filter to MenuField, so that mousedown messages caught by the inner menubar are redirected to the BMenuField's MouseDown() like happens on beos. That way we can track and invalidate correctly. Implemented Show/HidePopUpMarker

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17613 a95241bf-73f2-0310-859d-f6bbb57e9c96

Invalidate less in BMenuBar::FrameResized() and a bit more in _BMCMenuBar_::FrameResized(), removed unused _BMCItem_

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17417 a95241bf-73f2-0310-859d-f6bbb57e9c96

Enlarged a bit the BMCMenuBar's frame, so that it's drawn more nicely

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16795 a95241bf-73f2-0310-859d-f6bbb57e9c96

* _BMCItem_ is no longer used, but I didn't remove it
yet, just commented it out in BMenuField. As was expected,
nothing changed in any obvious way
* made the _BMCMenuBar_ draw the popup marked. I changed it
a bit, inspired from some mockup I saw, sorry I don't
remember where. I hope you like it (it is easily changed
back if you don't).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16444 a95241bf-73f2-0310-859d-f6bbb57e9c96

Partially reverted to 15464 to have less code duplication, now that the special case is handled in BMenu::CalcFrame()

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15944 a95241bf-73f2-0310-859d-f6bbb57e9c96

Small changes, nothing important

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15942 a95241bf-73f2-0310-859d-f6bbb57e9c96

Yesterday's commit triggered some other visual bugs: hopefully fixed them all. A disabled menufield now doesn't open its associated menu anymore.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15906 a95241bf-73f2-0310-859d-f6bbb57e9c96

menufields should default to B_ITEMS_IN_COLUMN. This fixes the workspaces menu (in Screen) opened at the wrong position. As a consequence of this, I had to change the drawing code a bit

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15892 a95241bf-73f2-0310-859d-f6bbb57e9c96

forgot about the right side extra room for the focus indication

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15464 a95241bf-73f2-0310-859d-f6bbb57e9c96

take care of resizing and cleaning up parent BMenuField in FrameResized(), fixes missing areas in Fonts and most likely other BMenuFields

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15413 a95241bf-73f2-0310-859d-f6bbb57e9c96

fixed wrong usage of ConstrainClippingRegion() introduced by myself a couple months ago

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15374 a95241bf-73f2-0310-859d-f6bbb57e9c96

MenuField layouts the menu bar better with respect to fDivider, it aligns better with other controls. fDivider in TextControl is an integer number now, small fix and small cleanup in Menu, Window::InitData takes an optional BBitmap token to construct an offscreen window, fixed PrivateScreen IndexForColor, View prevents being located at fractional coordinates as in R5, BBitmap unlocks its offscreen window since it is never Show()n and needs manual unlocking, fixed Slider offscreen window mode and improved triange thumb drawing, ScrollView would not crash when passing a NULL target just for kicks, the private MenuBar class now implements Draw to draw itself a little differently inside the BMenuField (dark right and bottom side) - though how it currently sets the clipping region prevents the text controls to draw in Playground, needs fixing

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13450 a95241bf-73f2-0310-859d-f6bbb57e9c96

BMenuField


git-svn-id: file:///srv/svn/repos/haiku/trunk/current@3542 a95241bf-73f2-0310-859d-f6bbb57e9c96