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>

BMenuField: remove deprecated constructors

These were introduced by mistake during the addition of the layout
system. They have been private since 2011. It seems safe to assume that
nothing uses them anymore and they can now be removed safely.

Change-Id: I98d030096f9cb06fccc25233fe4da17d0213050e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6075
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

BMenuField: use anonymous namespace for internal class.

As suggested by korli, this is indeed a better way to hide internal
classes and make them completely unreachable from outside the cpp file
they are defined in.

BMenuField: Fix private ABI leakage

Problem introduced in hrev46195. The MouseDownFilter class may be
declared deep in the middle of a cpp file, yet without precautions, it
will end up being part of the ABI.

WonderBrush has a class with the same name, and on 64bit Haiku, a mixup
of the two would happen, leading to a crash because they don't have the
same size.

Move the class into BPrivate to avoid this.

Change-Id: I60b608edf3188816281332c972c654e3c57740b4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3536
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Rene Gollent <rene@gollent.com>

Remove MouseDownThread and its usages

This code comes from an old Be Newsletter and since then the API
received the addition of SetMouseEventMask. In several places the
MouseDownThread was misused: it would spawn a new thread on every mouse
click and not clear the previous one. This could for example lead to
BSpinner skipping values if you clicked it at the right speed.

There are functional changes in BSpinner, before it updated for the
first time 100ms after mouse down, and then as you moved the mouse
around the button, now it activates immediately on first click and then
every 200ms (which may be a bit short). In other places, no functional
changes intended.

Change-Id: Ie600dc68cbb87d1e237633953e5189918bf36575
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2599
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

BColorMenuItem: add custom color menufield

http://insightfactory.tumblr.com/image/142366356207

* Make the color box a rectangle with proportions of golden ratio.
* Override GetContentSize() to make menu item area larger.
* Label should never truncate since I make sure there is enough room.
* Draw the label using BMenuItem parent class
* Carefully adjust the spacing so that there is an attractive amount of
padding between the checkmark and color box and the color box and label.

Add _AddMenu method to BMenuField that adds BColorMenuItem as its
base menu item. This shows the BColorMenuItem in the closed state.

Create BPrivate::MenuItemPrivate

Add a SetSubmenu() method to MenuItemPrivate that gives you
the ability to add a submenu after creating the object. This
method should be public

Skip disabled items

Color gets updated even if you select an item in a submenu

BMenuField: Change label to panel text color

...instead of menu item text color when the label is unselected.

Menu item text color seems to make sense when the control is unselected
because we use selected menu item text color when the control is
selected, but, this isn't the case. We color the label background using
the menu item color because we are reproducing similar behavior of
BeOS R5. However, when the menu field is unselected the label needs to
draw so that it goes on the panel bg color.

MenuField Low Color (for frame)

BMenuField's frame is drawn from the LowColor() which is adopted from its
parent. However, we should be adopting the parent's view color for our low
color, otherwise we sometimes end up with a miscolored border (most often white).

This was not noticed earlier as most views have matching view and low colors.

Fixes ticket #12603

Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>

kits/interface: Convert to using Set*UIColor.

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

Restore the BMenuField label background

Highlighting was added in hrev45983, stopped working in hrev49614, specifically
d8919236503108a2db13c454109d7c7696677514.

Add comment to explain what is happening and hopefully deter this from being
removed again in the future.

Fixes #12359

BMenuField: use layout rect for the label.

* Instead of just laying it out as without the layout API.

Style fixes to IK, focus on docs

BMenuField/BTextControl: Store and reuse Label()

BMenuField: Check if menuBar is NULL explicitly

BMenuField: Replace 5 with DefaultLabelSpacing()

BMenuField: style fixes

MenuField: Filter out additional MouseDown messages.

...while mouse is down on a menufield

This makes it so that you can't open 2 menufields simultaneously
by clicking and holding the right mouse button on one menufield while
clicking a second with the the left mouse button opening it.

This matches the behavior on BeOS R5.

Should help with #6408 comment:9

Revert "MenuField: Make sure input is a single byte"

This reverts commit 4e075e0f4c60a600a86792d9c36eae513f1cda31.

MenuField: Remove unused variables

fSelected and fTransition

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: Make sure input is a single byte

MenuField: Open the menu bar when the label is clicked

Fixes #6894

Private DrawLabel() method renamed to _DrawLabel() and rest of drawing
code moved to new private method _DrawMenuField(). These methods both
check to make sure that they are drawing in a valid rect that intersects
updateRect.

When label or menu is selected Draw a the label background in the selected
menu color matching the behavior of BeOS R5.

_DrawLabel() calls be_control_look->DrawLabel()

Update copyright year in MenuField.h

Revert "don't open the menu if it's disabled."

This reverts commit ce8253d97b588366540230d11fb534c4846d0a09.

MenuField: need stdio.h if TRACE enabled

* Also update authors adding myself

BMenuField: Check if Frame() is valid, refactor

BMenuField: Style fixes

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.

Move kMinMenuBarWidth to MenuField.cpp

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.

Don't resize to preferred height if fixed size, BeOS didn't

Use roundf() as suggested by Axel

Remove the unused bounds parameter from DrawLabel

Also refactor BMenuField::Draw()

Don't cast to float, use floorf

Use better variable names in SetDivider

Style fixes to BMenuField

Rename resize to resizingMode, whitespace fixes, compare to 0 explicitly

Refactor BMenuField::DrawLabel()

also use std::max() instead of max_c()

Style fixes to BMenu and related classes.

Cleanups.
Removed code path for be_control_look == NULL.
Improve comments.

BMenuField: fixed broken view color.

* Apparently, I only tested the other case :-)
* This fixes bug #9433.

BMenuField: use panel background color as default.

* There is no reason the BMenuField should behave differently from
any BControl here.

interface kit: added compatibility symbols for GCC4

* InvalidateLayout method for BBox, BButton, BCheckBox, BMenuField,
BScrollView, BSlider, BStringView, BTextControl.

Use the correct perform invocation for these functions.

Add compatibility symbols for removed LayoutChanged() calls.

Replace remaining InvalidateLayout()'s with LayoutInvalidated(). Also do a bit of cleanup/move methods around.

De-virtualize BView::InvalidateLayout() and introduce LayoutInvalidated() hook, like BLayout.

* Made the messed up BMessage* constructors private - since it only affects the
layout API, we probably can just phase it out after a while.
* Introduced new constructors, and added missing flags to one of them to make
it more convenient to use.


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

Updated BMenuField and its custom BLayoutItems for layout-safe archiving. Added an _InitMenu(const BMessage*) method that inits the menu during unarchival.


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

bonefish+stippi:
All views which cache layout information need to call ResetLayoutInvalidation()
when they have updated the cached information. Otherwise calling
InvalidateLayout() once they are already attached to a layout may not have any
effect.


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

* Added missing default initializer for the message.
* Changed BMenuField::MenuBarLayoutItem::BasePreferredSize() to return the
min size as well, instead of a fixed 100 pixels for the width...
* More minor cleanup.


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

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


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

Both BTextControl and BMenuField layout the inner control at divider
+ frame width. BTextControl was even calculating it like this everywhere,
but then layouted like BMenuField. Now it's consistent and much easier to
align other controls with the text view or menu bar layout item.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30190 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

* Fixed the unified menu bar width calculations. SetDivider() got it wrong.
* _InitMenuBar() had the meaning of fixedSize reversed. The layout-mode
constructors pass fixedSize = true accordingly.


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

Fixed more inconsistencies in layouting the menu bar. These would mostly
result in the BMenuField not always drawing all of the frame around the
menu bar correctly, for example cutting off at left for divider = 0.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29660 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

don't open the menu if it's disabled.

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

* Stronger BMenuField popup indicator.
* Softer recessed frame for BMenuField to distinguish more from BButton
and make it slightly more similar to BTextControl.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29235 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

bonefish + zooey:
* Fixed a general problem with respect to overriding of the reserved
virtual function slots: instead of statically invoking the method
that corresponds to the reserved slot on the class that contains the
slot, we now invoke the virtual Perform() method. Perform() then dispatches
the method invocation to the "proper" class, i.e. the highest class in the
hierarchy that actually implements the requested method.
This fixes a crash in apps that use liblayout's MSlider class and
should fix one or other spurious bug with old apps or libraries, too.
* added new header folder 'binary_compatibility' that contains files that
define the method codes and data structures required by Perform()
* looked for and implemented all used reserved virtual slot functions to
invoke Perform() where necessary or to pass on the method call statically
(for slots that were already maintained by Be)


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

* Don't set an explicit max size, instead calculate a proper max size in
MaxSize(). This makes sure that MaxSize() returns a proper size when the
user "unsets" the explicite max size.
* minimum label height is 0 if there is no label.


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

Use the dedicated BView constructor for using layout management.


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

Several fixes to BMenuField layout calculations.
* The most important fix is that in BMenuField::_ValidateLayoutData(),
divider was calculated, but then never used. If the menu field was not
using the layout management, it should take the existing fDivider into
account, but never did. This caused #2728.
* Added some tracing that helped me debug this.
* Fixed a bunch of layouting inconsistencies. It will also improve some
unnecessary resizing of the menu bar.

Will test all of this some more. But in the test app I do have, the BMenuField
works more like in BeOS now.


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

mmlr + stippi:
Fixed more controls to handle a B_TRANSPARENT_COLOR as view coloe of the
parent view. Some controls would not initialize their LowColor() at all
if they were the only control in a window.


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

if no menubar is found in the archive, recreate one to avoid crashing


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

Draw the label right at origin in B_ALIGN_LEFT mode. Should improve alignment
with other controls. (BTextControl patch with the same change is upcomming, but
it includes many other changes I didn't want to mix in.)


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

pass -1 as first parameter of StartMenuBar(), otherwise it will hide the
cursor (used for keyboard navigation). Fixes bug #1807


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

cleanups


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

* make sure that the menu bar is still aligned with the right
side if in fixed size mode in ResizeToPreferred, this fixes
the menu bars going out of view bounds in a lot of apps using
fixed size fields, like Screen



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22230 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

* ceilf() both font ascent and descent individually before adding them up to
compute the vertical space requirement of the label.
* Use a better algorithm for vertically aligning the label. The menu bar (or
item) seems to use another algorithm. So, ATM the label is not necessarily
aligned with the menu bar text.


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

I *think* I've fixed the problem of menu fields not being opened when
the user clicks on the part which has been resized...


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

* Implemented Min/Max/PreferredSize().
* Reworked the internal layout. _ValidateLayoutData() computes and caches the
layout related data and all other methods just use those values. Now, in
layout-aware mode the class should properly work not only when using the
layout items. And when using layout items, the class does actually do
internal layout; it was basically good luck that it worked in the tests,
before. Vertical resizing is supported, too.
* We do a few mean tricks to get the probably mostly preferred layout behavior:
By default our own explicit max width and that of the menu bar layout item is
set to unlimited and the horizontal menu bar alignment to left aligned. This
allows to horizontally resize a BMenuField beyond its preferred size,
although both label and menu bar have a limited max width. The user can, of
course, override those explicit sizes/alignments to get a different behavior,
if desired.
* Fixed invalidation in SetDivider(). When having the focus, the left and top
border of the blue frame were not invalidated.
* The label is no longer drawn at vertical position font ascent + descent
+ leading + 2 (not sure how this calculation was supposed to work), but
vertically centers the label around the ascent. With big fonts the label is
shown a bit too far to the bottom. Not sure how to fix this in a generic way.


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

some more work on menus... fixed bug #953 and some more stuff


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

don't hide the cursor when the menu pops up

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

Merge from layout management branch.


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

partially reverted to an old version, should fix strange problems with menufields

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18067 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

fixed some Archive() following stippi's path


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

small cleanup

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17014 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

* have the MenuBar resize to preferred in
ResizeToPreferred()
* fix and sanitize GetPreferredSize()... people,
think "simple"


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16426 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

All controls/views now accept NULL arguments for "width" and "height" in GetPreferredSize().


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

Cleanup.


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

More or less correctly implemented GetPreferredSize().
The menu bar is now resized to a proper size.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14790 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

Fixed warnings.


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

Fix null statement and remove an unused variable


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

BMenuField


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

BMenuField: use layout rect for the label.

* Instead of just laying it out as without the layout API.

Style fixes to IK, focus on docs

BMenuField/BTextControl: Store and reuse Label()

BMenuField: Check if menuBar is NULL explicitly

BMenuField: Replace 5 with DefaultLabelSpacing()

BMenuField: style fixes

MenuField: Filter out additional MouseDown messages.

...while mouse is down on a menufield

This makes it so that you can't open 2 menufields simultaneously
by clicking and holding the right mouse button on one menufield while
clicking a second with the the left mouse button opening it.

This matches the behavior on BeOS R5.

Should help with #6408 comment:9

Revert "MenuField: Make sure input is a single byte"

This reverts commit 4e075e0f4c60a600a86792d9c36eae513f1cda31.

MenuField: Remove unused variables

fSelected and fTransition

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: Make sure input is a single byte

MenuField: Open the menu bar when the label is clicked

Fixes #6894

Private DrawLabel() method renamed to _DrawLabel() and rest of drawing
code moved to new private method _DrawMenuField(). These methods both
check to make sure that they are drawing in a valid rect that intersects
updateRect.

When label or menu is selected Draw a the label background in the selected
menu color matching the behavior of BeOS R5.

_DrawLabel() calls be_control_look->DrawLabel()

Update copyright year in MenuField.h

Revert "don't open the menu if it's disabled."

This reverts commit ce8253d97b588366540230d11fb534c4846d0a09.

MenuField: need stdio.h if TRACE enabled

* Also update authors adding myself

BMenuField: Check if Frame() is valid, refactor

BMenuField: Style fixes

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.

Move kMinMenuBarWidth to MenuField.cpp

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.

Don't resize to preferred height if fixed size, BeOS didn't

Use roundf() as suggested by Axel

Remove the unused bounds parameter from DrawLabel

Also refactor BMenuField::Draw()

Don't cast to float, use floorf

Use better variable names in SetDivider

Style fixes to BMenuField

Rename resize to resizingMode, whitespace fixes, compare to 0 explicitly

Refactor BMenuField::DrawLabel()

also use std::max() instead of max_c()

Style fixes to BMenu and related classes.

Cleanups.
Removed code path for be_control_look == NULL.
Improve comments.

BMenuField: fixed broken view color.

* Apparently, I only tested the other case :-)
* This fixes bug #9433.

BMenuField: use panel background color as default.

* There is no reason the BMenuField should behave differently from
any BControl here.

interface kit: added compatibility symbols for GCC4

* InvalidateLayout method for BBox, BButton, BCheckBox, BMenuField,
BScrollView, BSlider, BStringView, BTextControl.

Use the correct perform invocation for these functions.

Add compatibility symbols for removed LayoutChanged() calls.

Replace remaining InvalidateLayout()'s with LayoutInvalidated(). Also do a bit of cleanup/move methods around.

De-virtualize BView::InvalidateLayout() and introduce LayoutInvalidated() hook, like BLayout.

* Made the messed up BMessage* constructors private - since it only affects the
layout API, we probably can just phase it out after a while.
* Introduced new constructors, and added missing flags to one of them to make
it more convenient to use.


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

Updated BMenuField and its custom BLayoutItems for layout-safe archiving. Added an _InitMenu(const BMessage*) method that inits the menu during unarchival.


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

bonefish+stippi:
All views which cache layout information need to call ResetLayoutInvalidation()
when they have updated the cached information. Otherwise calling
InvalidateLayout() once they are already attached to a layout may not have any
effect.


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

* Added missing default initializer for the message.
* Changed BMenuField::MenuBarLayoutItem::BasePreferredSize() to return the
min size as well, instead of a fixed 100 pixels for the width...
* More minor cleanup.


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

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


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

Both BTextControl and BMenuField layout the inner control at divider
+ frame width. BTextControl was even calculating it like this everywhere,
but then layouted like BMenuField. Now it's consistent and much easier to
align other controls with the text view or menu bar layout item.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30190 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

* Fixed the unified menu bar width calculations. SetDivider() got it wrong.
* _InitMenuBar() had the meaning of fixedSize reversed. The layout-mode
constructors pass fixedSize = true accordingly.


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

Fixed more inconsistencies in layouting the menu bar. These would mostly
result in the BMenuField not always drawing all of the frame around the
menu bar correctly, for example cutting off at left for divider = 0.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29660 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

don't open the menu if it's disabled.

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

* Stronger BMenuField popup indicator.
* Softer recessed frame for BMenuField to distinguish more from BButton
and make it slightly more similar to BTextControl.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29235 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

bonefish + zooey:
* Fixed a general problem with respect to overriding of the reserved
virtual function slots: instead of statically invoking the method
that corresponds to the reserved slot on the class that contains the
slot, we now invoke the virtual Perform() method. Perform() then dispatches
the method invocation to the "proper" class, i.e. the highest class in the
hierarchy that actually implements the requested method.
This fixes a crash in apps that use liblayout's MSlider class and
should fix one or other spurious bug with old apps or libraries, too.
* added new header folder 'binary_compatibility' that contains files that
define the method codes and data structures required by Perform()
* looked for and implemented all used reserved virtual slot functions to
invoke Perform() where necessary or to pass on the method call statically
(for slots that were already maintained by Be)


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

* Don't set an explicit max size, instead calculate a proper max size in
MaxSize(). This makes sure that MaxSize() returns a proper size when the
user "unsets" the explicite max size.
* minimum label height is 0 if there is no label.


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

Use the dedicated BView constructor for using layout management.


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

Several fixes to BMenuField layout calculations.
* The most important fix is that in BMenuField::_ValidateLayoutData(),
divider was calculated, but then never used. If the menu field was not
using the layout management, it should take the existing fDivider into
account, but never did. This caused #2728.
* Added some tracing that helped me debug this.
* Fixed a bunch of layouting inconsistencies. It will also improve some
unnecessary resizing of the menu bar.

Will test all of this some more. But in the test app I do have, the BMenuField
works more like in BeOS now.


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

mmlr + stippi:
Fixed more controls to handle a B_TRANSPARENT_COLOR as view coloe of the
parent view. Some controls would not initialize their LowColor() at all
if they were the only control in a window.


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

if no menubar is found in the archive, recreate one to avoid crashing


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

Draw the label right at origin in B_ALIGN_LEFT mode. Should improve alignment
with other controls. (BTextControl patch with the same change is upcomming, but
it includes many other changes I didn't want to mix in.)


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

pass -1 as first parameter of StartMenuBar(), otherwise it will hide the
cursor (used for keyboard navigation). Fixes bug #1807


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

cleanups


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

* make sure that the menu bar is still aligned with the right
side if in fixed size mode in ResizeToPreferred, this fixes
the menu bars going out of view bounds in a lot of apps using
fixed size fields, like Screen



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22230 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

* ceilf() both font ascent and descent individually before adding them up to
compute the vertical space requirement of the label.
* Use a better algorithm for vertically aligning the label. The menu bar (or
item) seems to use another algorithm. So, ATM the label is not necessarily
aligned with the menu bar text.


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

I *think* I've fixed the problem of menu fields not being opened when
the user clicks on the part which has been resized...


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

* Implemented Min/Max/PreferredSize().
* Reworked the internal layout. _ValidateLayoutData() computes and caches the
layout related data and all other methods just use those values. Now, in
layout-aware mode the class should properly work not only when using the
layout items. And when using layout items, the class does actually do
internal layout; it was basically good luck that it worked in the tests,
before. Vertical resizing is supported, too.
* We do a few mean tricks to get the probably mostly preferred layout behavior:
By default our own explicit max width and that of the menu bar layout item is
set to unlimited and the horizontal menu bar alignment to left aligned. This
allows to horizontally resize a BMenuField beyond its preferred size,
although both label and menu bar have a limited max width. The user can, of
course, override those explicit sizes/alignments to get a different behavior,
if desired.
* Fixed invalidation in SetDivider(). When having the focus, the left and top
border of the blue frame were not invalidated.
* The label is no longer drawn at vertical position font ascent + descent
+ leading + 2 (not sure how this calculation was supposed to work), but
vertically centers the label around the ascent. With big fonts the label is
shown a bit too far to the bottom. Not sure how to fix this in a generic way.


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

some more work on menus... fixed bug #953 and some more stuff


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

don't hide the cursor when the menu pops up

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

Merge from layout management branch.


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

partially reverted to an old version, should fix strange problems with menufields

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18067 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

fixed some Archive() following stippi's path


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

small cleanup

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17014 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

* have the MenuBar resize to preferred in
ResizeToPreferred()
* fix and sanitize GetPreferredSize()... people,
think "simple"


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16426 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

All controls/views now accept NULL arguments for "width" and "height" in GetPreferredSize().


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

Cleanup.


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

More or less correctly implemented GetPreferredSize().
The menu bar is now resized to a proper size.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14790 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

Fixed warnings.


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

Fix null statement and remove an unused variable


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

BMenuField


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