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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
