* The spacing is already present due to the insets
of the contents, so there was some extra room
between the menu and the contents which this
commit removes.
There isn't actually a file on disk somewhere. And Quit
could have been mistaken to quit the entire Debugger
application, as Quit in File usually does with applications.
However, it will only close the that team window and only
quit Debugger if it was the last open window.
Fixes#9753 (for real this time)
Don't resize the menu field when the menu bar resizes, the menu
field stays the same size because we'll need to use it's width to
check when the menu bar width has expanded beyond its width.
Then, if the selected menu item expands the menu bar to a width
greater than the width of the menu field resize it to the menu field
width.
* Factor out the code to add some data to the about window, with a header and a content under it
* Make this method public so it's possible to add custom entries in an about box
* If the method is called with only the header or only the content, the text is added non-bold and non-indented (like the description entry*).
* Make the header text bold. I'm not sure it looks that good, after all. Thoughts ?
This means the build tools will no longer be built against the host
platform's libbe, which avoids compatibility problems -- e.g. an
older Haiku host libbe may not have certain features the build tools
require -- and also makes the build behave more similiar on Haiku and
other platforms. The host libroot dependency still remains and is not
easy to get rid of.
Also remove some bits of BeOS/Dano/Zeta build support.
...a source path-based tree of all the image's functions, and
consequently organizes them into a nested hierarchy similar to the
on-disk directory structure in which they were originally found (or at
least, as close as we can get from the DWARF info).
It was there only for <build>mimeset, which is now always invoked with a
custom MIME DB and thus won't use the function anymore. We could
actually easily implement it using MimeInfoUpdater, if the MIME DB
directory the build system generates was compiled in.
* Update MimeSet rule to use the MIME DB the build system creates.
* Add CreateAppMimeDBEntries rule and call it from Link for targets that
might be applications that need to be registered with the MIME DB. For
the target the rule is invoked with it creates a directory into which
the entries for the types to be registered are written. The directory
is associated with the target via the HAIKU_MIME_DB_ENTRIES variable.
* AddFilesToContainer: If a target is added that has MIME DB entries,
also add those to the container.
* build_haiku_package: Call mimeset for the package contents.
Since the same driver can be added in more than one category, in a few
cases AddDriversToContainer was invoked twice for the same target. Avoid
adding the driver twice to add-ons/kernel/drivers/bin in such a case.
Didn't really cause any problem, but no need to copy the file twice.
* Don't require the first MIME DB directory to exist anymore. Database
creates it anyway.
* Make use of MimeInfoUpdater to support updating MIME info with a
custom MIME DB.
* Make use of MimeEntryProcessor::DoRecursively() to support recursive
operation with a custom MIME DB.
Jérôme Duval