Re: gEDA-user: pcb printing

[Peter Clifton <pcjc2@xxxxxxxxx>]

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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user