> Scott Gilbertson wrote: > > Do you suppose we should have a pure java subclass of ClasspathToolkit (from > > which to subclass XToolkit), or do I need to go ahead and get XToolkit to > > work as a subclass of ClasspathToolkit?
to which Graydon Hoare replied: > hmm. tricky. the obvious ways forward that I can see for you are: > > - make a ClasspathFontPeer with a special subclass name, which your > toolkit generates and your Graphics object recognizes, which only > supports the pre-1.4 semantics (which is broadly compatible with > the view of fonts available to xlib), and explodes when the user > tries to call any fancy new stuff. this would mostly be an > API-mapping task, with a bunch of cases that map to "throw ...". >... Thanks for the suggestions. I guess the one reproduced above is the simplest way to go. I roughed something in today along those lines, but it just crashes in a different place now (in the font metrics cache). I'll have to revert to the previous gcj/libjava code for a while, until I can schedule a day or so to make a working implementation (next week I hope). In the meantime nobody's beating down my door for xlib peer updates, and my embedded app was working fine on the older code. _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
