Just unpacking

[Mysha]

That would brings us to the icon manager tool, that can be run without doing more harm than HELP. Any progress?

I am not entirely sure what you meant with icon manager tool but am assuming you are referring to the work that user Miker is doing on his icon tools ?

I'll do an easy one first. (I know: Not the developer way, but I'm a bit too busy for the other parts.) To get icons working, we got PNGs first. To that more parts of icons were added, and more types of graphics. Obviously, having the IFF system, this is easily cobbled together.

For simplicity's sake, for icons the PNGs would be allowed as a stack of images, and anything beyond that be stored in the IFF. That way, everyone would be able the handle the icons, but the content of the IFF would be on a "don't know - don't touch" basis.

Anything more complicated could be handled by more complicated software, as long as they understood the basics: Get images, get IFF; if more than one image, check the IFF to read their purpose. More complicated icon formats: Support them as long as you are able to translate them back to PNG-IFF.

Easy as cake, but later approaches seem to be make a pie of some sort out of it....
Simple approach: Convert entire install to to PNG-IFF. Do whatever you want to do to their images. Do whatever you want to do to their IFFs. Regenerate VerySpecial icons out of them if you must.

That was all that was about, except that I can't find my way around here, much, so I tend to ask rather general questions to see what I catch with it.

[magorium]

Please forgive me Mysha for still not quite understanding what you are referring to. I have been using Amiga OS for so long that it is difficult to imagine someone not knowing/being aware of some of the details.

Traditionally Amiga OS adds supports for icons using the icon format. There has been a couple of iterations of that format to add support for different other formats (newicons, glowicons etc) to compensate for some of the shortcoming that the original icon format had.

AROS adopted the png icon format, basically the OS supports that you place png image into a directory, give it the proper icon filename extension (.info) and the 'desktop' allows you to add icon related properties. You can even merge two png images together to have a separate image for the selected and unselected state.

Miker is working on some tools that f.e. allows you to manipulate (the colours of) icon images, put two images together to create an icon etc. His work can be found on this board at this subforum (see topics: iconsplitter, iconpress and icontoolkit) but he moved his discussions over to arosworld.org here

Other than that the aros archives provide other icon related tools.most notably processicon

So, in light of that I (still) do not fully grasp what you are trying to tell/ask with your post other then what I am able to interpret and that seem to suggest to add yet another icon storage format ?

[AMIGASYSTEM]

@magorium
User Mysha may be referring to the default AROS "Gorilla" Icons that are in the images IFF format

@Mysha
I still don't understand what you write, you could make your requests more simply and concisely !

[Mysha]

Hi,

Please forgive me Mysha for still not quite understanding what you are referring to.

You are forgiven.

Other than that the aros archives provide other icon related tools.most notably processicon

See, I told you somebody should be able to manage icons. I'll have to check that it's for the right blood type, and it's rather Swiss Army knife, instead of a specific tool, but if it matches, it'll get things done.

[Mysha]

... I'll have to check that it's for the right blood type, and it's rather Swiss Army knife, instead of a specific tool, but if it matches, it'll get things done.

Hm, It doesn't seem to be the right blood type, after all.

• So, there was an older ABIv0, 32 bit, no longer supported by AROS.org itself, but possibly still in use for IcAROS. Obviously, leaving that situation behind means once again split in user base. We seem to be quite fond of that.
• Then there's a newer ABIv0, also 32 bit, well if we call the first one  ABIv0.0, then this would be ABIv0.1. That's in personal locations, and it's a moving target.
• Next we get a 64 bit target, let's  call that one ABIv1.0. It's supported on AROS.org. I take it that is a moving target as well, though.
• And then there's ABIv1.1, which is possibly the axrt version, in which case for optimal unusability that one too is a moving target.

Add to that, that I now realised that rather than the "original developers completely seized 32-bit development of AROS",  it should read "original developers completely ceased 32-bit development of AROS", and options are rather limited. Things come down to either ABIv0.0 from IcAROS, which we already know won't work in my case, or recompiling every offering myself since there are no other stable versions to create software releases for.

Well, not tonight; I'm going to bed.

[magorium]

So, there was an older ABIv0, 32 bit, no longer supported by AROS.org itself, but possibly still in use for IcAROS.
Obviously, leaving that situation behind means once again split in user base. We seem to be quite fond of that.

Affirmative on both accounts.

Then there's a newer ABIv0, also 32 bit, well if we call the first one  ABIv0.0, then this would be ABIv0.1. That's in personal locations, and it's a moving target

Strictly technically speaking old ABIv0 (Icaros) and alt_ABIv0, but yes.

Next we get a 64 bit target, let's  call that one ABIv1.0. It's supported on AROS.org. I take it that is a moving target as well, though.

ABIv1 exist for 32-bit, 64-bit, m68k (it always was ABIv1 for m68k since ABIv1 was introduced), arm, ppc etc as listed here.

And then there's ABIv1.1, which is possibly the axrt version, in which case for optimal unusability that one too is a moving target.

It really is referred to as ABIv11 but yes again. See here (master/main branch)

Axrt resides at the same repo but in another branch, here.

Add to that, that I now realised that rather than the "original developers completely seized 32-bit development of AROS",  it should read "original developers completely ceased 32-bit development of AROS",

Indeed, one of my more ... shall we say ... finest moments ? 

and options are rather limited. Things come down to either ABIv0.0 from IcAROS, which we already know won't work in my case, or recompiling every offering myself since there are no other stable versions to create software releases for.

Alt_ABIv0 is as stable as it gets, and the same is true for ABIv11.

Deadwood tries to keep breaking changes to a minimum (I can't even remember the last breaking change). Both ABI's do get constant updates and Axrt is really a moving target (though deadwood did indicate it to be reasonably stable but he might change his opinion for the better good, as it is an experiment after all).

To try and make your head spin even more, updates, fixes and other improvements gets committed back 'n' forth between different repo's and/or branches. See for example this commit history in main AROS Development team repo/branch.

There are at least two distributions that that are based on alt_ABIv0, namely Tiny AROS and AROS One. The only thing I currently do not know is if both distro's also support ABv11 (but the idea/intention is to move forward).

Deadwoods next effort seem to be a 32-bit AROS emulator for 64-bit AROS but you would have to ask him about the details because I have not had the time to get into that particular project

I do not know what exactly you wish to contribute but you could always opt for going the safe side and commit to the original AROS Development Team repository. Changes made in that repo will usually and eventually find their way back to the other ABI('s).

BTW: Don't let the member status fool y'ah, it is just an indicator for the postcount. Thus many questions asked will get you there as well 

[Mysha]

And then there's ABIv1.1, which is possibly the axrt version, in which case for optimal unusability that one too is a moving target.

It really is referred to as ABIv11 but yes again. See here (master/main branch)

Ah, I thought that was a missing dot. OK, the 11th version AROS; we have come along way, apparently.

Add to that, that I now realised that rather than the "original developers completely seized 32-bit development of AROS",  it should read "original developers completely ceased 32-bit development of AROS",

Indeed, one of my more ... shall we say ... finest moments ? 

Oh, you score quite high on the list. (I work in a school.)

and options are rather limited. Things come down to either ABIv0.0 from IcAROS, which we already know won't work in my case, or recompiling every offering myself since there are no other stable versions to create software releases for.

Alt_ABIv0 is as stable as it gets, and the same is true for ABIv11.

That's good to know. That should mean that people can add compiles for other branches to their software distributions.

To try and make your head spin even more, updates, fixes and other improvements gets committed back 'n' forth between different repo's and/or branches.

OK, thus any OS-y corrections will eventually percolate to all relevant versions.
 

I do not know what exactly you wish to contribute but you could always opt for going the safe side and commit to the original AROS Development Team repository. Changes made in that repo will usually and eventually find their way back to the other ABI('s).

No, that's the type of fine moment I tend to do; I shift the viewpoint without warning the reader. The software development  I was referring to above, is the type done by other developers. If there are no stable branches, we have to tell everyone to let their users compile it themselves. If their is a limited number of stable branches, we can invite those developers to distribute pre-compiled versions for those. (Apparently, at the moment we could do so; but I don't know if we have the contacts.)

That's also why I said /I/ would have to compile it myself if I was on a different branch from the one in The AROS Archives. (I'll probably start anew, after work today, but I'll probably need recompiling anyway.) But where changes are concerned: There usually are improvements to be made in any program; but I guess here I'd prefer to let the Uploader/Author know.

[magorium]

Ah, I thought that was a missing dot. OK, the 11th version AROS; we have come along way, apparently.

Tbh I do not know if secretly/internally it actually does stand for 1.1 but when deadwood named it I seem to remember that it was done to make it more distinct to the other ABI's. 11 sounds more impressive than 1.1... perhaps depending on your point of view.

Oh, you score quite high on the list. (I work in a school.)

I take any compliment I can get 

OK, thus any OS-y corrections will eventually percolate to all relevant versions.

Corrections, yes for sure. When it comes to new features than that is dependent on the viewpoint of the maintainer(s).
 

No, that's the type of fine moment I tend to do; I shift the viewpoint without warning the reader.

As is your prerogative 

The software development  I was referring to above, is the type done by other developers. If there are no stable branches, we have to tell everyone to let their users compile it themselves. If their is a limited number of stable branches, we can invite those developers to distribute pre-compiled versions for those. (Apparently, at the moment we could do so; but I don't know if we have the contacts.)

As far as my understanding goes atm there are developers that get asked to compile software for a distro maintainer or to bring software to AROS (bars'n'pipes is an example of that) so that things get ported and can be added to such distro. What happens after that, I have no idea and might depend on the agreement between distro maintainer and porter. It is different for each individual situation.

AROS does have the contrib repositories that are maintained but which software ends up exactly were is a bit unclear to me atm so you are not wrong there..

That's also why I said /I/ would have to compile it myself if I was on a different branch from the one in The AROS Archives. (I'll probably start anew, after work today, but I'll probably need recompiling anyway.)

Yes, unfortunately. Though depending on the chosen branch/distro you might be in luck if someone already did it for you.

On a sidenote, and if I recall correctly (old) ABIv0 software (fe. from the AROS archives) should be able to run on alt_ABIv0 but afaik it is not guaranteed to work. On that same note, alt_ABIv1 compiled software should be incompatible with old ABIv0.

I certainly have been out of the loop for too long....

But where changes are concerned: There usually are improvements to be made in any program; but I guess here I'd prefer to let the Uploader/Author know.

I do not know if there is a recommended way nor what (if any) path should be taken there.

For sure, and as you already concluded, it is a fine mess and almost incomprehensible to understand.