Hyperion Entertainment Message Boards

Hello,

Simple short one here, I would like to see it possible for developers to insert (AISS) icons into all menus, those at the top of the screen and the pop-up variety too.

Edit: This is unrelated to the previous locked thread which was in related to a user running into problems with a Beta version of the OS. I can only comment and feature request against the current publically available version of the OS which does not allow this/has not been implemented.

djrikki wrote:Hello,

Simple short one here, I would like to see it possible for developers to insert (AISS) icons into all menus, those at the top of the screen and the pop-up variety too.

Edit: This is unrelated to the previous locked thread which was in related to a user running into problems with a Beta version of the OS. I can only comment and feature request against the current publically available version of the OS which does not allow this/has not been implemented.

I have no idea what thread you are referring to, but this is already possible in context (pop-up) menus, and ought to be possible in Intuition (pull-down) menus but the functionality is broken in the public version* (but fixed in beta).

* actually it appears to have been broken since at least OS3.1

I remember that thread (might be deleted since it was a beta feature that sneaked in) and iirc this will be some of the 4.2 functionality for both intuition and context menues.

I may be completely wrong though

Back when I was using my brother's Amiga 4000 - that was about in 2001 - I was tinkering with user interface ideas - and other things.
I had written some new classes that together provided a new style of menu representation for the Classic Amiga utilising BOOPSI.

Just one of the features my new style of menus provided was the addition of icons which could be placed to the left of text of the menu item.
Is this the sort of feature you are requesting?

I just received my X1000 last Wednesday. So I will be pleased to be able to look at my code under the spotlight of the latest version of the OS now

As I mentioned the icons were just one feature.
I was also adding backgrounds, multi-qualifier support, automatic menu adjustment (ie for font resizing), wrap around menus, automatic placement.
As part of the process I was also removing limitations such as the maximum number of menus, items, and sub-items or that bars chewed up a menu item.
I was also working on a menu editor (a new preference program) to allow people to re-organise items as they desired (including overloading of items).

UI design is very important to me. I want to be able to add icons and other things while retaining that nice Amiga-ness about them.
One of the usual effects of designing something like the above is to start adding in idiosyncrasies and stylisation artifacts.
You can usually tell under what model - MUI, reaction, etc. - a program is implemented because it carries certain characteristics along with it.

I've tended to follow a regime of dumber is better. Always when I've created objects I've tended to break them up into their smallest functional constituents.
An example of this is a lister. I wrote a listerclass that contains not a single instance of graphical rendering.
What I felt was important was to be able to represent the lister behaviour in a generalised fashion without tying it to any graphical representation.

Anyone who has written a graphical lister will most probably have directly coded the lister and graphical functionality together along with a particular 'feel'.
Back when I was writing my objects I was amazed out how many ways that listers where being implemented.
The way you used a lister in one program was completely different to another program.

Having common lister provision - such as through MUI - has been a useful thing as you get used to a common feel.
However, as I say, once you start utilising MUI you are fairly locked into adopting all its stylisation.

I felt it was better to attempt to write a lister object that did nothing but handle lister operations without drawing anything.
I don't have enough experience with other systems to know if something similar has already been done so please let me know if there has been?

The good thing about generalising the lister is that you don't have to think about how a lister works when you create one.
You don't have to worry about things like optional multi-item support, range selection, plus other things that I don't immediately recall.
You can then also apply it ways that you might not expect...

Things like the time region selector in preferences could be written on top of this lister. It has selectable items that are graphical and non-evenly spaced.
You could make a directory with icons that can be moved about and snapshot as well. Like what we see in the Workbench itself.

I haven't done any of those things.
What I have done is use it to create my lister in my menu editor from it with a WYSIWYG look and feel. With a whole lot of other code of course.
It looks quite nice editing a menu and seeing exactly how it will look - though this was still in it's preliminary state when my brother's A4000 died back then

I've worked on the code, just a little, using Amiga Forever but I have always wanted to see how it would go under the latest version of the OS.
I'm sure I will need to learn a few new things...
I am curious to see if a particular bug I discovered in OS3.9 is still with us in OS4.1 or not when I try to convert my code over.
The particular bug had to do with Intuition and it's menu handling.
I'll have to check again but it either had to do with check mark selection or just selection in general.
Either OS3.9 would draw the check marked image before changing the checked flag or it would draw the selected/unselected image before changing the selected state?
I'll check my code. I should have left a note in there to see which it was...
I had to write a work-a-round which I hopefully don't have to do under OS4.1?

So I hope this is the sort of feature you were talking about djrikki?

After such an interesting read I am ashamed to reply with a simple Yes, but there you go.

Yes, Icons in Menus (and elsewhere) would be fantastic, but I am asking at an OS-level, what we don't need is another toolkit or library, but features that come as-standard as opposed to being bolted on through third-party efforts which is very common in the Amiga-world.

djrikki wrote:Yes, Icons in Menus (and elsewhere) would be fantastic, but I am asking at an OS-level, what we don't need is another toolkit or library, but features that come as-standard as opposed to being bolted on through third-party efforts which is very common in the Amiga-world.

And I will repeat: it's already supported. It happens to be broken in most versions of gadtools.library, but has been fixed recently, and does exist.
For popup/context menus (popupmenu.class) it is present and working.

@Chris

Cool that is great to hear. I look forward to seeing that. At the moment I'm sharing one monitor between two computers. I've decided upon a monitor that I want to get (Viewsonic VX2370Smh-LED) but they don't appear to be available in Australia yet. So I haven't really set myself up properly yet. I imagine that the following features aren't supported:

- multiple qualifier support (eg. Alt L-Ctrl A, etc) and customisable qualifier icons
- menu item order customisation (including combining commands into single items eg Bold + Italic, etc.)
- menu look customisation (backgrounds, frames, selection)

@DJRikki

I agree that it needs to be incorporated at the OS level and I eventually would like to see that happen.
I don't want to impose another look-n-feel - especially being what I decide.
Key elements of the design were to make things customisable. Amiga is the king of customisation and I would like to see that grow.

I would like to offload the code actually as I have other things to work on. However, I will have to work out what I was doing as I have had gaps in looking at it.
The problem with having 'dumb' objects is that you end up with so many of them. I do believe ultimately this makes things more compact and faster.

If it is permissable I would like to use this thread to re-examine the principles behind the code and the code itself?
Over time hopefully some people will see the approach and it can move forward...

For example I found menu layout to be an interesting area to bring an Amiga-ness to.
As far as I'm aware, ours are the only menus that indent a menu item for the checkmark. Does anyone know anyone else who has this?
I love this and I think it is great and love the look of it.
All the other OSes seem to have the checkmarks in-line with the other icons. Yuck! So for checkmark items you can't show its own icon!

I implemented mine so that you can have icons for the checkmarked items as well and that they indent the text after the icon for their space.
Also, other OSes tend to implement multiple qualifiers but these occupy their own column as well.
All very organised but you end up with a lot of unsightly spacing.
I implemented mine so that these overlap the menu text - when they are long - but in such a way as everything still looks nicely lined up.

Even though its probably not necessary, I didn't want to prescribe what a menu item should look like.
So again, I've separated the menu and menuitem objects from their actual graphical contents.
Instead they utilise a layout pointer to ask the style of menu item used to assist in laying themselves out nicely.
Layout should and only occurs when changes are made to a menu.
So as for the listerclass, menuitems don't actually have drawing code inbuilt. The menuitems instead focus on menuitem behaviour.

Some of the other aspects of the approach are the addition of a menuport.
Normally Amiga programs process menus by being told a menu/item/subitem number.
But if you have customisable items that becomes less than useful.
So instead the approach is to have app specific requests sent to the program instead of a number.
This was actually the most recent thing - still awhile ago - that I was working on for menu system.

I think it would be nice if the Amiga were the first system with a Menu Preference. As I say, it is the King of Preferences.
Which goes to another aspect in how I wanted to develop it...
Usually Preferences are system wide. I wanted to make my Menu Preference both for system wide aspects and application specific aspects.
You obviously don't want to have the same menu items in every application.
You might want to set a general look and feel for most of your apps but again with some individualism (ie. for games) to give them a more thematic look.
So in this respect the menu preferences was to double as both a 'Pref' in the menu drawer and a requester (like a file requester) for applications to use.

I should probably move this over to the "general developer support" area at some stage - or even perhaps "off topic" - as this isn't really a feature request; even if it relates to requested features. I would like to re-examine this code so hopefully that will be acceptable on this forum?

During my Amiga Forever days I had the opportunity to have discussions with Thomas Richter - a great find; and very knowledgeable about Amiga programming issues.

One of the interesting things to come out of our discussions was that the ClickToFront commodity can try to access invalid Windows.
The problem is that Intuition can close a window while ClickToFront has obtained the window's pointer.
There is no way for ClickToFront to lock a window from closing in an acceptable fashion.
It is rare that this can cause a problem but it can... I wonder if that has been able to be fixed?

I developed some new classes to make sure my code would work. These are zoneclass and moveclass and I wrote a commodity called mousezone.
As a feature they added zone locking so that zones would remain valid while they were being examined in the "watcher" chain.
The "watcher" chain is something I added to simplify graphics object location.
If you have ClickToFront, Intuition, and other programs all going up and down the Screen, window, gadget tree it creates effort repetition which slows things down.

So I wonder if these things can fit into the OS4 plan? Or is there already a solution in place?
Has some sort of a common way of handling zones already found its way into OS4?
If not I would certainly like to incorporate what I have done into the OS.
Whether that is done as is or some of it added directly into the Intuition code (eg "watching")?

gonegahgah wrote:So I wonder if these things can fit into the OS4 plan? Or is there already a solution in place?
Has some sort of a common way of handling zones already found its way into OS4?
If not I would certainly like to incorporate what I have done into the OS.
Whether that is done as is or some of it added directly into the Intuition code (eg "watching")?

We should talk...

Email sent.

Thanks SSolie, I would enjoy that.

Continuing my recollections...

I created a few different BOOPSI classes using my zone code including one called pointer.zone.
The purpose of pointer.zone is to display a different pointer image when the pointer is over that zone.

This is one where I realised that more intimate association with Intuition would be useful...

I wrote a little test program and moved my pointer over the little zone gadget.
And just like magic the pointer would become an alternate image whenever I moved it over the zone. Great!

However, at some point, I clicked elsewhere in Workbench and then moved the pointer over my zone.
But, the pointer remained its old self... No change at all!

It dawned on me to realise - doh - that the pointer imagery is tied to the current active window.
So if the window is inactive; you can change it's pointer all day long and nothing is going to be seen...

So I'm thinking, for it to work how I was hoping, Intuition will need to become a little zone aware and allow a system wide pointer imagery to be set when a zone is present; overriding classic behaviour.
When a zone isn't present then classic behaviour would default.

I think it would be simple enough to add this feature but the question would be: is the slight change wanted?

For myself, when I move a pointer over a zone, I would like the pointer to reflect that zone's purpose; even when it's Window is not active. Does anyone agree or feel otherwise?
I feel the same would be the case for things like wheel scroll zones (not something I had implemented back then).

My zoneclass code - all this is from recollection - handles zone 'hits' in a similar fashion to BOOPSI gadgets handling mouse 'hits' - without the need of a mouse click though. So you can utilise odd any shaped zones like you can have any shape gadgets.

Something else that was useful for me - and in relation to this - was that I created a way to have multiple inheritance in Amiga BOOPSI. My zoneclass is a base class - as is the existing gadgetclass - so if you want to meld a zone with a gadget then multiple inheritance is the simple way.

The reason I wanted to meld gadgetclass and zoneclass is that not all zones are gadgets and not all gadgets are zones.
So making gadgetclass the base class of zoneclass would be superfluous and wasteful.

I called this additional process class adaption.
The zoneclass is not just about its methods. At its heart it utilises static memory to allow the zone locking to occur - if I recall things correctly. I will need to re-examine my code to re-discover what I was doing...

All these zone related things were actually fairly easy to write - if I recall - and I hope they prove worthwhile...