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

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