[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] menu_popup() ideas
lør, 01,.10.2005 kl. 16.56 +0200, skrev email@example.com:
> Selon Odd Skancke <firstname.lastname@example.org>:
> > Hi list,
> > the enable-value, but was changed to -1 in later revisions.
> According to Atari documentation:
> mn_scroll: The scroll field status of the menu:
> 0: The menu not scroll
> !0: The menu will scroll if the number of menu items exceed
> the menu scroll height. The non-zero value is the object at which scrolling will
> begin. This will allow one to have a menu in which the scrollable region is only
> a part of the whole menu. The value must be a menu item in the menu.
Ah, this is news to me. According to my epxeriences, any positive value
turns scrolling off. Only negative values turn scrolling on. But then
again, I dont have that much experience :) Any apps that use this?
Does this mean that the relative Y coordinate of the item whose number
is given in mn_scroll is to be used as the height of the scroll-box? And
the number is the object number and not the row-count, so to speak? In
anycase, this looks like what I was proposing, so if it is already
existing, does it work in N.AES? Because if it isnt existing or working
properly, I was gonna propose a way for apps to check for these
extentions via appl_getinfo().
And on the subject of appl_getinfo(); The values returned by
appl_getinfo(AES_MENU), are those values or is it a bitmask? Can we use
bit 1 of ap_gout3 to indicate the availability of mn_scroll height
extention? This means that AES implementing the stuggestion here will
yield 3 and not just 1. Anyone know this for sure?
> conclusion that as of now, only a 'scroll' value of -1 should enable
> > scroll when more than 8 entries are present.
> > Now for the extention I want to propose;
> > 1. If ('scroll' == -1), enable scrolling when entries > 8
> Agree if NAES do it we should do it too, this is not incompatible with Atari
> documentation because if refer to this an application should not use it!.
Ok, then this is definitive?
> > 2. If ('scroll' > 1), enable scrolling when
> > entries > ('scroll' < 8 ? 8 : 'scroll')
> Why would you restrict to max 8, application should perhaps prefer 10 or other,
> in fact it should be restrict to max possible scroll item that AES can redraw
> on screen.
If you look closely you will notice the "scroll < 8" :) This means that
you cannot have less than 8 entries in a scroll-list.
> And probably it is possible to have scroll==1 with only 1 object display
Yes, perhaps. But I think this is not possible, as it looks as if aMail
uses a positive value here. And N.AES does not render a scroll-list.
> > 3. If ('scroll' >= 0 && 'scroll' < 2) then disable scroll.
> > This should not break any existing apps, since I think most apps
> > actually use -1 to enable popup, while offering a way to set the number
> > of entries to the app.
> > This implementation is present in XaAES as of next cvs checkin from me,
> > but if there are strong objections I will remove it again. Ideas?
> > Comments?
> My point of view, I never test it at this time, perhaps I'm wrong.
> If I look TOS 4.04 AES code this look something like this.
I dont understand..?