* Private intuitionbase variables have moved/changed. reading them is
illegal. Writing them is both illegal and dangerous.
* Poking intuitionbase maxmouse variables is now a no-op, but stop
poking when Intuition version is >35.
* If you are opening on the Workbench screen, be prepared to handle
larger screens, new modes, new fonts, and overscan. Also see
"fonts" compatibility information.
* Screen TopEdge and LeftEdge may be negative.
* Left-Amiga-Select is used for dragging large screens. Do not use
left-Amiga-key combinations for application command keys. The
left-Amiga key is reserved for system use.
* For compatibility reasons, getscreendata() lies if the workbench
screen is a mode only available after 1.3. It will try to return the
most sensible mode that old openscreen() can open. this was
necessary to prevent problems in applications that cloned the
Workbench screen. To properly handle new modes, see lockpubscreen(),
getvpmodeid(), and the sa_displayid tag for openscreentags().
* Using combined RAWKEY and VANILLAKEY now gives vanillakey messages
for regular keys, and rawkey messages for special keys (fkeys, help,
etc.)
* Moving a simple_refresh window does not necessarily cause a
refreshwindow event because layers now preserves all the bits it can.
* Sizing a simple_refresh window will not clear it.
* menuverify/reqverify/sizeverify can time out if you take too long to
replymsg().
* Menu-key equivalents are ignored while string gadgets are active.
* You can't type control characters into string gadgets by default.
Use Ctrl-Amiga-char to type them in or use IControl Prefs to change
the default behavior.
* Width and Height parameters of autorequest() are ignored.
* New default colors, new gadget images.
* JAM1 rendering/text in border may be invisible gadgets over default
colors.
* The cursor for string gadgets can no longer reside outside the
cleared container area. If your gadget is 32 pixels wide, with
maxchars of 4, all 32 pixels will be cleared, instead of just 24, as
was true in 1.3.
* Applications and requesters that fail to specify desired fonts will
get the fonts the user sets up in Font Preferences in Release 2.
These could be much larger, or proportional in some cases. Screen
and window titlebars (and their gadgets) will be taller when
accommodating a larger font. Applications which open on the
Workbench screen must adapt to variable size titlebars. Any
application which accepts system defaults for its screen, window,
menu, Text or intuitext fonts must adapt to different fonts and
titlebar sizes. String gadgets whose height is too small for a font
will revert to a smaller ROM font. There are now 2 different
user-specifiable default system fonts which affect different
Intuition features. This can lead to mismatches in mixed gadgets and
text. See the "intuition screens" chapter.
* Don't modify gadgets directly without first removing them from the
gadget list, unless you are using a system function designed for that
purpose, such as newmodifyprop() or setgadgetattrs().
* Don't rely on newmodifyprop() to fully refresh your prop gadget after
you've changed values in the structure. NewModifyProp() will only
correctly refresh changes which were passed to it as parameters. Use
remove/add/refreshglist() for other kinds of changes.
* Custom screens must be of type CUSTOMSCREEN or PUBLICSCREEN. Other
types are illegal. One application opens its screen with
newscreen.type = 0 (instead of customscreen, 0x0f). then, when it
opens its windows, it specifies newwindow.type of 0 and
NewWindow.Screen of NULL, instead of Type = customscreen and
Screen = (their screen). That happened to work before, but no longer.
* Referencing intuimessage->iaddress as a gadget pointer on non-gadget
IDCMP messages, or as a window pointer (rather than looking at the
proper field intuimessage->idcmpwindow) may now cause enforcer hits
or crashes. The IAddress field always used to contain a pointer of
some type even for IDCMP events for which no IAddress value is
documented. Now, for some IDCMP events, IAddress may contain a
non-address, possibly an odd value that would crash a 68000 based
system).
* Using Intuition flags in the wrong structure fields (for example,
using ACTIVEWINDOW instead of ACTIVATE). To alleviate this problem,
2.0 has introduced new synonyms that are less confusing than the old
ones. For example, idcmp_activewindow and wflg_activate. this
particular example of confusion (there are several) was the nastiest,
since IDCMP_ACTIVEWINDOW, when stuffed into NewWindow.Flags,
corresponds numerically to wflg_nw_extended, which informs intuition
that the newwindow structure is immediately followed by a tagitem,
list which isn't there! Intuition does some validation on the
tag-list pointer, in order to partially compensate. To make your
compiler use the new synonyms only, add this line to your code before
Intuition include files: #define INTUI_V36_NAMES_ONLY.
* Do not place spaces into the stringinfo->buffer of a gact_longint
string gadget. Under 1.3, this worked, but the 2.0 validation routine
that checks for illegal keystrokes looks at the contents for illegal
(i.e., non-numeric) characters, and if any are found assumes that the
user typed an illegal keystroke. The user's only options may be
shift-delete or Amiga-X. Use the correct justification instead.
* If you specify NULL for a font in an intuitext, don't assume you'll
get Topaz 8. Either explicitly supply the font you you need or be
prepared to size accordingly. Otherwise, your rendering will be
wrong, and the user will have to reset his Preferences just to make
your software work right.
* Window borders are now drawn in the screen's DetailPen and BlockPen
rather than the Window's pens. For best appearance, you should pass
an sa_pens array to openscreen(). this can be done in a backwards
compatible manner with the extnewscreen structure and the ns_extended
flag.
* The system now renders into the full width of window borders,
although the widths themselves are unchanged. Window borders are
filled upon activation and inactivation.
* Window border rendering has changed significantly for 2.0. Note that
the border dimensions are unchanged from 1.x (Look at
window->borderleft/top/right/bottom if you don't believe us!). if
your gadget intersects the border area, although it may have looked
OK under 1.3, a visual conflict may occur under 2.0. If Intuition
notices a gadget which is substantially in the border but not
declared as such, it treats it as though it were (this is called
"bordersniffing"). Never rely on Intuition to sniff these out for
you; always declare them explicitly (see the Gadget Activation flags
gact_rightborder, etc.). see "intuition gadgets and window borders"
in the "Additional Information" section below.