In the vector case we are creating a bitmap, in the non-vector
case we are grabbing the bitmap from a resource.
The vector case we have to create a bitmap to rasterize.
The non-vector case we just grab the bitmap pointer.
We have to create new bitmaps from the vector icon at
different sizes, when we do that we were leaking the memory
occupied by the previous icon.
So make and use SetIcon() setter method which deletes the old
bitmap before setting the new one. In the non-vector case this
means we need to make a copy of the bitmap we grab from the
resources that we can safely delete.
Also delete bitmap on destructor.
For all other TBarMenuTitle's (meaning the team menu item),
we are grabbing a bitmap from resource, so don't delete the
bitmap as it is owned by resource set, we just use the pointer.
Fixes#8505 restoring the aesthetic integrity of the cut-off leaf.
Add vertically & horizontally centered, whole vector icon to rdef.
Reformat BarMenuTitle.h rename header guard from BARMENUTITLEH to
BAR_MENU_TITLE_H.
Created TDeskbarMenuTitle subclass which deals with Deskbar menu
item stuff like getting the icon from vector data and pushing the
leaf down a few pixels to cut off the leaf (maintaining its aesthetic
integrity).
Made TBarMenuTitle methods virtual. Remove unused expando constructor
parameter and private variable.
Add a TODO to scale the bitmap if we can't find any vector icon data.
With non-vector bitmap it behaves same as before this commit in
horizontal mode.
Adjust kMinimumTrayWidth to restore Deskbar's minimum width to its
classic value since days of yore, 143px. This, perhaps not coincidently,
is exactly the amount fit 7 replicant icons. Update constants in the
code to reflect this reality. Adjustable width coming soon.
replace dynamic_cast<TBarApp*>(be_app) with a static_cast in 1 place.
* We don't have kernel/userspace access to UEFI at this point
either, and with some firmware, if we don't keep the
runtime memory identity mapped, then the loader dies. This
will fix booting on such machines, and shouldn't have any
impact on already working machines.
Also includes changes to HaikuDepot to change wording and add the menu item
to open the Repositories preflet.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Closes#13147.
- This is the native resolution of two of my displays here
- I am bored of manually setting it with screenmode -m
- Also fix the 1366x768 modeline which was 100Hz instead of the
advertised 60Hz.
* Maintain a list of all MESSAGING_DEVICE_PATH and
MEDIA_DEVICE_PATH handles, so we can avoid adding devices
multiple times.
* Split up platform_add_boot_device() into separate functions
for better readability (add_cd_devices, add_boot_device_for_image,
etc.).
* This is useful for UEFI, as we can then add the device that
contains the UEFI loader, as well as all CD devices. As a
result, if the device with the UEFI loader doesn't contain
a bootable BFS partition, it will then attempt the same for
CD devices.
In ffmpeg, an audio frame may be made of multiple samples. We don't
really support that in our plug-in, and assume the frame rate and sample
rate are the same thing.
Adjust the reported frame count by multiplying ffmpeg's frame count by
its frame size (which is the number of samples per frame).
This fixes audio not working or stopping after a short time in
MediaPlayer, which uses the frame count this way.
This allows me to find and boot disks and cds(*)
platform_add_boot_device tries to find the disk of the EFI partition
As on other platforms if boot disk isn't found platform_add_block_devices
will be called.
platform_add_block_devices will find all block devices that arn't partitions as
they are handled by Haiku already.
Currently first found suitable partition will be selected.
TODO:
* pass in partition UUID's as boot-loader arg to setup boot for
any partition.
* Better cd detection
* Better disk_identifier
*) vfs_boot.cpp is very restrictive when it comes to booting cds.
It either do very Anyboot check where boot partition should be at offset 0,
which isn't true for EFI. In my case it's not even on that disk.
Or it only allow data session partition types.
This is currently failing as the Anyboot partition type is BFS.
Talked with Vidrep, and he's right:
Apps already have a "Page setup" menu item, opening a window titled
"Page setup". Having a picture button in there that's labeled "Page setup",
too, isn't cool.
So, let's name that and its opening window "Paper setup", even if it's not
always 100% accurate. The PDFWriter e.g. has a compression and version
setting in there...
The LegacyPackageInstaller's data folder is (and has always been)
"~/config/packages", which is of course the same directory that Haiku's
(relatively) new package management system uses. We don't want the
"administrative" folder and any HPKGs in that directory to show up in
the "installed legacy packages" list, so ignore them.
Fixes CID 609586: Uninitialized members (UNINIT_CTOR)
Non-static class member "fWritable" is not initialized in this
constructor nor in any functions that it calls.
Also initialize fOffset and fBlockNumber to 0 for good measure.
