#10887 closed enhancement (fixed)
Public API to get a "default icon" (for example for standard toolbar icons)
Reported by: | waddlesplash | Owned by: | pulkomandy |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta5 |
Component: | Kits/Interface Kit | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Currently, icons are usually retrieved from an app's resource file. This shouldn't be the case for standard icons (like home, left, right, stop, info, warning, etc.), which should be retrievable.
I say this should go in "BControlLook" (icons embedded inside libbe.so), so we potentially could have different "BControlLook"s for different styles and have a separate icon set for each.
Blocking #1142 because currently, all the apps will have duplicate copies of icons for their toolbars...
Change History (20)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Type: | bug → enhancement |
---|
At the very least, this is an enhancement, unless the public API for this existed already in BeOS R5.
follow-up: 4 comment:3 by , 10 years ago
@Urias, Oops, you're right.
@John, no, that's not what I meant. One should be able to call be_control_look->GetIcon("edit-copy")
and get an easy-to-use icon class (BIcon
) and use it.
comment:4 by , 10 years ago
Replying to waddlesplash:
@Urias, Oops, you're right. @John, no, that's not what I meant. One should be able to call
be_control_look->GetIcon("edit-copy")
and get an easy-to-use icon class (BIcon
) and use it.
I don't see a reason why #1142 or this ticket have the target milestone alpha5. While both is nice and useful functionality neither has been in BeOS R5, nor is there any other reason for urgent inclusion in R1.
comment:5 by , 10 years ago
Milestone: | R1/alpha5 → Unscheduled |
---|
New APIs are out of R1 scope, moving out of alpha5 milestone.
comment:6 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:7 by , 5 years ago
Blocking: | 1142 removed |
---|
comment:8 by , 4 years ago
Summary: | Public API to get a "default icon" → Public API to get a "default icon" (for example for standard toolbar icons) |
---|
comment:9 by , 18 months ago
If coupled with the "FontAwesome" (ab)use of font glyph formats from the Web Font API, grouping icon sets together could be possible and even practical. Having an HVIF derivative that can be a multi-glyph representation of an icon, could be a combination of an idea I pitched on the forum about an HVIF font editor and format for Haiku. It's just a matter of a mapping API that's independent of the text paradigm.
Unfortunately, that would make the changes to Icon-o-Matic during the current Summer of Code project a corequisite or even prerequisite for the completion of the idea. I wonder how hard it would be to accomplish. (I also wonder if I used too many big words in this post for the non-English speakers. Oops!)
comment:10 by , 18 months ago
HVIF is not suited for fonts, it's strength lies elsewhere.
Why create fonts nobody but Haiku can read? Let's first fix our support for variable fonts if storage size is the issue.
comment:11 by , 18 months ago
SamuraiCrow, your comment is completely offtopic from the initial bugreport here. This is not the first time this happens, and it is not great. Please open your own enhancement ticket or forum topic to discuss your idea. You can mention related tickets and other forum topics if needed.
Especially in the bugtracker it is important to keep the discussion in each ticket *extremely* focused on one thing. Otherwise, the initial problem in the ticket gets lumped with a thousand other improvements, the task becomes too big, and nothing ever gets done.
comment:12 by , 18 months ago
While it is indeed already possible to get the alert icons from app_server as shown by John, it is not convenient at all, and a bit hardcoded. So an easier API should be provided.
I will take a look into doing it, since I also wanted them for the new AlertWithCheckBox in Debugger but couldn't do it. (I could also have used them in the debug_server crash dialog, but the "bug" icon used there was better).
comment:13 by , 18 months ago
Doing it in control look as suggested sounds like the best option since it now already provides size information to the layout kit for windows aswell as other drawing of gui elements. Perhaps it can even draw them itself instead of providing a hvif provide a BPicture.
comment:14 by , 18 months ago
Owner: | changed from | to
---|---|
Status: | assigned → in-progress |
comment:16 by , 11 months ago
Milestone: | Unscheduled → R1/beta5 |
---|---|
Resolution: | → fixed |
Status: | in-progress → closed |
Change merged in 4dbd474753bd0d7392dc9d6f350ff5b7ec9f43f2
comment:18 by , 11 months ago
I don't know the hrev number. You can look it upeasily from the SHA1 if you want.
Usually I put the hrev when I have it (when I close the ticket just after merging something) but here I forgot to do it when I merged the change.
comment:19 by , 11 months ago
Trac automatically make hyperlinks from hrevXXX numbers, but not from Git hashes.
We already have a few icons in app server that apps can retreive and use such as the stop and warn icons used by alerts. Here's an example where I'm grabbing them from app_server and using them in Keymap preferences:
http://cgit.haiku-os.org/haiku/tree/src/preferences/keymap/ModifierKeysWindow.cpp#n147