Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#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:
Has a Patch: no 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)

MIDI_icons.png (25.8 KB) - added by Pete 9 years ago.
Suggested icon variants (PNG file)
MIDI_32x32_icons.png (11.9 KB) - added by Pete 9 years ago.
32x32 icon images (PNG)
MIDIport.icon (14.9 KB) - added by Pete 9 years ago.
Base 2-D Icon-O-Matic file

Download all attachments as: .zip

Change History (16)

Changed 9 years ago by Pete

Attachment: MIDI_icons.png added

Suggested icon variants (PNG file)

Changed 9 years ago by Pete

Attachment: MIDI_32x32_icons.png added

32x32 icon images (PNG)

Changed 9 years ago by Pete

Attachment: MIDIport.icon added

Base 2-D Icon-O-Matic file

comment:1 Changed 9 years ago by Pete

I've attached PNGs of initial suggestions for the icon, and an Icon-O-Matic file of the base version (no coloured rim).

comment:2 Changed 9 years ago by axeld

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?

comment:3 Changed 9 years ago by phoudoin

Status: newassigned

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 in reply to:  2 Changed 9 years ago by Pete

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?

comment:5 in reply to:  3 ; Changed 9 years ago by Pete

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.

comment:6 in reply to:  5 ; Changed 9 years ago by phoudoin

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.

comment:7 in reply to:  6 ; Changed 9 years ago by Pete

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 in reply to:  7 Changed 9 years ago by phoudoin

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.

comment:9 Changed 9 years ago by 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. 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.

comment:10 in reply to:  9 ; Changed 9 years ago by Pete

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.

comment:11 in reply to:  10 ; Changed 9 years ago by phoudoin

Resolution: fixed
Status: assignedclosed

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.

comment:12 in reply to:  11 ; Changed 9 years ago by Pete

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 in reply to:  12 Changed 9 years ago by phoudoin

Replying to Pete:

  1. 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... ;-)
  1. 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.
  1. You're right, it's not clean. I'll fix that during next free time slot. Aka not immediately...
  1. 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...

Note: See TracTickets for help on using tickets.