It literally did nothing except look nice^W^W^W^Wterrible, as it didn't
use the Layout Kit and it pre-dates the Haiku coding style (last "real"
modification was sometime before 2005). Supposedly it saved its settings
to disk but I can't find that.
See the "pppconfig" and "ppp_up" applications in src/bin/network for
something that actually works (though the modem stuff in the kernel PPP
stack hasn't been rewritten, so those are PPPoE only at the moment.)
* When the event is late there are two major situations, the first
is when the enqueue time is in past compared to the performance time.
The second happen when the performance time is in past compared to the
enqueue time. The purpose of this change is to calculate the lateness
considering always the nearest of the two values. This way the exceding
latency is trimmed out from the calculus depending on what the actual
source of delay is.
* There is a lot more that could be done by looking at the previous
lateness value.
These buttons go to the left according to the ad-hoc rule we've
created for preflets. The right side is reserved for an Apply or OK
button and is left blank otherwise.
SetBorder(B_NO_BORDER) on tabView.
Add a BSeparatorView to draw a line between tabs and bottom buttons
Inset by B_USE_WINDOW_SPACING around buttons.
(B_USE_DEFAULT_SPACING betwen buttons and the tabview)
Change suppress warnings options to -Wno-sign-compare
since -Wno-error= can be used with gcc 4.2 or later.
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
Einsteinium provides smarter monitoring of applications and system services for
Haiku. It will restart applications and system services that quit or crash,
gather statistics on application usage and provide customizable ranked lists
of applications.
- Introduces new network API class BSocketMessenger, allowing one to send
and receive BMessages across a network socket in a BMessenger-like
fashion. Still very much WIP, hence currently not exposed via public headers.
Based partly on previous work by Axel.
...instead of DrawBox().
Also use ceilf when calculating tab height to prevent non-integral height.
Fixes#12683
More Todo:
You have to understand way too much about how this class draws if you
want to have any hope of overriding one of its Draw... methods and have
it do what you expect.
e.g. The BeBook implies that the tabs are drawn first, then the box, but, we
draw them in the opposite order. Probably better this way but not intuitive.
There are a number of remaining questions:
1. Why don't we need to draw the bottom of tabs if B_FANCY_BORDER?
2. Why do we need to expand tab border horizontally if B_PLAIN_BORDER?
3. Why is the bottom border color (152, 152, 152) instead of (151, 151, 151)?
Add a bunch of TODOs for these questions and more.
There can be some unitiutive gaps between the box border and view
depending on if you choose B_FANCY_BORDER or B_PLAIN_BORDER.
You don't notice the gaps unless the view draws right on it's edge. Some
views, including in Devices and Media Prefs do this though. Media Prefs
further complicates matters by overriding BTabView.