Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!stanford.edu!neon.Stanford.EDU!flamingo.Stanford.EDU!espie From: espie@flamingo.Stanford.EDU (Marc Espie) Newsgroups: comp.sys.amiga.programmer Subject: Re: 2.0 Compatibility Message-ID: <1991May1.213904.338@neon.Stanford.EDU> Date: 1 May 91 21:39:04 GMT References: <4766@orbit.cts.com> Sender: news@neon.Stanford.EDU (USENET News System) Organization: LIENS, ENS, 45 rue d'Ulm, Paris (France) Lines: 129 In article <4766@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: [parts of a nice discussion deleted to save space] >Yeah, well commodore itself is hard at work for a FULLY documented interface, >they've had general rules for years, but they're trying to iron out the >loopholes. the big problem is still with european programmers not having >access or not being able to afford proper documentation. The mac doesn't have >this problem since it's Euro sales are about Nil: :) Commodore is also at >work on a Device Independant Graphics device.. great things take time.. > >> >>It sure looks safe to simply write CLI based applications, because they >>won't break as easily, but these kinds of programs aren't any better than >>a Unix or MS-DOS or MPW program (to a large extent). The Amiga has a >>decent GUI in Intuition, but even its use doesn't appear as if it is going >>to keep applications compatible for a long time to come... One of the >>first things I noticed about 2.0 is that when I run CygnusEd in a workbench >>window, the pull-down menus no longer line up correctly (thanks to 2.0's >>ability to allow me to change the default screen font). > >well, again, many of the inconsistancies you see are because of people takeing >advantage of undocumented bugs (some call features) which disapear in bug >fixes. also, it's long been known that the default fonts can and probably >will change, so that ASDG's problem. Warning! Gripe alert. > >> >>This is not a lament, but a objective view of what looks like is going on. >>It would be ideal to be able to rely on the OS for future compatibility, >>but there are going to be a zillion gotchas that we are going to have to >>deal with from now on (for each new hardware and OS platform). The Amiga >>is becoming like the Mac in that when the hardware/software changes, those >>who get the improvements will have to upgrade their software to gain full >>compatibility. > >Well, it's not too objective IMHO. you are reacting to hype generated by >people that don't take time to ask the proper questions (MB?). sure, alot of >software won't work under 2.0, but these are because the developers chose to >take shortcuts rather than be thorough. Commodore has long warned about 99% >of all the problems people are encountering now. Apple on the other hand hs >consistantly changed it's specs. it says do it this way or die.. so you do it >that way, then apple says, no we didn't mean THAT way.. do it this way now. >(we have always been at war with etc... etc.. etc..., etc.. has always benn >our ally.. very representitive of orwellian theories) Apple makes mistakes >then tries to pawn them off on developers, commodore had the forethough to >warn people of 99% of the compatibility problems, people just chose to ignore >them. :-). Go on banging on Apple, I like that. >.--------------------------------------------------------------------------. >| UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | >| ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | >| INET: chucks@pnet51.orb.mn.org | you really think he's | >|-------------------------------------------------| moved back in?" | >| Amiga programmer at large, employment options | Lou Diamond Philips in | >| welcome, inquire within. | "The First Power". | >`--------------------------------------------------------------------------' About that font change problem, I think this is THE biggest loophole in specs. HOW WHERE PROGRAMMERS SUPPOSED TO DEDUCE FROM THE ROM KERNEL MANUAL THAT THERE WOULD BE *TWO* DISTINCT SYSTEM FONTS ? Myself, not being a professionnal developper, and having the RKM1.3, was having a hard time figuring that out. Knowing you can rely on preferences fonts is rather elusive, where do you find the font information ? For people wanting to make software run under 2.0, here are the steps I know of. - the easiest way is probably to specify the ``default'' topaz.80 in every possible field. - if you want to have a nice looking application, it is much better to deal with the default fonts. There are two such fonts, a system font, and a screen font. The system font is to be found in GfxBase->DefaultFont, the screen font is to be found in the screen you want to open: screen->Font. One bad thing about these is that one speaks graphics (struct TextFont), and the other one speaks intuition (struct TextAttr). ok, you can also find the screen font attributes in the screen rastport. Other interesting detail, the screen font is not necessarily fixed-width, the system font is... To get to that screen (for instance workbench), you can either open a window in it, or lock IBase and look for it... the big problem is, if you don't have a window opened, preferences is free to change its fonts... so you had better get to it with a probe window (LockPubScreen is of course another solution, which doesn't run under 1.3). (side-question to 2.0 developpers: is there a way to get notified when preferences wants to change its fonts, so that you can do as the workbench, close all your windows, wait for font change, and reopen them ?) ...So, some time later, you manage to get the height of the two fonts you will have to play with. Where are they used ? - menus use the screen font by default. - unless you setfont in the window rastport, the Text and IntuiText function use the system font. - any text specified in Gadgets and stuff like that uses the screen font !!! I would have expected the system font, but... live and learn. With that in mind, you can get nice looking text at the right size. Other compatibility problems: window borders and window title. The simplest way I've found around this one is the following (since GZZ windows are inefficient): - open a window as though it had no borders. - adjust all your gadget and display stuff to the window border. - resize the window, simply: Size(window, window->BorderRight + window->BorderLeft, window->BorderTop + window->BorderBottom); (for more dynamic sizing, you can compute open the window with say, xstart and ystart as a size, compute the size you need (borders not included), say xmax, ymax, and Size(w, w->BorderRight + window->BorderLeft + xmax - xstart, ...). Another compatibility issue: colors. Use variables for the ``constant'' BLACK and WHITE pen numbers (instead of hard-coding 1 and 2). If your IntuitionBase version is greater or equal to 36 (not 37... commercial 3000 have 2.02, which is 36.something), swap them. Of course, this kind of stunt needs to be tested on a 2.0 system... find a friend who has one. A last thing that can be done: use the arp.library. When 2.0 is finally available to everybody, most of your arp stuff will need only minimal changes to run under 2.0. As an example, my Lattice C includes for the file requester give a structure which is a carbon copy of the arp one, and incredibly similar calling sequences (in fact, using the arp autodocs, you can just figure out many new calls of 2.0). Of course, this kind of thing is only a stopgap measure, 2.0 availability for everybody would be much better. But with some extra-effort, much stuff, can run under 1.3 and 2.0. -- Marc (espie@flamingo.stanford.edu)