My menus are already localized... it sounds like I would have to totally rewrite my menu-related code to work with your new system?

Your menu handling code which would presently work off menu/item/sub numbers would instead work off the function ids or entries that you submit to the menu system via the new initialisation.

You would also have to wait on the menu message port as well as the IDCMP for the other non-menu intuition events.

I expect the coding of menus to be a fairly standard approach with what I am doing instead of all the hard work that you had to do to achieve the menus you were after.

You would remove the localisation code you have done for your menus and instead use the menu editor to add other languages for your menu functions.  You could add the backgrounds you desire.  The visual style of item selection should be changeable also.

The aim is to achieve the sort of things that you are after but with out all the work that you had to go through to achieve it.  The menu editor would do most of the work for you.

So, I would tend to call it a fairly standard reduction and simplification of your code; not a rewrite.  And hopefully the benefits would outweigh the loss of all that original hard work.

but...

(you knew there would be a "but..." :D

My menus are translated, independently, by 20 different ppl each editing a .catalog file for their language.  A lot of these ppl do not have Amigas and have no idea how to use one.

I can currently just give anyone a plain .txt file and let them translate it into their own language.

It sounds like you are saying that I :( would have to copy out the translated strings and put them into the menu editor every time someone made a translation change (this happens a lot).  This would not be good.  Translation work should take place 100% completely autonomously from the main coder.

The text file that third parties provide to you what do you do with that when you receive it?  What does it look like?

The text file that third parties provide to you what do you do with that when you receive it?

Put it in Catalogs/

What does it look like?

A plain text file with ; comments

If someone edits their .catalog file they can then run the game and see/test the results immediately.  They do not need to read instruction manuals, compile anything or send it to me.

My catalogs also have some very fancy features to support 100% multilingual translations.  But that does not apply to simple menu strings.

I can email u.

Did you ever find the checkmark in one of the gfx dirs?

I think that would be the easiest way to do it.
But, we won't be able to determine that until the system is first up and running.

In relation to your addition of changeable strings and values in the language files, I'm wondering if something like that should be considered for the menu system.  I will have to think on that.
eg. 'Cut Circle', 'Cut Objects', 'Cut Selection', etc.
I know Corel Draw changes the 'Undo' and 'Redo' menu items.
eg. 'Undo', 'Undo Create', 'Undo Delete', 'Redo Delete'.

I looked for and found your checkmark on Saturday.
Today I've looked at how to implement it with transparent background.
I have cheated.  I'm not keen to spend time at the moment rediscovering and merging my iff loading code with my class code which will take time and testing.
Instead I have used the bitmap.image class provided with Reaction that comes with the Amiga now.
So I have your amitick checkmarks working in my menus now.
They look even better with transparency working.

If you are happy enough with this I will explain how to add it to your code so that your checkmarks can shine their best.

I don't think I tried the transparent version in the game... donno... my pain killed me :(

Will transparent checkmarks display transparently in standard AmigaOS menus?

Does Reaction depend on the presence of certain datatypes which may or may not exist on the end user's machine?

This one still has the black background.
Either way I think the main difficulty was in using a standard image.
There is no way to get DrawImage() to draw a standard image with a transparent background.
So any standard image checkmark we set will draw its background over the real background.
But a BOOPSI image can draw what it likes.
DrawImage() automatically relies on the BOOPSI image to draw itself.

Reaction does use the datatypes system.
But a straight iff datatype is supplied with all Amigas since 3.5 or maybe earlier?
Seeing your checkmark is an iff file this shouldn't be a problem for anybody.
Or, will it be a problem?  Let me know if it is.

Does that sound like a problem?

I'll show how to use bitmap.image shortly.

2. The thing about OS 3.0 is simply that if I add code that requires some new OS then I have to release a new version in a new archive and advertise it as "REQUIRES OS blah.glah"

I once purely accidentally released a version that required Ixemul.  Man, that was a disaster...

So long,
Thomas

The thing with DrawImage() is that it takes a pointer to an image structure as its source argument.  The image structure makes no allowance for transparency.  There isn't any way to extend the structure either as there are no flags and no place to indicate that the structure is extended.  The only modification that has been made to it is that a depth of 0 means that it is a BOOPSI image.

So DrawImage() will never be able to draw a transparent background except via a BOOPSI image.
So much of the Amiga OS uses DrawImage() so the problem remains.

A BOOPSI image is always based on the image structure but can add whatever other data it needs without hurting anything.

So it really is the only option.

Using Reaction's bitmap.image is only one option.
It can be done instead by creating our own class.

The question is when did Reaction become part of the OS.
I think it only came on board from OS 3.5.
I read that it was OS 3.9 but I'm sure I recall it from OS 3.5?
Again, I'm not sure.

If so we can't use that for your OS 3.0 users.