Recent changes to feature-requests

Calendar Needs Resize Method

Ant — Sun, 26 Oct 2008 16:25:28 -0000

No resize() method for calendar gadget yet.

Remove GADGET_CLOSABLE

Ant — Wed, 30 Apr 2008 13:46:01 -0000

The GADGET_CLOSABLE flag only applies to one gadget, so having it as a flag in the base gadget doesn't really make much sense. It would be better if the window included its own enum of custom flags in addition to the basic flags offered by the gadget. This should be sent to the window as a separate parameter.

Flags should be:

- AMIGAWINDOW_SHOW_CLOSE (shows close button if set)
- AMIGAWINDOW_SHOW_DEPTH (shows depth button if set)

Similar idea for the screen class:

- AMIGASCREEN_SHOW_FLIP (shows flip button if set)
- AMIGASCREEN_SHOW_DEPTH (shows depth button if set)

It should also be possible to set these options via usual getters/setters, which should resize any relevant border gadgets as appropriate.

Gadget::remove()

Ant — Thu, 03 Apr 2008 23:33:24 -0000

Create a new Gadget::remove() method that will remove a gadget from the Woopsi hierarchy and hand responsibility for it back to the developer.

Woopsi could expose vbl counter

Anonymous — Sun, 09 Dec 2007 06:53:49 -0000

To implement "double-tap" detection in my List gadget, I had to add a vbl() member to it, to increment a counter so I could distinguish the time between taps.

This seems a bit expensive, since all I did was

bool List::vbl()
{
_vbl++;
return(false);
}

It cost me a member variable (_vbl) and really only adds to the overhead in the system. If Woopsi had a member variable, it could do this 'incrementing' in its vbl() and all the trivial classes could just leech of it. ie,

class Woopsi {
...
protected:
int _vbl;
bool vbl() { _vbl++; return true; }
inline int getVblCount() { return _vbl; }

My List can then just access woopsiApplication->getVblCount() whenever it wants the current value - you should never write to it, and its my problem to deal with wraparound.

Ordinarily, I would say do it yourself, but VBL's are something that you want to keep as short as possible. I understand that the simplest approach was to have all gadgets have one, but I think thats a little extravagant for such a limited resource. It would be better if the constructors for such objects add themselves to a global list, and their destructors remove them. (ie, add a vector to the global Woopsi object of gadgetsThatWantVBL[] that you have to explicitly ask to be put in)

Its also worth asking "why is it a bool function" ? there is no circumstance where me returning false would imply that my brothers should not also get a turn.

Gadget::removeGadget() is protected

Anonymous — Sat, 08 Dec 2007 00:31:27 -0000

I got half-way through writing some code that dynamically creates a new screen (with some stuff on it) only to discover that whilst I can add the gadget to the Woopsi quite easily, I can't *remove* it.

removeGadget() seems like it should be as public as addGadget()

Naming convention of boolean accessors

Jeff Laing — Tue, 04 Dec 2007 02:07:14 -0000

It was confusing looking through Gadget:: and seeing getDecoration() - I thought it actually returned a decoration, which didn't make sense in the context.

I think it might be a good idea for the accessors that return bool to call those methods isXXX instead of getXXX.

ie, getDecoration() becomes isDecoration(), etc.

Screen Flip button needs more thought

Jeff Laing — Mon, 03 Dec 2007 10:24:25 -0000

I'm pushing my app forward a little and the default behaviour of the screen flip button is problematic.

If I want a screen depth button, I have to have the screen flip button as well, but thats not really desirable behavour. The top-screen, which is click-free, shouldn't display the screen title gadgets (since you can't activate them). But if you don't display them, then when you flip that screen down, you can't flip it back up.

The ability to turn on/off the flip and depth buttons seperately seems highly desirable
The ability to change the behaviour of the buttons is highly desirable

At the moment, the screen flip button insists on calling Screen::flipScreens() and there is no way to subclass the button to do something different because its created directly by Screen. The workaround is to subclass Screen and change the flipScreens() method - in fact, that may be the only way to go forward anyway

Do you really need two fonts by default?

Jeff Laing — Mon, 03 Dec 2007 09:47:34 -0000

It seems like Woopsi is somewhat extravagant, requiring two essentially identical font bitmaps.

It might be more efficient to use a single font, which would be possible if the 'glyph' characters were moved from A,B,C,etc down to 0x01, 0x02, etc

It seems relatively unlikely that the 32 available spaces (0-31) will be insufficient for the foreseeable future.

Explicit support for backgrounds might be nice

Jeff Laing — Thu, 22 Nov 2007 09:51:03 -0000

At the moment, a window/screen gets a dull gray background - if you want something more exciting, you need to burn a Gadget to do it.

I think it might be useful to have a strongly supported "background gadget" which should be supported by both Window and Screen. This gadget would be automatically click-dead, etc and would auto-size itself to fit the available "background space" of the enclosing window/screen.

You could also have a single Gadget which was just a ColouredBackground which took one colour and filled its rectangle with it.

You could also have a new Gadget called a 'Gradient' which took two colors and just extrapolated from one to the other down the screen. No need for any backing storage, just draw horizontal lines, adjusting the colors as you go.

(Obviously, you could do these with existing Gadgets - but its nicer if the framework does it for you :)

Top-screen coordinate confusion

Jeff Laing — Mon, 12 Nov 2007 23:04:30 -0000

It seems to me that the TOP_SCREEN_Y_OFFSET constant is not an optimal value.

It is currently set to 384 which is 2*192, double the height of a DS screen, but since you can't draw off-screen anyway, it seems like using 192 would have been fine. There may be a subtlety I'm missing.

Nevertheless, if you used 512 instead of 384, then a number of other 'commonly called' routines could be a bit faster.

u8 Gadget::calculatePhysicalScreenNumber(s16 y) {
if (y & 512) return 1;
return 0;
}
s16 Gadget::calculatePhysicalScreenY(s16 y) {
if (y & 512) {
return y - 512;
}
return y;
}

or even better

u8 Gadget::calculatePhysicalScreenNumber(s16 y) {
return (y>>9) & 1;
}

u8 Gadget::calculatePhysicalScreenY(s16 y) {
return (y & 0x1FF);
}

These don't work for negative y but I don't think Woopsi allows negative coordinates here (at this level - these are hardware coords being discussed)