In fixed size mode, the menu field always uses all the available width.
In non-fixed size mode, the menu field will resize itself to be as small
as possible.
With layout, usually the difference isn't noticeable, since the layout
will already try to resize the control to the smallest possible size.
But there are a few cases where it makes a difference, when the layout
is over-constrained and the menu field can't be made as small as
possible. In that case, the menu field would be forced to fill its
allocated space, where we can instead make it a little smaller.
Change-Id: I911d497218a09aab3824865968558df5d4b3cf98
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6076
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: John Scipione <jscipione@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
These were introduced by mistake during the addition of the layout
system. They have been private since 2011. It seems safe to assume that
nothing uses them anymore and they can now be removed safely.
Change-Id: I98d030096f9cb06fccc25233fe4da17d0213050e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6075
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The code is endian-dependant because the alpha channel is not at the
same place. This resulted in transparent white in icons being converted
to partially transparent yellow when attempting to darken the icons, for
example.
Change-Id: I57916139ba37b8d7ae0f9e9ba9e74c1d496d7b05
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6077
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The previous logic of _AddTrim plus _TrimNext meant that if a trim
range was specified in the final call to _TrimNext (i.e. with force=true),
but the trim buffer was already full at that point, that last range
would not actually be trimmed.
Now, _AddTrim returns true when the buffer is filled and trimming
should be done, rather than delaying it and requiring a second
add after trimming.
Change-Id: I4b782948e8dc9267c63e61bce0c078fd4e834177
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6070
Tested-by: Automation <automation@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
BSD extension to set both the input and output speed of a termios
structure.
Fixes#18220.
Change-Id: I8c4a06b4be4aa55b8ce35cb7f62552fc47a8e8d0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6049
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
There's only one implementation of smix so we don't
need any selection logic.
Change-Id: Id43e4ed49ee5a96755c3c4ab975bd128024e57b0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6065
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Define a dedicated OnDiskData structure for each on-disk structure. This
must match the on-disk layout, except for endianness, which is handled
by _SwapEndian methods. These structure are "plain old data" so we can
use offsetof on them. They are wrapped in an easier to use C++ API.
This resolves a lot of problems with the previous code: warnings caused
by the use of offsetof as well as a much simpler instanciation of the
objects from on-disk data.
Also fixed another problem with UUIDs, where the UUIDs were handled by
pointers in a lot of place where it was not necessary. Use references
instead. The V4 structures which don't have an UUID will return a "null"
(zero-filled) one.
Change-Id: Ifb2bf6ab94906ca50410dd3446d3566615392ca2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6021
Reviewed-by: Raghav Sharma <raghavself28@gmail.com>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
..instead of readv_pos/writev_pos. This way, we can be sure that we
are remapping them properly even under Haiku, as well as remove some
potential confusions.
bfs_shell seems to still work fine on a regular build.
All drivers using IORequest should have any problems here already caught
by it, and overruns in other drivers would overrun the buffer and cause
corruptions, so we should no longer silently be ignoring this,
presuming it is still a problem at all.
As the TODO comment indicated that this logic could also be used for
writes if this wasn't a problem, I have added a separate TODO for that.
They are not about reading and writing pages, but just iovecs.
As the passed iovecs use void*s, it can't possibly be working with
physical pages on 32-bit systems with PAE.
It appears nothing uses or implements these functions anyway,
as there was nothing else in the tree I had to adjust after making
this change...
This is required to make crypt_r() really reentrant.
Change-Id: I81497be16cae21fabb5895a88e27e6c20d3e06e0
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6066
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
On adding a font, we may or not have other faces of the same family, so
we may be trying to add the new face to an already managed family. In
that case, we can't delete it when we get an error inserting the new
style.
This same code was already in place before the user fonts, but it's much
more unlikely to trigger, except maybe on purpose. A later patch
refactoring a bunch of things will join both into the base class.
Fixes#18169
Change-Id: I78053b6e941c18b952fc2bd64f393e26d3d53b0a
* Enable user to drag the WebPositive web page icon to the bookmark
bar to create a bookmark there, or drag it to a Tracker window to
create a bookmark in the displayed directory.
* Send a message to the drag target that can be handled by Tracker's
generic drop routine.
* Overload _CreateBookmark with a more flexible version and a
_CreateBookmark(BMessage*) that handles both the icon being dropped
on the bookmark bar, and the message that Tracker sends if the icon
is dropped on Tracker.
* Account for the fact that, when _CreateBookmark(BMessage*) is called,
Tracker may or may not have already determined the file name to use and
created the file, depending on whether the icon was dragged to
Tracker or not.
* Use page-specific small and large icons for the bookmark file, if
they are available (currently Haiku WebKit doesn't seem to provide
them though).
* Follows CharacterMap as a model for dragging an icon and ShowImage
for dragging to Tracker.
* Fixes#10795.
Change-Id: I7f32013cc1372dab1894b5d92335d3a4cbfb671f
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6007
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
DuckDuckGo terms of use say "don't use our name for your app", so go for
a generic "Web Search". Mention them in the README, however.
Their terms of use say "don't remove our branding", but the results from
the HTML page have pretty much no branding. There's a logo at the top of
the page, but the terms of use also say "don't use our logo". So I guess
we're fine here.
Change-Id: Ib24a95faf4e727769ae00c1cb74fab79abde0379
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5498
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
This is much easier to parse. The only downside is it is HTTPS only, so
we can't do this in the kernel. But it works well as a userlandfs
filesystem.
TODO: rename and replace the icon. Make it clear that the replies are
generated by DuckDuckGo (we can add this in the README file exposed by
the filesystem for example)
Change-Id: I7cdbe7d71d63f3ab742f21dc55fb9df7b16da7df
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5495
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
* Extracted an "acpi_ac_update_status()" function.
* Use that for both "acpi_ac_init_driver" and "acpi_ac_notify_handler".
This ensures that "acpi_ac_read()" returns the correct (current) status.
Change-Id: I4f8f35037180c10fe507b9abfda3a8a169349c13
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6048
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
FontFamily is babysitted by the FontManager. It doesn't own FontStyle
references, there's no place in it to release them.
FontManager owns a reference to the FontStyle, and it is in
fStyleHashTable. Putting a style there acquires a new reference, so we
can release the one from the new style. Removing a style from the map
releases the reference. We need to clear the map before shutting down
FreeType to get rid of our last references and let the styles die now
instead of afterwards to avoid double freeing the faces.
These solve the new crash from the previous patch. It didn't crash
before because even after the map was destroyed there were still
dangling references to the styles.
On removing a user font, the style will remove itself from the family
through the manager if that was the last reference, and the manager will
remove and delete the family if it has no more styles.
Change-Id: I460ff830fa8a8a5adb90dc8ea12120e1e50a5912
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6052
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
The managed families are already deleted (in a correct way) in
FontManagerBase, so it's unnecessary to do it in GlobalFontManager.
Fixes#18245, though it surfaces another problem.
Change-Id: I93f1dcd1e0c1ec8d0657f3db6b484662e50c3487
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6051
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
When using the panel background color, always use the matching panel
text color from system preferences.
When using a custom color, compute appropriate light or dark text color
to go with it.
Change-Id: I107731efec03a8c9661b89e26255a4fe91def79b
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3560
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
* changed explicit locking to use Autolocker for gFontManager/fAppFontManager
in ServerApp, per comments in https://review.haiku-os.org/c/haiku/+/4790
* changed BFont::LoadFont (memory version) to use size_t for size and offset
* no functional changes
Change-Id: I438a4975d5bb1b2fa17bc54e9e171c31dadfeec5
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6003
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: Adrien Destugues <pulkomandy@pulkomandy.tk>
It was used only for playing CDs via SCSI commands, which is what
CDPlayer also did; but this is not really much supported anymore,
so CDPlayer was removed years ago, and now this is too.
Its source code lives on at HaikuArchives.
Fixes#18236.
errno is a thread-local variable, we can't read it in another thread
and have the value make any sense. Thus we need to store it.
Fortunately, as our errors are all negative already, we can just put it
directly in fFD instead of having to make a new variable altogether.
Should help with diagnosing a problem seen in some syslogs.
