"I'd guess that Zune doesn't support embedding images inside Text.mui using the \A tag. Here's the relevant information from MUI_Text.doc:
ESC A[x]
draw raw ARGB data taken from struct MUI_AlphaData pointed to by
<x>, i.e. "\033A[deadbeef]". The address may be prefixed with a '$'.
This is how RapaGUI and MUI Royale embed images inside buttons, lists, etc." (A. Falkenhahn, nov 26th 2018)
As Neil pointed out immediately after, AROS already provided a way to include the images in the buttons:
"came across this snippet at https://muidev.de/ticket/133. External images like those from AISS are to be used like this
"\033I[5:TBIMAGES:list_fold]".
Looking at the Zune sources, it looks like the above would work. Is this a possible work-around?" (N. Cafferkey, nov 28th)
This was, to me, a damn good suggestion, since it gave me the mandatory hint to learn how to include image buttons in my LUA-based scripts. That's exactly how I could create my (still orphan) volume slider and the GUI selector at Icaros startup. However, it was not the same for RapaGUI and MUI Royale:
"I'm afraid that isn't a feasible workaround because Hollywood uses image data directly from memory pixel data so using \330I would require Hollywood to save the pixel data to a file first which is of course very very cumbersome." (A. Falkenhahn, dec 3rd)
On the same day, Paul Bloedel sent me a customized version of Icon Editor with text buttons instead of icon ones, so I could add it to Icaros Desktop 2.2.5:
But the story does not end here. In the following days, Neil worked on Zune to add the missing method.
"I've now implemented \33A for ABIv1, and hope to have it backported to ABIv0 in a few days.
I wouldn't say it was "very simple" to do however :-) It took quite a few hours, although that included writing code to generate a test image, and comparing results with MUI." (N. Cafferkey, dec 21st)
The follwing day, Neil sent me a very nice Christmas present: an updated version of muimaster.library that supported \033A on AROS i386 ABIv0. One of the missing pieces was in my hands. But there was still a little problem:
"Hi, looking at the code, I can see that RapaGUI enables ESC-A support if MUIMasterBase -> lib_Version >= 20 which corresponds to MUI >= 3.9.
I can adapt this for AROS if needed but you'd have to tell me the minimum version of muimaster.library required for ESC-A support on AROS..." (A. Falkenhahn, dec 27th 2018)
Unluckily, there are many several V20 attributes still missing in our muimaster.library, so Neil prefered the safest solution to keep V19 for now, and gave the following suggestion. If you are writing an application for AmigaOS and/or AROS, please write it down and keep it somewhere:
"You can test for ESC-A suport in AROS in C with:
if (MUIMasterBase->lib_Version >= 20 || MUIMasterBase->lib_Version == 19 &&
MUIMasterBase->lib_Revision >= 52)" (N. Cafferkey, dec 29th)
And, on december 30th, just one day before the end of 2018, I could finally get the other missing piece of the puzzle.
"Ok, so here is an updated version of RapaGUI. Please report back if this is working correctly and then I'll enable ESC-A support for AROS in RapaGUI and MUI Royale." (A. Falkenhahn, dec 30th 2018)
I replaced the old AROS versions of muimaster.library and RapaGUI with the newer ones, started the older version of Icon Editor with graphic buttons and... tah dah...
We finally have Icon Editor working as it should, with proper icon based buttons!
I often asked people to help me with porting and compiling stuff, made tests, sent bug reports and, as like as in this case, kept track of the progress. I have other two similar projects still open, I hope to talk about them in the future. It's part of a distribution mantainer job, but I am not the only one who can act like this. What does this teach to us? That the best way to advance is collaboration. The whole Amiga community should collaborate to make the difference. Have a wonderful 2019!
