Opened 4 years ago
Closed 4 years ago
#16473 closed bug (fixed)
Autoraise icon in sys tray distorted
Reported by: | yangh | Owned by: | ambroff |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Applications | Version: | R1/beta2 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
Attachments (1)
Change History (8)
by , 4 years ago
comment:1 by , 4 years ago
Component: | Preferences/Appearance → Applications |
---|---|
Description: | modified (diff) |
Owner: | changed from | to
Status: | new → assigned |
comment:2 by , 4 years ago
comment:3 by , 4 years ago
When you first add it to the deskbar it does write the actual path.
~> message ~/config/settings/x-vnd.mmu.AutoRaise_settings BMessage(0x0) { ar:active = bool(false) ar:delay = int64(0x7a120 or 500000) ar:mode = int32(0x0 or 0) ar:app_path = entry_ref(device=4, directory=741, name="AutoRaise", path="/boot/system/apps/AutoRaise") }
The directory entry changed. I suspect that the problem is that persisting an entry_ref for a file from packagefs doesn't work because the device and directory aren't stable across reboots?
comment:4 by , 4 years ago
Anyway this is easy to fix by just getting the path using our_image() trick that other tray applets use, rather than storing the path in the settings.
comment:5 by , 4 years ago
Owner: | changed from | to
---|
Fixed here: https://review.haiku-os.org/c/haiku/+/3341
comment:7 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Note:
See TracTickets
for help on using tickets.
I've noticed the same thing and just looked into it. I see the problem.
When the applet loads it creates an instance of TrayView. The constructor calls TrayView::_init(), which loads the bitmaps that are used in the TrayView::Draw().
So the bitmaps get loaded from resources in the AutoRaise app file which lives in /boot/system/apps/AutoRaise. How does _appPath get initialized?
Looking at the settings file the answer becomes clear.
So it is supposed to write the path to itself in its settings, and when it is loaded back up, is supposed to use that path to the binary so that it can load the resources. But it's unable to find the file.
And since the error returned from res.SetTo() is ignored, the _activeIcon and _inactiveIcon bitmaps end up containing random garbage.