On Tue, 7 Sep 2010 12:50:50 -0700, Cory Nelson wrote:
On Tue, Sep 7, 2010 at 11:41 AM, Alexander Lamaison <awl03@doc.ic.ac.uk> wrote: On Tue, 7 Sep 2010 10:19:23 -0400, Gwenio wrote:
On Tue, Sep 7, 2010 at 8:40 AM, Alexander Lamaison <awl03@doc.ic.ac.uk>wrote:
I hope that, for starters, the end-result would look nothing like that produced by gtkmm. GTK-based GUIs on Windows just look 'wrong'. I'd hope that any solution we envisage would use the platform native widgets to render itself just as SWT does for Java.
Getting a native look would be difficult;
Why? It's been done well in the past. Just not for C++ (if you exclude the C++ 'port' of SWT)
ideally you would have a set of functions that provide the functionallity to draw in the native style.
Yuk. This approach doesn't work well. Every time the native style changes you have to update your fakes widgets. Maintainence nightmare! Not to mention that it's almost impossible to simulate native widgets faithfully.
And yet many people do want a native look, so if it's not using native controls already, I think building it with enough theme support to make this work is imperative.
Absolutely! I simply wouldn't touch a GUI library that didn't render native widgets. I'd be too embarrassed to release software that had an amateur look&feel.
The other way would to have a wrapper for native controls and some method to adjust how they function.
This is how SWT, Adam/Eve, etc. work though I'm not sure what you mean by adjust how they function.
I think that using native controls, while much simpler, would severely handcuff us in terms of how great we could design the library. A clean break from any native controls would give us many more options.
I know that saying "WPF" will turn some people off immediately
Not me. But by all accounts the effort involved in developing the 'windowless' WPF GUI library wass extreme. Possibly as great as all other Boost libraries combined. (If I had time I'd find the quotes from MS insiders to back this up. Raymond Chen said something pertinent to this at one point.)
If there are native controls why bother with custom controls. (I also don't see what 'branches' have to do with anything - do you mean 'option')?
Not all native controls exist on all platforms, and not all native controls have the same functionality. If we didn't want to limit the library to the small subset of controls and functionality that exist on all platforms, we'd eventually need to write some custom controls.
The overlap is greater than you think but you have a valid point. SWT's approach to this to to custom-draw a control if and only if it doesn't exist on the platform in question and can't be created by aggregating two or more other controls. This is an acceptable approach as it it _not_ simulating a native control: there is no native control to simulate. I know I keep harping on about SWT but it really is a *fantastic* GUI library that gives cross-platform, best-of-all-worlds, native GUIs rather than lowest-common deminator support or custom-drawn nonesense. My idea of the ideal Boost.GUI library would be something in the vein of SWT but with a much nicer interface. For those of you who hate the idea of manipulating individual controls and want to program at a higher level look at the relationship between SWT and JFace. JFace create common UI elements in a model-based manner and is built on top of SWT. SWT in no way depends on any aspect of JFace. The same should apply to any higher-level GUI framework in Boost. It should build on top of an SWT-style layer and, in my opinion, they should be separate libraries. Alex -- Easy SFTP for Windows Explorer (http://www.swish-sftp.org)