* fix unitialized variables in __printf_fphex() in case of architectures
without support for long double - this triggered unreliable results
or crashes when using %La or %La on x86
* activate long double implementation in use for x86_64 for x86, too,
as they share the long double format
Almost complete. bepdf is still missing, since it doesn't build with gcc
4 and a few source packages are missing as well (binutils and gcc
because haikuporter doesn't build them correctly ATM, mesa due to an
oversight).
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
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.
A small revision on my last published commit, set and restore the
low color in addition to the high color when drawing the menu item
because DrawString() will produce nicer looking results if the low
color of the view matches the color it draws on due to anti-aliasing.
See #6610 comment:15 for details.
Firstly, don't save and restore the super menu's low color
since it never changes, instead, save and restore the super
menu's high color which does get altered here.
Secondly, set the high color to
B_MENU_SELECTED_ITEM_TEXT_COLOR only if the menu item
is activated and enabled, otherwise set the high color by tinting the
background color which might be
B_MENU_SELECTED_BACKGROUND_COLOR or
B_MENU_BACKGROUND_COLOR depending on whether
the item is selected or not.
Thirdly, complete the TODO by using a lighten tint if the menu
has a dark background and vice-versa.
This third item is actually a good candidate for a BControlLook
function because the disabled tint should depend on whether the
background color of the thing you're disabling is light or dark.
... to layout the menu field label and menu in the grid. This makes
the label and grid layout correctly, the AddMenuField() method should
be deprecated or fixed as it lays out the menu field differently.
Also replace numeric spacing units with font relative spacing units.
With #6610 fixed, it is now possible to open disabled menus in a
menubar, so the workaround introduced in hrev33840 is no longer
needed.
Signed-off-by: John Scipione <jscipione@gmail.com>
* fallback to mechanism 1 for out of range bus numbers
* Support for the fallback is mandatory according to the PCIe specification.
* Should help with #9929 and #9930
Use CreateLabelLayoutItem() instead of faking the label with a BStringView.
This is important because it means the label is part of the menu field control
rather than being it's own separate view.
Also convert from using deprecated BGroupLayoutBuilder and
BGridLayoutBuilder classes and use the BLayoutBuilder template instead.
Use font-relative spacing values instead of constants.
Make key label take up 2 columns
Make protected methods private, don't want to subclass
ModifierKeysWindow
* Added ParagraphStyleData. Contains actual style data. Incomplete.
Supposed to be immutable,.
* Added ParagraphStyle, references a ParagraphStyleData.
Multiple ParagraphStyle object can refer to the same ParagrapgStyleData,
when a style aspect is changed for ParagraphStyle, it makes its own
copy of the previous ParagraphStyleData with the changed property.
* Added Paragraph class, currently knows only its ParagraphStyle.
... just because the source path ./kernel/drivers/audio/usb obviously
references audio hardware so "_audio" suffix is excessive.
No functional changes.
* USB audio device entry number made 1-based instead of 0. According to
Haiku MultiAudio specs audio device entries should be 1-based but
0-based;
* cleanup and refactoring. No functional changes;
* recording stream activated;
* fix input channels description report and codestyle issues.
* some functionality like recording temporarily disabled;
* set the endpoint speed call added;
* packet size hard-coded for 48kHz case;
* draft support for formats and sampling rate handling;
* implement sampling rate change on the fly;
* optimized using of starting frame;
* fix user_memory in buffer exchaqnge call;
* fix exchanged buffer recoriding processing;
* debug tweaks, fix current buffer switching;
* cleanup, cleanup, cleanup...
In case control transfer is finished with STALL answer from device only
the setup TD is retired into the Done Queue but other TDs (data and
status) are left in the ED queue. HC set the endpoint halted - so we
process such endpoint regardless of it's non-empty queue.
PS: cleanup some trailing spaces.
Finishing and refactoring the draft, initially implemented during April-May 2012
NOTE: startingFrameNumber returned to device contains the number of the
next free frame right after the last packed of submitted data. For more
details please Look into corresponding [haiku-development] discussion
started at 03 Jul 2013.
Partially fixes#1045.
