Opened 2 years ago

Closed 2 years ago

Last modified 17 months ago

#15313 closed bug (fixed)

Icons - running apps showing "broken computer" icon

Reported by: vidrep Owned by: pulkomandy
Priority: normal Milestone: R1/beta2
Component: User Interface Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


hrev53416 x86_64

When viewing running apps in either Process Controller or Slayer, the icons displayed are those of a "broken computer". See attached screenshots to illustrate.

Attachments (3)

ProcessController.png (87.6 KB ) - added by vidrep 2 years ago.
Slayer.png (96.5 KB ) - added by vidrep 2 years ago.
SoftwareUpdater.png (10.3 KB ) - added by vidrep 2 years ago.

Download all attachments as: .zip

Change History (10)

by vidrep, 2 years ago

Attachment: ProcessController.png added

by vidrep, 2 years ago

Attachment: Slayer.png added

by vidrep, 2 years ago

Attachment: SoftwareUpdater.png added

comment:1 by diver, 2 years ago

I also see it. Could be related to hrev53399.

comment:2 by waddlesplash, 2 years ago

Owner: changed from stippi to pulkomandy
Status: newassigned


comment:3 by pulkomandy, 2 years ago

Makes sense, as the app argv[0] is now pointing to the symlink, so code using that should resolve the symlink if neded, I guess? Or use get_image_info instead?

comment:4 by waddlesplash, 2 years ago

There is already a function "get_app_ref" which has a "bool traverse" parameter. Should we always set it here? If we did, this would remove the capability (which I think PulkoMandy was trying to add) to set icons in symlinks.

comment:5 by pulkomandy, 2 years ago

My work (for this change) was not to allow setting icons on symlinks, but allowing the app itself to know that it was launched from a symlink, getting the correct argv[0] so it can use the filename (busybox uses this when run from Terminal to behave as different apps), or in the case of the app I'm working on, use informations stored in the symlink attributes to behave differently.

Setting the icon on symlinks is in fact somewhat easier: Tracker is explicitly traversing the symlink to get the icon already, at least in the InfoWindow case, and will show the correct icon for broken symlinks, if you set one. So we would just need to reverse the order in which we check things here (check if the symlink has an icon first, and if it doesn't, check the pointed file/dir).

I'm now testing changing BRoster to dereference the entry_ref it gets, so that GetTrackerIcon will behave correctly for getting an icon from a running application (through its app_info).

comment:6 by waddlesplash, 2 years ago

Resolution: fixed
Status: assignedclosed

Fix merged in hrev53430.

comment:7 by nielx, 17 months ago

Milestone: UnscheduledR1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

Note: See TracTickets for help on using tickets.