#4562 closed enhancement (fixed)
MIDI endpoint icons should support vector icon format too
| Reported by: | phoudoin | Owned by: | phoudoin |
|---|---|---|---|
| Priority: | normal | Milestone: | R1 |
| Component: | Kits/Midi Kit | Version: | |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
Currently, the MIDI kit support endpoint "icon" in bitmap format only. Vector icon format should be supported too, for better audio *and* visual experience ;-)
Attachments (3)
Change History (16)
by , 14 years ago
| Attachment: | MIDI_icons.png added |
|---|
comment:1 by , 14 years ago
I've attached PNGs of initial suggestions for the icon, and an Icon-O-Matic file of the base version (no coloured rim).
follow-up: 4 comment:2 by , 14 years ago
| Version: | R1/pre-alpha1 |
|---|
Since those icons are not thought to be Tracker icons, I actually prefer the flat version. But I don't like the color indicator for consumer/producer - I would have chosen the reverse colors intuitively. Why not using an arrow, like usual in audio symbols?
follow-up: 5 comment:3 by , 14 years ago
| Status: | new → assigned |
|---|
Well, as most existing midi endpoints icons outwhere are flat ones, it would make sense. But I actually agree with Stephan here, Haiku goes with (pseudo)isometric vector icons, and there is not reason to not follow it system wide, midi_server physical endpoints includes. I also agree with the arrow for showing endpoint direction, red and green while obvious visual colors are semantically ambiguous regarding directions.
Anyway, nothing more easy than replacing some HVIF raw bytes with another "better-looking" ones.
I'll add HVIF support to midi_server soon (hopefully tonight) and use one of Pete's icon for a start. I also plan to import an HVIF-aware PatchBay under src/tests/kits/midi. Maybe this usefull tool could be promote as an MIDI app beside MIDI Player, BTW. Sadly, his current code breaks pretty much every coding rules...
comment:4 by , 14 years ago
Replying to axeld:
Since those icons are not thought to be Tracker icons, I actually prefer the flat version. But I don't like the color indicator for consumer/producer - I would have chosen the reverse colors intuitively. Why not using an arrow, like usual in audio symbols?
Agreed -- the colours seemed reasonable, but pretty arbitrary. How about an arrow top-left to centre/ centre to bottom-right?
follow-up: 6 comment:5 by , 14 years ago
Replying to phoudoin:
I'll add HVIF support to midi_server soon (hopefully tonight) and use one of Pete's icon for a start. I also plan to import an HVIF-aware PatchBay under src/tests/kits/midi. Maybe this usefull tool could be promote as an MIDI app beside MIDI Player, BTW. Sadly, his current code breaks pretty much every coding rules...
I was intending to modify PatchBay myself (and the midi_server too so I could test things). (The code -- even the app -- seems hard to locate these days, but I have a copy, so I can do the necessary.) I have already had to fix one blatant bug -- it uses the wrong list for the Producer icons! -- so it might be easier for me to proceed with the vector icon part too.
follow-up: 7 comment:6 by , 14 years ago
Replying to Pete:
I was intending to modify PatchBay myself (and the midi_server too so I could test things). (The code -- even the app -- seems hard to locate these days, but I have a copy, so I can do the necessary.) I have already had to fix one blatant bug -- it uses the wrong list for the Producer icons! -- so it might be easier for me to proceed with the vector icon part too.
Well, maybe we could split the task in two, me adding HVIF support to midi_server and you making PatchBay HVIF aware, beside fixing bugs.
Or I could just wait for your patch. You tell me.
At least, let me import Be's PatchBay sample code under src/tests/kits/midi/patchbay, so your patch will be smaller and easier to apply.
follow-up: 8 comment:7 by , 14 years ago
Replying to phoudoin:
Well, maybe we could split the task in two, me adding HVIF support to midi_server and you making PatchBay HVIF aware, beside fixing bugs.
Sounds good. I'm working on modifying PatchBay right now, so I'll let you know how it goes. I've had to hack in the vector icon into midi_server too, so I can test things, but I'll leave it to you to do it properly! (For now I'm using the message field name "be:vector_icon" for consistency with the existing names, but I suppose it should rather be "haiku:vector_icon". Your call.)
At least, let me import Be's PatchBay sample code under src/tests/kits/midi/patchbay, so your patch will be smaller and easier to apply.
Fine -- then I'll have a ticket target for the patch (:-))
comment:8 by , 14 years ago
Replying to Pete:
For now I'm using the message field name "be:vector_icon" for consistency with the existing names, but I suppose it should rather be "haiku:vector_icon". Your call.
Hum, I guess we could goes with "haiku:vector_icon" field name indeed, as it's available only on Haiku.
At least, let me import Be's PatchBay sample code under src/tests/kits/midi/patchbay, so your patch will be smaller and easier to apply.
Fine -- then I'll have a ticket target for the patch (:-))
Done in hrev34229.
follow-up: 10 comment:9 by , 14 years ago
I just add vector icon support to midi_server in hrev34230, using your attached MIDIport.icon flat vector icon above. I've check with PatchBay, and "bitmap" endpoint icons are now showing your icon. Oh, BTW, I goes in hrev34231 with naming it "icon", simply. A search show that message fields "be:xxx" syntax is kept *only* when R5 compatibility is needed.
Beside displaying larger vector icons, PatchBay may also benefits to move to haiku layout system, which will allow to display a larger endpoints matrix in a smaller space than what it take today. But that would make another enhancement ticket I guess.
follow-up: 11 comment:10 by , 14 years ago
Replying to phoudoin:
I just add vector icon support to midi_server in hrev34230, using your attached MIDIport.icon flat vector icon above. I've check with PatchBay, and "bitmap" endpoint icons are now showing your icon.
PatchBay still does not get correct vector icon data, because the resources data gets lost by the time _SetIcon() is called!
The problem is that the 'resource' variable is local to the DeviceWatcher constructor, and its data is not preserved outside that. Making it a static global fixes things.
follow-up: 12 comment:11 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Replying to Pete:
PatchBay still does not get correct vector icon data, because the resources data gets lost by the time _SetIcon() is called!
The problem is that the 'resource' variable is local to the DeviceWatcher constructor, and its data is not preserved outside that.
Nice spotted, and stupid error from my side. This should be fixed in hrev34358, while a vector icon aware PatchBay patched after your changes posted in haiku-development ML is available since hrev34357.
Thanks Pete.
follow-up: 13 comment:12 by , 14 years ago
Replying to phoudoin:
Nice spotted, and stupid error from my side. This should be fixed in hrev34358, while a vector icon aware PatchBay patched after your changes posted in haiku-development ML is available since hrev34357.
Considering both of us made exactly the same error... (:-/)
Anyway, thanks for fixing, and adding the vector-aware PatchBay. However, some observations:
1) in 34358, why didn't you just make the resources a global? I suppose copying just the icon data to a new array saves a few hundred bytes, but seems unnecessarily complicated.
2) I (finally) noticed that the row/column display bug I'd fixed in my copy of PatchView.cpp is fixed independently in the code you uploaded. Did you fix it, or is it somehow a later archive than the (I thought final) copy I had? The rest of the source is identical.
3) When you added my patch to EndpointInfo.cpp, you left in the printfs that I had added for debugging. (They were actually DPRINTFs, but I edited for the mailing list.) Also, if you want to leave the "#ifdef _ _HAIKU_ _" around it, you should do the same to "#include <IconUtils.h>". Or -- as I suspect it will quickly become BeOS incompatible -- just omit the conditional.
4) I don't believe the added 'libicon.a' in the jamfile is needed: I think it's included in libbe. When I was compiling PatchBay in userland, I simply linked IconUtils.h into the /boot/develop/headers hierarchy, and everything built and ran.
In any case, I'm still working on PatchBay. I want to replace the horrible [to my eye] 'Unknown Device' icon with a vector one, and get rid of UnknownDeviceIcons.h by adding an rdef. In the process it should also get an App Icon -- maybe a couple of crossed MIDI-cables? Still thinking on that...
comment:13 by , 14 years ago
Replying to Pete:
- Yes. Plus semantically we're not interested in app resources, just one single vector icon data. And I've not that much occasion to write delete[], so... ;-)
- Dunno. It's a version I find in an old BeOS partition, can't told you if it's a more recent than your or the reverse. What I know is that I didn't fix it myself.
- You're right, it's not clean. I'll fix that during next free time slot. Aka not immediately...
- Well, I just follow the way others apps needing libicon.a are built: they all link explicitly against libicon.a. While libbe.so is indeed linked with libicon.a (needed by BAlert, AFAICT), it's not official and I'm not sure we can assume that everything *your* app could needs from libicon.a is actually present in libbe.so.
I want to replace the horrible [to my eye] 'Unknown Device' icon with a vector one, and get rid of UnknownDeviceIcons.h by adding an rdef. In the process it should also get an App Icon -- maybe a couple of crossed MIDI-cables? Still thinking on that...
I'll create a ticket to improve PatchBay enough so we could promote it from a test app to a builtin app. After all, that's really a useful and central MIDI app...
Suggested icon variants (PNG file)