Fabien Costantini wrote: >>>> Actually, I vote to drop QuickDraw support entirely. That interface >>>> (QuickDraw) is slower and buggier than Quartz, and is deprecated in >>>> 10.5. >>> =20 >>> +1 >>> It would be great, then we could concentrate on furthering a=20 >>> better quartz support. >>> As I started to do that, I noticed QD was broken when=20 >>> checking about the compatibility in QD of one function addon. >>> It slows down the global process on the mac platform. >>> BTW, Cairo does not provide support to QD and it will avoid=20 >>> questions/problems to remove it in FLTK too. >> Yes, I think dropping the QD support is probably our best option. >> >> However, to that end we need to sort out the hooks into the Quartz layer >> - there are some bits of QD used to get our Quartz support working.=20 > IMHO, what is important to decide now is if we still continue > to support QD. > If no, as apparently many of us think, then we are not in a hurry to remove > "mixed" QD/Quartz code. > > But if it's ok, I would certainly rapidly change the documentation and remove > the disable-quartz possibility so that new 1.3 users won't ask if it is still > supported. > > For me, the most important thing to do first is disabling this option if we > agree.
+0.5 from me for dropping QuickDraw support. +1 because it's deprecated with newer MacOS versions, as Mike wrote, but +/- 0 because I don't (yet) support Mac at all. The first version will be OSX 10.5 with FLTK 1.3 (at least I think so now), and that would be okay for me. But maybe this doesn't count ;-) Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
