Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!uunet!overload!dillon From: dillon@overload.Berkeley.CA.US (Matthew Dillon) Newsgroups: comp.sys.amiga.programmer Subject: Re: 2.0 Compatibility Message-ID: Date: 2 May 91 20:42:46 GMT References: <4766@orbit.cts.com> <1991May1.213904.338@neon.Stanford.EDU> Organization: Not an Organization Lines: 100 In article <1991May1.213904.338@neon.Stanford.EDU> espie@flamingo.Stanford.EDU (Marc Espie) writes: >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] >>warn people of 99% of the compatibility problems, people just chose to ignore >>them. >:-). Go on banging on Apple, I like that. :-) >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 ? Commodore has specifically mentioned the fact that if you WANT topaz 8 you should SPECIFY it as your TextFont instead of putting a NULL there to get the system default font. Either that or properly compute your rendering based on nominal text size. Those people who followed the rule will get topaz 8 under 2.0. Those people have not followed that rule will get the system default font which is no longer necessarily topaz 8. Now, obviously, the *user* wants said program to use their selected fonts, but if the program break's with a non 8 font then it's an ok hack. I've personally heard this at least 3-4 times over the last several years and believe it's even in the documentation somewhere. Of course, , I'd not paid too much attention to it until I started developing under 2.0, but it turned out to be pretty easy to upgrade the source code to handle variable fonts. >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. >... >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). LockPubScreen() is the best way. It's actually easier to simply check the library version of either EXEC or DOS in a conditional and USE the 2.0 calls when the program is running under 2.0 (if you are developing an application that works under both). That way you can easily delete the 1.3 code in a year. >(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 ?) Not yet that I know of. >... >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) In terms of ARP, I would *STRONGLY* suggest that people with ARP do not overwrite the 2.0 C: commands. Instead, rename your ARP commands. In fact, for the most part you may decide to throw them away entirely since the 2.0 C: command executables are tiny. If you *replace* your 2.0 C: commands with ARP commands you are guarenteed to BREAK a lot of programs you try to run, causing a lot of hassle for yourself. I for one have grown tired of all the 'bug' reports I get that turn out to be problems with ARP and I don't want to see it all get transfered to 2.0. -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA