How big or small is the NATAMI team at the moment?

Cheers.

If I'm right we are 18.

I don't think Natami will be out tomorrow so I don't think there is a real immediate rush though I know it might be nice to have an easier menu paradigm available sooner for everyone to consider and include.  Would save them a lot of work on this aspect of their software and give them features they would not have otherwise included.

At the moment I'm working on writing a universal parser which is more important to my main project.  So I will get back to the menu system soon hopefully but it is lower priority at the moment.

I apologise but the parser is important.

I think the thread has served its original purpose so I don't think anyone will mind if we hijack it now.

With respect to how I was talking about implementing the app writers side of things, I think it is important to separate the Menu events from the IDCMP.  One reason is to get around the Intuition menu system limitations.  The other is to allow the menus to be edited independently of the app (like the save requester does) - though saving to where the prefs for that app are.

One of the challenges with this approach of course is that menus are tied to Windows and Windows get an IDCMP and the IDCMP relies on signals, and those signals are got from the process which is tied to your app.  So normally we are reliant on Intuition to manage the menus, and when used, create messages to send to the active windows IDCMP.

The way around that is that the menu system jumps in when the menu item is told to be drawn and it is at this time that the menu system does its trickery and sends any events to the apps new menu message port.

At the same time this provides an opportunity to remove the limitations imposed upon Amiga menus.  Menus need not have a limit on the number of menus, items and subitems as is the present case.  Also the limitations on mutually exclusive items can be removed as well at the same time.

As mentioned the app writer only needs to supply to the menu system the list of contexts and functions it has and what it wants in return if that function is selected.  A little more information needs to be provided about check items, etc.  The app first opens up the menu system obtaining a menu object to talk to and a message port to  wait upon.  When the context changes the app tells the menu object so that the menu system can swap the menu.

That's how it should work.  The app then no longer receives menu events through its IDCMP and instead through the new menu port.  And the app receives function events you've assigned rather than menu position events so that you no longer have to work out what it was that was selected.

For legacy apps the IDCMP would still do its original job but none of the menu system features, such as item editability, would be available of course.  The look & feel of these would be the default one as set by the user in the menu prefs.

One fancy feature that can be added later is localisation.
When an app writer makes up their list of app functions and settables they create a default text id for the function to supply to the menu system.

Initially the menu system will use this to list the function to the user who is using the menu editor.  When the menu system is up and running then it should be relatively easy to tack on the localisation aspect afterwards.  Again the app writer won't have to worry about any programming when it comes to this.  Instead the menu pref can be modified to allow the user to add the different languages for each of the functions and settables.

This is something that can be added later so I will format for it but someone else can do it when the time comes.  All I want to contribute is to get the main heart of the system up and running.

The combines will need a simple way to indicate the possibilities.
I think that this can be done in the menu editor itself.
The 'choices', 'actions', 'toggles' and 'requests' are straight forward.
Adhocs need to be updated by the app as they change.
If anyone can think of anything else then fire away.

I will look to make it so that the user can combine selections too.  For example: 'bold' & 'underline' or 'align centre horizontally' & 'align centre vertically', together if they wish.  Even 'plain' is a combine as it turns off all typestyle formating.

I'm thinking that like the current menu system - that gives you a chain of menu selections - that the selections will be put into your menu port in the message as a chain of selections; so as to not create loads of memory allocations.

There are different ways of presenting choices for the same options.  For example Bold could be presented as: 'Bold On' & 'Bold Off' or just as 'Bold' the last reversing the current status.  Where you have multiple letters selected and some are bold then the usual action is to make all the letters bold.  An alternative action could be to reverse the status on a letter by letter basis.  This 'complement' action is an unusual situation but I think I have seen it in graphics.

Also some of the options that can be set in a program are range values.  Generally these are accessed via an options requester but it may be that the user has preferred values which they would like to have listed in their menu.  For example they may always alternate between size 16 and size 24 fonts so they may actually have these in their menu as 'Font Size 16' & 'Font Size 24' if they wish.

Normally these are so specific that a program would not come with these but it doesn't hurt to allow the user to add them later.

Ad hoc menus can also be the last few selections so it may be that the last few font size choices as an example are held in a little group in the menu somewhere.  Again this would allow the user to quickly select them instead of going into a full blown option requester.

As to keyboard shortcuts in the menu editor you will be able to assign shortcuts to adhoc groups according to their order.  You see this for 'recent documents' where the first may be 'A-1', the second 'A-2', etc.  So you would assign 'A-1' to whatever the first item will be and so on even when their are presently no recent documents.

Shortcut keys aren't always needed.  But the user can add in missing ones later if they use a function a lot.

The menu and the app need to be able to stay in sync in terms of what the current status is.  For example if the cursor is moved the text may no longer be bold so the menus need to know this.  And if bold is selected from the menu the app needs to make the characters bold.  In general they will need some way to share the status.

So far most of my work has concentrated on the editor itself so it is good to begin exploring the app side of things.

That can either be done by following conventions or alternatively by allowing a set of default function shortcuts to be defined in the default menu editor that apps can troll from.  Something worth thinking about.

So make a topic what sort of functions should be a default, and then think what key stroke to assign to that function name it in a list at the end of both the user manual and the programmer manual.

The user can still modify these later if they wish and can add their own menu items and shortcuts.

The Amiga Style Guide Manual already proposes a small set of standard A-key combinations.

I'm making the full range of qualifiers able to be shown in the menus, and not just the A key, so I don't know if we want any standards on those or not.

The shift key quite often represents the opposite action.  I will look to make it so that menu items can be visibly changed when a qualifier is held down so that they reflect the qualified action.  For example 'undo' may change to 'redo' when the shift is held down.  This polyality would be definable in the menu editor.

Hm, if the two amiga keys have a two different scan codes you can make a left and right A difference. ;)

And not every key needs to be a short-cut to something.
I think the current list is a good starting point since a lot of potential users already know those by heart.

The left and right Amiga keys are always treated as different keys from my recollection.  The alt, shift, and ctrl (on PC keyboards) can be treated as synonymous or as the left or right of each distinctly.

So if you truly wanted you could have a shortcut like:
'LAlt Shift LCtrl LAmiga RAlt RCtrl Z'
for the truly masochistic user.
But, an app writer certainly wouldn't offer that as a default.

The good thing about allowing the other qualifiers is that a key can be reused so you can have A-P for 'Print' and Alt-P for 'Plain' for example.

I also allow 'Help', 'A-Help' & 'Shift F1' for example.