Opened 10 years ago

Closed 4 months ago

Last modified 4 months ago

#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 jscipione, 10 years ago

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

comment:2 by umccullough, 10 years ago

Type: bugenhancement

At the very least, this is an enhancement, unless the public API for this existed already in BeOS R5.

comment:3 by waddlesplash, 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.

in reply to:  3 comment:4 by bonefish, 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 pulkomandy, 10 years ago

Milestone: R1/alpha5Unscheduled

New APIs are out of R1 scope, moving out of alpha5 milestone.

comment:6 by waddlesplash, 9 years ago

Owner: changed from axeld to waddlesplash
Status: newassigned

comment:7 by pulkomandy, 4 years ago

Blocking: 1142 removed

comment:8 by pulkomandy, 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 SamuraiCrow, 12 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 nephele, 12 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 pulkomandy, 12 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 pulkomandy, 12 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 nephele, 12 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 pulkomandy, 12 months ago

Owner: changed from waddlesplash to pulkomandy
Status: assignedin-progress

comment:16 by pulkomandy, 4 months ago

Milestone: UnscheduledR1/beta5
Resolution: fixed
Status: in-progressclosed

Change merged in 4dbd474753bd0d7392dc9d6f350ff5b7ec9f43f2

comment:17 by X512, 4 months ago

Why obscure Git hashes, not hrevXXX number?

comment:18 by pulkomandy, 4 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 X512, 4 months ago

Trac automatically make hyperlinks from hrevXXX numbers, but not from Git hashes.

comment:20 by humdinger, 4 months ago

It's hrev57030 for the record.

Note: See TracTickets for help on using tickets.