Re: gEDA-user: pcb printing

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Mon, 2009-03-02 at 13:22 -0500, DJ Delorie wrote:
> > 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?
> 
> Because, as Mike puts it, GTK under windows doesn't look like windows,
> doesn't act like windows, and just confuses users.

Looks: Use the right theme engine, and it does a pretty good impression.
File-choosers being the main exception, but you could (if desired), use
custom code to invoke the Win32 file choosers.

Acts: Need to make more use of GTK's APIs to reorder buttons on dialogs
for different platforms perhaps? I'm more interested in specifics
though.. this is all about conventions, not the toolkit.

Win32 doesn't really have a toolkit as such, as far as I could tell last
time I programmed for it. Different development platforms use / provided
different APIs. Only commdlg32.dll (?) provided some coherency across
the platform last time I coded Win32. (This was back when you chose
between MFC / OWL / raw win32 APIs).

> > 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?
> 
> It looks different, acts different, etc.  If it were me, I'd get rid
> of the GTK hid - it's the least maintainable for us.

Perhaps the code is a little crufty in places, but I wouldn't call it
difficult to maintain.

Just because it looks different - so what. Does it cause a problem with
usability or speed? Does it act differently harm productivity?

> > 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.
> 
> And it would look like and act like none of the above.

All of the above can use the native theme engine for Win32, either as a
theme engine plugin, or as part of their native design. What you do with
the toolkit may give you differences in UI paradigm between various
platforms, but this is largely up to the programmer, not the toolkit.


I think maintainability / unified documentation is far more important to
us than making the apps feel 100% native, certainly at this point in
time. I see developer effort as our most valuable asset, and it is a
shame to divide it between multiple front-ends using different tool-kits
where such effort could be minimised.

New HID's (once merged) aren't free, from a core maintenance / design
flexibility point of view. Unmerged HIDs create a headache for their
maintainer as anyone else wants to alter the HID API between releases.


-- 
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