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 seems like glibc also has paths.h and m4 fails to bootstrap
without _PATH_BSHELL.
This file really needs some cleanup btw, since most is actually
irrelevant or incorrect for Haiku.
In hrev47355 a logic reversal was introduced as part of a cleanup
commit which caused B_ARGV_RECEIVED to be sent only to apps with the
B_ARGV_ONLY flag set instead of clear.
In addition to that, don't send the B_SILENT_RELAUNCH message for apps
with B_ARGV_ONLY either, as they are not supposed to receive messages
after launch. This is in line with the documentation and what BRoster
does.
* We don't change the data cache (and other) settings.
Interesting to know their state on each platform.
* Not used by default as it needs called after
serial-init in u-boot
The AddOnManager was in the global namespace, clashing with application
classes with the same name.
The input_server has an AddOnManager of its own. When the
shortcut_catcher filter was loaded by said AddOnManager, it in turn
loaded libgame.so, which in turn loaded libmedia.so, where an
AddOnManager was created for the global AddOnManager instance in
libmedia.so. Unfortunately the wrong AddOnManager, the one from the
input_server, was created. This lead to two AddOnManagers being active
in the input_server which very well could be responsible for #11049
and #11280.
This was a regression since the move of the AddOnManager from the
media_server to libmedia.so in hrev47086. This also fits with the two
tickets.
I actually noticed the problem when debugging the shutdown process of
the input_server, where the destruction of the wrong AddOnManager
caused a deadlock with itself.
* Before this commit address bar used:
B_MENU, B_LIST, B_DOCUMENT colors.
With strange results during customization.
* Now the address uses list user colors.
* Partialy fixes#10840.
The model was owned by the info window and is gone at the point where
the AttributeView is destroyed. Since the extra check whether the model
is a symlink isn't really needed at all, I opted to just remove it
instead of destroying the AttributeView sooner or unsetting its model.
The layout item representing the layout of the view to be removed is
owned by the view and must not be deleted. The layout only owns the
item if a new layout item was created when adding the view, i.e. when
it did not have a layout.
Fixes the underlying issue that triggered #11976.
Removing the view from the window and deleting it is fine. This is a
quick fix for #11976. The underlaying issue of how BLayout::RemoveView
should work still needs to be fixed.
* Do not define the symbols by default, as they are not in the default
libraries.
* Adjust jamfiles of all code using BSD extensions to define
_BSD_SOURCE.
* This makes Haiku slightly more compliant to standard C/POSIX.
Because of the virtual hooks a BLayout must never be destroyed while it
still has layout items. If these items are only removed from the layout
in its destructor, the subclass version of hooks like ItemRemoved() are
not called anymore. This lead to leaks because many BLayout subclasses
use the ItemRemoved() hook to clean up associated data (as is suggested
explicitly in the BLayout documentation).
In the same line of thought, a BLayoutItem must never be deleted when it
is still attached to a layout, as it similarly has virtual hooks like
DetachedFromLayout() that can not be called at this point anymore.
The destructors of BLayout and BLayoutItem now have debugger calls in
case these conditions are not met which should help to avoid
accidentally introducing such hard to debug issues.
To ensure the correct destruction order the sequence is now:
* Destroy the child views first. This cleans up their layout items while
the layout tree is still intact.
* Unset the view layout before removing layout items so it can properly
detach from the layout instead of just deleting it.
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.
... especially for SendMessage and SendReply.
* Delete the item's message if AddItem does not return successfully.
* Fixes#11934.
Signed-off-by: Adrien Destugues <pulkomandy@gmail.com>
