* You can specify which borders will be drawn using the
BControlLook::B_TOP_BORDER, ... constants.
* Adapted Mail to no longer need the SetInsets() hack.
* Moved entirely into MainWindow.
* Moved duplicated code into separate methods.
* Resize the main window on larger screens by default, as we can make
use of the extra space.
* Use BWindow::MoveOnScreen() instead of make_sure_frame_is_on_screen()
as the former has more info. And is even smarter now as it can
optionally resize windows to fit on screen.
* Center window on screen by default (ie. when there are no settings).
* While this breaks binary compatibility with earlier Haiku releases,
use values that are less likely to clash with actual use cases.
* Specifically, using a negative spacing is one way to get rid of the
border of BScrollViews, to put them into a window neatly.
* Also, BControlLook now uses a switch to resolve them.
* B_AUTO_UPDATE_SIZE_LIMITS only really makes sense for resizable
windows, and it only sets the minimum/maximum window size.
* ResizeToPreferred() resizes the window to its preferred size, and
also supports height-for-width layouts.
* Add new methods
BView::BeginLayer(uint8 opacity)
BView::EndLayer()
* All drawing between begin and end of a layer is redirected onto an
intermediate bitmap. When ending the layer, this bitmap is
composited onto the view with the opacity given when the layer was
started.
* Layers can be nested arbitrarily and will be blended onto each
other in order. There can also be any arbitrary interleaving of
layer begin/end and drawing operations.
* Internally, drawing commands are redirected into a BPicture between
BeginLayer and EndLayer (but client code need not know or care
about this). Client code can also start/end other BPictures while
inside a layer.
* Uses the PictureBoundingBoxPlayer to determine the size of the
layer bitmap before allocating and drawing into it, so it does not
allocate more memory than necessary and -- more importantly -- it
will not alpha-composite more pixels than necessary.
* Drawing mode is always set to B_OP_ALPHA, blend mode to
(B_PIXEL_ALPHA, B_ALPHA_COMPOSITE) while inside layers. This is
necessary for (a) correct compositing output and (b) for
redirection of drawing into the intermediate bitmap, which uses the
renderer_region offset (in B_OP_COPY, the Painter does not use the
AGG renderer methods, it directly accesses the pixel data. This
would access out-of-bounds without the offset, so B_OP_COPY cannot
be allowed.)
To ensure these modes aren't changed, BView::SetDrawingMode()
and BView::SetBlendingMode() are ignored while inside a layer.
* The main motivation behind this new API is WebKit, which internally
expects such a layers functionality to be present. A performant and
reusable implementation of this functionality can only be done
server-side in app_server.
* Address TODO about setting fSelected when nothing is done.
* Pass a pointer to the tab view to the BTab so that it can call Invalidate().
(Checked against BeOS).
* Call Invalidate() from the BTab after SetView() & SetName().
Fixes#12108 & #12196.
It works analoguous to BView::RemoveSelf(), i.e. it removes itself from
the parent (layout in this case) and returns whether or not it had and
was successfully removed from said parent.
and remove TExpandoMenuBar as a friend class to BMenu hack.
In Deskbar, call the newly added MenuPrivate::SetLayout() method instead.
This is a much cleaner way to implement this, thanks Stefano Ceccherini
for the tip!
Add private BMenu::_SetMenuLayout() method. Set TExpandoMenuBar
as a friend class in BMenu to call this method. A little hacky,
but, this keeps SetMenuLayout() from being exposed as part of
the public API.
Don't destroy and rebuild the ExpandoMenuBar when switching from
horizontal to vertical mode. Instead build the TExpandoMenuBar
when the application starts and then switch it from B_ITEMS_IN_ROW
to B_ITEMS_IN_COLUMNS by using the newly added _SetMenuLayout()
method.
When we resize from vertical to horizontal, recalc the max
menu item widths, this resizes the application menu items so
that they take up the right amount of space.
Since we no longer destroy the menu bar we no longer have to
save whether menu items are expanded or not in a separate list.
Instead we can store that information in directly in
TExpandoMenuBar. This removes a lot of code.
Fixes#9350
* When RemoveSelf() is called, we do not own our own layout items, so
we must not delete them.
* However, we do own them when we still have layout items left when
we get deleted ourselves.
* This fixes removing/adding a child view to a view without deleting
it inbetween (like the new Network preferences will do).
* Optimized item removal -- not a good idea to always remove item 0.
* Added new truncation mode B_NO_TRUNCATION.
* The Truncation()/SetTruncation() methods itself are Dano-compatible,
however, there was no B_NO_TRUNCATION.
* There is no need to delay this to AllAttached
* Apps may want to override the SetDivider, and doing it as late as
AllAttached can be annoying.
Fixes#10734.
* We archive views using "managed" archives, and the children are not
attached in the BView(BMessage*) constructor, but later. So it's not
possible to find the target and scrollbars in the constructor of
BScrollView.
* Make BScrollView override AllUnarchived and find the target and
scrollbars again there. The code is slightly different as there is no
guarantee that the first child will be the target in that case. The
existing code in the constructor is preserved for non-managed archives.
* MarkAsInvalid is used to enable or disable the mark
* The B_INVALID BControlLook flag is used
* invalid BTextControls are drawn with a red border.
* You ar encouraged to let the user know more precisely what's wrong, by
showing an helpful error message next to the control or in a tooltip.
Double checked BeOS R5 & Haiku R1/A4 and BTextView should be 356
bytes, somewhere since then we've added 4 bytes. So, this commit
reduces the class size from 360 back to 356 by removing 1 reserved
int32 (instead of 2).
I believe the class size changed in hrev46798 as a result of adding
2 bools (1 byte each padded out to 4 bytes).
Sorry for the noise.
In hrev46796 I added two new private methods: _PreviousLineStart(),
and _NextLineEnd() which increased the size of the class breaking
binary compatability because I forgot to decrement the reserved array.
This commit decrements the reserved array restoring the class size
to the original size fixing the binary compat issue.
Thanks Axel for noticing.
The order is updated so the virtual methods appear in the same order
that they did in BeOS R5 with methods new to Haiku added to the bottom.
Perform() moves up, all other methods move below GetDragParameters(),
the last virtual method in BeOS R5's TextView.h.
Accidentally renamed these in the header, rename them back to
match the cpp file. These param names might not be very good but
they match the struct variable names. They are private methods
anyway. No functional change intended in either commit.
No functional changes intended.
* Updated copyright information.
* Reduced doxygen documentation down to a helpful summary
in a regular comment, the documentation has been moved into
the Haiku Book.
* Some parameter renaming for consistency and clarity.
* A few other style fixes.
* Nothing ever reads fTargetName in the scrollbar code, so remove the
field.
* Frees one reserved slot, and a little memory, as the target name was
copied with strdup.
Create and use BLayoutUtils::AlignOnRect() to position the button label
in BControlLook::DrawLabel().
AlignOnRect(), unlike AlignInFrame(), provides the possibility to return
a rectangle with dimensions greater than the available size.
Add some comments above the methods in LayoutUtils that indicate such.
Also update copyright headers in LayoutUtils and ControlLook
* BView gets SetFillRule/FillRule methods. The fill rule is part of the
view state.
* The B_NONZERO rule is the default. This is what we implemented before.
* The B_EVEN_ODD rule is the other common possibility for this, and
we need to support it to help WebKit to render properly.
inline const floats are a gcc extension. It is possible to do it in a
standard way in C++11 using constexpr, but then gcc will reject the
previously accepted nonstandard syntax.
Everything untested, but compiles, so it must work. The idea is to introduce
BAffineTransform additionally to the existing Origin and Scale properties of
BViews. One may use it in parallel or as an alternative. Painter in app_server
is not yet aware of the additional transformation. It is however already used
to transform drawing coordinates. It probably needs to work differently,
perhaps only in Painter and AGGTextRenderer.
Make Cmd+Left and Cmd+Right work the same as Option+Left and
Option+Right, that is, they do word-wise navigation.
Make Option+Up go to beginning of paragraph and Option+Down go to end
of paragraph like Cmd+Left and Cmd+Right used to.
Unfortunately option shortcuts are currently eaten by S&T until #9431
gets fixed.
* Command+Left goes to beginning of line, ignoring softwrap
* Command+Right goes to the end of line, ignoring softwrap
* Home goes to beginning of line, accounting for softwrap
* End goes to end of line, accounting for softwrap
* Option+Left goes to previous word
* Option+Right goes to next word
* Command+Home and Command+Up go to beginning of document
* Command+End and Command+Down go to end of document
Shift with any of the above also selects the text.
This is similar to how the text editor Eddie works.
* Add behavior constant B_POP_UP_BEHAVIOR which adds a pop-up marker
to the button (similar to that of BMenuField).
* Add methods [Set]PopUpMessage(). To set/get the the message that is
sent to the button's target when the pop-up marker is clicked.
* Add methods SetFlat()/IsFlat(). A flat button doesn't draw its frame,
unless the mouse is hovering over it or it is otherwise activated.
* As a side effect this change also activates the hover glow that was
already implemented in BControlLook, but not activated in BButton.
* Draw(): Remove the non-BControlLook code.
* GetPreferredSize(): Implement based on _ValidatePreferredSize() to
avoid code duplication.
* Draw(): Fix off-by-one error. The label was too close to the box.
* Draw(), _ValidatePreferredSize(): Add icon support.
_ValidatePreferredSize() is now actually aligned with what Draw()
expects. The preferred width is now a tight fit; there were three or
four pixels of empty space before.
Due to the fixed check box position the layout isn't that nice in
some situations (particularly with an icon larger than the text),
IMHO.
The icon is meant as an addition to or replacement of the label. Icon
bitmaps for various states of the control (off, on, partially on, each
enabled or disabled, plus up to 125 custom states) can be set
individually via SetIconBitmap() (getter IconBitmap()).
The convenience method SetIcon() can be used to set the bitmaps for the
standard states from a single bitmap; it also supports cropping the
icon to its non-transparent area. Code borrowed from BIconButton.
* Update the previously unused frame_type and background_type enums.
* Add methods GetFrameInsets(), GetBackgroundInsets(), GetInsets() to
get the insets for a given frame type, background type, or both
respectively.
* Add possible control state B_CONTROL_PARTIALLY_ON and support it in
BCheckBox and BControlLook.
* BCheckBox: Add partialStateToOff property defining whether the
partial state should transition to off. Defaults to false (i.e.
partial to on).
No functional change intended.
Renamed title => name in regular constructors,
No right or wrong here but consistant now.
Renamed data => archive in Achive constructor,
Ditto.
* BWindow used to generate the B_MOUSE_IDLE events by sending a
delayed message with a one-shot BMessageRunner to itself.
Every creation and deletion of BMessageRunners causes synchronous
messaging between the application under the mouse cursor and the
registrar. This creates large amounts of calls to set_port_owner()
in the kernel whenever moving the mouse.
* Now, B_MOUSE_IDLE is sent by the cursor loop inside the app_server
instead. When the mouse wasn't moved for the tooltip delay time,
it inserts a B_MOUSE_IDLE message into the event stream.
* The tooltip delay thus becomes a system-wide constant and is not
configurable per-application anymore (no code currently in the
Haiku repo makes use of that anyhow).
...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
... 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
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
Implements enhancement described in #9819
This feature works pretty much as it did on BeOS R5.
When you focus on the color control, the border is drawn blue and
the dot on the red ramp draws as an outline to show that it is
selected. You can push the up and down arrow keys to navigate to the
previous and next ramps respectively and can push right and left to
increment and decrement the color value of the selected ramp.
Clicking on the control no longer gives it focus.
In BeOS the left and right arrows would increment and decriment by 5,
on Haiku they increment and decrement by 1, but, by holding down the
key for a second or so the increment value increases to 5 allowing for
both course and fine adjustments.
On a technical note I split the int32 fFocusedComponent member variable
into 2 int16 member variables, fFocusedRamp and fClickedRamp. I did this
because I needed an entra variable, and can't change the size of the
class without using up another reserved member variable slot. int16
should be more than enough for these variables as they store an index to
the currently focused or clicked on ramp (0-3). Please someone chime in
if this is not okay for FBC in some condition I didn't think about.
...from orientation params. Elaborated type specifiers are not needed
for C++ code and removing them makes doxygen happy. Verified working
on both gcc2h and gcc4h builds.
...on controls where it makes sense:
- BRadioButton and BCheckBox now return their preferred size as their
maximum.
- BRadioButton, BCheckBox and BTextControl now use left alignment by
default, as this is the most common use case for them.
Motivated by inconsistancies found while documenting BView.
Update copyright year, alphabetize
Variable names normalized:
* pt => point
* r => rect
* p => pattern
* c => color
* msg => message
* a, b and pt0, pt1 => start, end
* r, g, b, a => red, green, blue, alpha
A couple of white spaces fixes.
A couple of !pointer => pointer == NULL fixes.
GetPreferredSize params => _width and _height to indicate out params.
