On 20.01.2012 23:17, Brad Anderson wrote:
I occasionally try to think about what sort of changes would be made to the
wxWidgets interface to be more idiomatic to D.  Signals come to mind (along
with delegates wherever possible).  Range-based access to the items in
certain containers is something that would be useful (wxWidget's container
item accessing is a particularly bad part of its API).  Probably use D's
date/time functionality rather than wxWidget's (or both).  There are some
stream classes in wxWidgets which could probably be replaced with a range
based interface (which would just serve as an adapter between ranges and
the streams).

It's a shame D doesn't have named parameters because wxWidget's usage would
benefit greatly from them (wxWindow and subclasses of it often have 4 or
more default parameters that I often need to specify to get to the one
parameter I actually want to set).  wxSizer's Add method is confusing
enough that they added a named parameter idiom version so you could
actually read the method call and figure out what is going on.

It's also a great benefit to be able to rely on wxWidgets' available examples and documentation, which might outweigh most benefits you can get by improving or D-ifying the API. Adding more convenient ways of doing things on top of the existing API should be fine, though. DWT doesn't add much on top of SWT, but if I recall correctly, the SWT API is already a lot nicer than wxWidgets.

Reply via email to