* BRoster now allows settings a "no-registrar" mode that is currently
only honored in _LaunchApp(), though.
* Job::Launch() is now using this, which also allows launching
applications by signature (ie. if the job name matches the
signature, you can omit the "launch" option).
* This will be heavily inspired by Apple's launchd, as well as
systemd -- for now it really doesn't do a whole lot, though.
* What works so far: the configuration files are read, parsed, and
the jobs created.
* The jobs are even initialized, and their message ports created.
* BApplication now retrieves a previously created port from the
launch_daemon for use with BServer.
* Only the registrar actually uses this for now.
* 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.
netresolv (and libbind) won't cache DNS requests, which can result in a
lot of DNS requests being made for the same host. Implement a simple
cache in RAM (local to each application) which will keep the most
recently requested addresses cached. This can speed up loading of an
HTTP page a lot, by saving a DNS request for each resource stored on the
same server as the main page.
* Put it in the BSupportKit namespace, following the style introduced
with the package kit for now.
* The BSupportKit::BJob class no longer knows about the package kit's
Context class. However, the BPackageKit::BJob class does.
* Due to the namespace juggling, a lot of files had to be touched.
* The JobQueue class remains private.
* Due to the way Haiku is built on itself, you cannot build this change
under Haiku with an older release.
"Renaming" means the icu namespace is suffixed with the version number,
atm icu_55. Using "renaming" allows to use two different versions of ICU,
thus easing upgrades. For instance haikuwebkit uses a current version of ICU,
while the system uses a newer one after an upgrade.
* Replace all uses of the icu namespace in our public headers, with a macro
defaulting to icu. As the namespace is only used for private fields pointers,
there should be no impact.
* Locale kit *.cpp have to import the macro from <unicode/uversion.h> *before*
including any locale headers. Ditto for a Time preferences cpp file. This way,
the correct current icu namespace is referenced.
* Fixes bug #12057.
Those return uintNN_t types instead of our own types,
but uint32 for example is long while uint32_t isn't,
giving some trouble with the PRI* macros for example on PPC.
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.
The BNetworkRoute class manages a route_entry and the sockaddr's
associated with it. It replaces the direct use of route_entry in the
BNetworkInterface API.
Using route_entry is fragile and inconvenient as it only holds pointers
to the sockaddr's. When getting a list of routes from the kernel, each
route_entry is set up so that its pointers point into the single flat
buffer that is passed around. Creating a copy of the route_entry and
then deleting the flat buffer makes the pointers in the copy stale.
Returning these route entries therefore always lead to a use-after-free
when they were eventually used.
BNetworkRoute also takes over the code and functionallity of getting
routes from RouteSupport. The corresponding method in BNetworkRoster is
replaced by a static method in BNetworkRoute.
Also distinguish between the default route and gateway of an interface.
GetDefaultRoute() now gets the default BNetworkRoute for the interface
while GetDefaultGateway() gets the associated gateway address within
that default route. Adjust network preferences panel to this change.
Note that we currently only seem to have per interface default routes
and not an actual global default route. This was already the case before
these changes and I did not further investigate what this means.
* And call it from the DNS client -- this is the only add-on that does
not trigger a configuration or settings update, so we have to notify
the changes manually.
* Get{Interface|Network|Service}() methods are now const.
* Added variants of Interface(), and Service() that are const.
* Added new BNetworkServiceSettings::IsRunning() convenience method that
reflects the status quo rather than the settings.
* Added BNetworkInterfaceListItem that can be used by interface protocol
add-ons to represent their functionality in the list view.
* It will automatically update itself on changes, and will show the
specified label, and address, if any, as well as indicate whether or
not the family has been disabled (which doesn't work perfectly yet,
as IFF_AUTO_CONFIGURED is on the interface level).
* Therefore, the interface list item will no longer show the address,
but the type of the device instead.
* Introduced the BNetworkConfigurationListener interface that is used
to broadcast network updates to.
* Network now monitors all network, and network settings changes, and
will notify all add-ons about those changes.
* Removed the global apply button. Instead, the static IP configuration
now got that button. All other changes will be instant.
* Added (still incomplete) helper classes for the settings messages.
* The net_server now uses these classes for its interfaces, and services.
* Renamed service_address to service_connection, as that better matches
what it is used for.
* As experimental API class BNetworkSettings.
* Added add/remove methods for interfaces, and services, too.
* Moved the conversion of the wireless networks into the settings class,
too, so that it only gives out converted ones (but accepts both
variants).
* The interfaces logic is within the main application, so is the
new interface view.
* Disabling/renegotiating does not work yet.
* Reveals a bug in some interface code; when you click on an ethernet
device first, there is no place for the wireless menu. When you then
press on a wireless device, it crashes in BMenuField code.
In the other direction, there is then an empty space.
* Fixed list item width reporting.
* Added an extra looperName argument to the private BApplication
constructor that BServer is using.
* This is now used to fix the ugliness that gave the registrar
a different looper name, and even saves a string comparison.
They are effectively the same thing, but int64 is more generic.
I used an off_t because that is what Tracker passed in, yet, this could be
used in other places where an off_t doesn't make as much sense.
Which doubles the maximum width fixing #11809. I wanted to convert this to
a variadic functionbut that would require updating all of the instance that use
MessageFormat or a clever hack to get around the ambiguity of an off_t
argument and an int argument count with 0 arguments. Either way seemed
out of the scope of fixing this bug.
Fixes#11809
Another Beta1 bug down!
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.
