There is indeed more to being a maintainer than just commiting changes
to Haiku main tree. Removing people from there without asking them first
seems a bit rude.
Also update creadits for translations from Pootle generated ones.
* Move anyone who has not committed in over 24 months to "past maintainers"
* Add Kacper Kasper to "maintainers"
* Remove Brian Hill from "contributors" as he's now under "maintainers"
Was nothing but a slightly-stripped version of the nvidia driver,
not touched substantially in nearly 10 years, and the cards it was
originally going to support (but never got anywhere near so) have long since
been deprecated.
All of its prior functionality has been moved into HaikuControlLook.
This paves the way for customizeable control looks, which I intend to implement
in the future as part of decorators.
This is being pushed now because libbe ABI was already broken due to the
Notifications changes, so this is riding that so we only have to do a mass
rebuild once.
* Caching these values could result in missed
state changes.
* We may want to re-implement later.
* Highlights that all DP AUX communication is broken
during my testing.
- Rather than the previous (reverted) approach of tracking the last selected
stack frame from within the StackTraceView, we now do so from the TeamWindow,
where the selection can be mapped by thread. This fixes a subtle issue where,
due to a lack of contextual information, the stack trace view would restore
the remembered last selected frame rather than an explicitly chosen one. This
was most noticeable upon selecting a function that had a corresponding stack
frame in the current stack trace, where, instead of selecting that frame,
the existing one would remain highlighted, even though the state of all other
views had updated. Found while investigating the cause of #13710.
Notifications preflet:
-Use sliders instead of text fields for width and timeout
-Remove icon size choice (mini icon looks horrible)
-Consolidate both "Enable" checkboxes into one
-Fix Revert button, remove Apply button, add Defaults button
-All changes to settings saved immediately
-Live example notification message shown when settings changes are made
-Add setting for individual apps to specify whether their notifications
should be muted
-Remove history list (to be implemented later)
BNotification class:
-BNotification records the signature and name of application that
created it
-New functions to get source application signature and name
Notification Server:
-Notification pop up view layout fixes and bold font size fix
-Remove notifications history from AppUsage class (will be saved in
cache instead)
-Remove vector of NotificationView objects which isn't needed
-Get source application info from notification object, not the received
message which is not reliable
Applications can control the 256-color mode and change the palette. This
was not much used until now, but our terminal is now advertising itself
as xterm-256color. Mutt noticed this, tried to use the escape sequence,
and crashed Terminal here.
This allows us to get meaningful result for the system volume, which
would otherwise scan both hpkg files, and their whole contents as
mounted in the system/ hierarchy. Now only the packages are seen.
Directories are not ignored, so system/ (which is a different mount
point) will still be browsed, and system/packages (which is a
shine-through) will be found and counted in the used space.
Only using the keyboard navigation colour to indicate the current day isn't that
nice in all situations. When using custom system colours, like white on blue
for selected items, it can become barely readable.
Now we
* use bold type face for 'today',
* tint 'today's background (lighten for dark, darken for bright bgColor),
* use B_LIST_SELECTED_BACKGROUND_COLOR and B_LIST_SELECTED_ITEM_TEXT_COLOR
for the selected day,
* keyboard navigation colour only for the frame and text when doing keyboard
navigation
Fixes#13714
... by calling TBarView::UpdatePlacement() in
TBarWindow::FramedResized() only if the width has changed.
Explanation from take 1:
TBarWindow::FrameResized() calls TBarView::UpdatePlacement() to
resize the ExpandoMenuBar, however, UpdatePlacement() as part of its
work also resizes the window, which calls TBarWindow::FrameResized()
which in turn calls TBarView::UpdatePlacement() and so on.
To get out of this mess remove TBarView::UpdatePlacement() from
TBarWindow::FrameResized() but that leaves ExpandoMenuBar the
wrong size initially.
(now call UpdatePlacement() conditionally instead of removing it)
To fix this call SizeWindow() on AllAttached() which resizes
ExpandoMenuBar along with the rest of the window, but, just once not in
an infinite loop. Use AllAttached() rather than AttachedToWindow() so that
we are assured that ExpandoMenuBar and all of its children have been
attached thus avoiding the potential for an embarrasing Deskbar crash.
(we still need to call SizeWindow() on AllAttached())
Fixes#13706
TeamWindow:
- When changing the active function, we would also attempt to select a stack
frame matching that function. However, in the case where the active function
was set via changing stack frames, this logic would break if the function was
recursive, and would cause the topmost frame to be selected instead of one at
the desired recursion depth.
TBarWindow::FrameResized() calls TBarView::UpdatePlacement() to
resize the ExpandoMenuBar, however, UpdatePlacement() as part of its
work also resizes the window, which calls TBarWindow::FrameResized()
which in turn calls TBarView::UpdatePlacement() and so on.
To get out of this mess remove TBarView::UpdatePlacement() from
TBarWindow::FrameResized() but that leaves ExpandoMenuBar the
wrong size initially.
To fix this call SizeWindow() on AllAttached() which resizes
ExpandoMenuBar along with the rest of the window, but, just once not in
an infinite loop. Use AllAttached() rather than AttachedToWindow() so that
we are assured that ExpandoMenuBar and all of its children have been
attached thus avoiding the potential for an embarrasing Deskbar crash.
Fixes#13706
This was originally instated back in 2013, but was reverted then
due to #9636 because most other systems did not yet recognize that
terminal type.
Nowadays, nearly all Linux terminals specify themselves as being
"xterm-256color" by default, so reinstating this should be fine.
