On Sun, 2009-03-01 at 22:03 -0500, DJ Delorie wrote: > Note that if Mike gets the Win32 HID working, it will support > Win32-based printing.
Is there any reason why this Win32 effort isn't / can't be merely adding developer time to ensure that the GTK code works well for its Win32 port, and adding native code as required to improve the integration / feel of the app for Windows users? (This might include work on Win32 printing, and / or native file-chooser dialogs). The way we're going, which I think is a shame, is to end up with three separate applications which happen to share a name, common file-format and a quantity of core code. We'll need three user guides, three bug-tracker (categories), ~3x developer effort for every feature added / changed which requires interaction with the user. Aside from the exercise to verify the decoupling of the HID API, (and at the risk of being controversial), what are the tangible reasons for the Lesstif HID's continued existence? Assuming a minimal GTK, with no theme engine etc.. are there any performance issues? If it is a UI design preference / usability issue, are they so far different from common GTK (or GNOME) UI design guidelines, that it couldn't be implemented through options? Either GTK, QT, or WxWidgets would give us a single toolkit, single code-base HID with true cross platform portability to Unix, Win32 and MacOS. Creating more HIDs than necessary is not cost-free from a maintenance and user-education point of view. EDA tools are sufficiently far from the category of desktop app, that I don't see a burning need to NIH a version for each and every favourite toolkit someone might come up with. (Says a biased Peter, who's favourite toolkit happens to be GTK at the moment). > OTOH it would be nice to separate out the rendering layer if it means > 3D-based rendering for Lesstif as well as GTK. If we could create a > cairo module, for example, which the various HIDs can point at a > window... I don't think it needs to be a full HID, just a rendering > module that the HID can choose. Each HID using it would probably just need a bit of code to create the cairo_t, and pass it along to the the share cairo code. If someone reminds me, I'll try and find my old attempt at a cairo renderer for PCB when I get a chance. This is similar to the GL code (which needs an active GL context). I've separated the core GL drawing routines. I just need (at some point), to figure out how to abstract some of the more complex / hardware feature dependent code, such as VBOs / stenciling etc.. Best regards, -- 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 geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user