On Mon, 2009-01-26 at 20:42 -0500, DJ Delorie wrote: > > I've wondered in the past.. would people (users / developers) object > > to making the GTK HID for PCB more in line with gschem's GTK UI. (Or > > vica versa) > > Maybe we need a gschem HID for pcb? ;-)
I had wondered in the past, however; I'd hope it didn't end up carrying so much delta from the GTK HID as to make it worthwhile. I'm not a great fan of having to maintain so many GUIs, so unless there was something controversial (#ifdef might help), I'd prefer to see a convergence between PCB's GTK HID and gschem, not a fork of PCB's GTK HID. On Saturday morning, I started to refactor some of my GL code to sit in a common location where it (might) be usable by more HIDs. I explicitly didn't want to commit GL support as a fork of the GTK HID (which is how the code-base currently stands). My intention is that it should eventually be merged as a conditional compilation option for the GTK HID. Only the core drawing window + drawing callback hooks need to be swapped for GL / GDK drawing. Having done a little Xorg + Mesa + Compiz debugging recently, I've come across some cool stuff which might make the GL rendering even better - I think most machines will support some form of rendering to a texture - which should allow me to sub-composite layers better, possibly avoiding the stencil (which might be slow for some drivers). -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
