Thread: [Waba-spec] Re: Waba-spec digest, Vol 1 #120 - 1 msg
Status: Abandoned
Brought to you by:
bornet
From: Sean L. <se...@cs...> - 2001-12-04 16:46:18
|
I'm thinking of also suggesting one additional method to the Vm class: /** Tells the Waba system to be compatible with at most the semantics of the given Waba version */ public static void setCompatibility(int wabaVersion); The idea would be that by setting this method to 10000, certain methods behave differently -- for example, the Font() constructor creates CORRECT font sizes rather than the broken font sizes. And drawRect() would create CORRECT rectangles rather than the broken ones. A simpler version of this method might be: /** Tells Waba to assume the Core Waba specification, else old Waba 1.0 */ public static void setCoreWaba(boolean set); I'm a little weirded out by needing to "set" this value. But I can't think of any way around it and still retaining compatibility with drawRect() while moving forward with a corrected version. Any ideas? To keep apps from having to set this switch themselves, we might define a class like MainWindow2 or WabaWindow or something which is defined as follows: public class MainWindow2 extends MainWindow { public MainWindow2() { super(); waba.sys.Vm.setCoreWaba(true); } } So core waba users would create applications with MainWindow2 or WabaWindow or whatever, rather than MainWindow, and magically certain methods would behave differently. Hopefully, if we did this right, we'd only have to make the modifications once. Sean |