[wx-dev] making wxSystemOptions become wxOptions ...

[Stefan Csomor]

Hi Vadim

sorry for the delay ...

> First of all, I agree that using options-based approach is one of  
> few ways
> around the ABI-compatibility constraints so if this is a major goal  
> then we
> may have no choice but to use it. However I thought you were  
> speaking more
> about 2.9 development and not 2.8 and I hope that even if we do  
> introduce
> the options-based approach in 2.8 we can provide a better API for it  
> in 2.9.

no you understood correctly, this is not for 2.8, but for 2.9 and  
later  - but of course I assume that we will run into similar problems  
sooner or later in the release cycle there as well..

> As for the example itself, the transparency should, of course, be set
> using a normal wxWindow method -- we do have it already and there is  
> no
> reason why it shouldn't be available on all platforms [in the  
> future, even
> if they don't support it now]. The concept is universal and so it  
> makes
> perfect sense to me to support it at wxWindowBase level.

yes, but I meant some 'special' aero transparency, not a common  
feature to all platforms, just an imaginary AERO only feature, which  
we didn't think of then writing the API, but we would like to support  
it later without breaking the API

>
> The "metallic" look and feel is more tricky but if we can do things  
> like
> above, i.e. use factory classes instead of directly writing "new  
> wxTLW",
> then it has a clean solution too: just use  
> MetalLnFFactory::CreateTLW()
> instead of DefaultFactory::CreateTLW() (and typedef MetalLnFFactory to
> DefaultFactory on the platforms which don't have it; it would derive  
> from
> DefaultFactory and share its code under Mac, of course).

I don't think this is a good idea, as we would end up with the square  
product of all possible options, eg we want a unified metallic look, a  
unified non metallic look etc etc ..

as I said the aim exactly is the loose coupling that arrises, I also  
thought about dynamic casting of a wxParam subclassed object that  
would have these methods, but then again we end up in a tighter  
coupling, eg this header would have to be available for compiling,  
exposed for wxPython etc... it would only be upwards compatible, but  
not backwards, unless we would make a subclass for every change ...  
and use dynamic casts in the toolkit backend

> SC> - another use case would be eg saving an image with jpeg
>
> Well, of course we already use options with wxImage so I can't really
> argue with this and, anyhow, I must admit that this is one of the few
> situations where I don't really see any alternative: there are many  
> image
> formats and many of them may have their own options and we just can't
> provide a common API for all of them. OTOH it also illustrates well  
> the
> problems due to the use of options, notably the mess with the  
> existence of
> both wxIMAGE_OPTION_RESOLUTION and wxIMAGE_OPTION_RESOLUTION[XY]  
> options
> (which are independent even though they shouldn't be) and the fact  
> that
> different handlers interpreted the meaning of  
> wxIMAGE_OPTION_RESOLUTIONUNIT
> differently (I corrected it since then but with a more explicit API  
> the
> problem wouldn't have arisen at all I believe).

I don't think that the fact whether something is exposed as a method  
or a option string really make a difference in this regard, it rather  
is the urge to DO something rather than first reading and asking what  
already exists, and what the semantics of it are. Also my point of it  
is also that to me there are options or properties on an image, eg dpi  
etc. but also options on the serializing process, like JPEG  
compression degree, etc.

The same will arise on the level of wxGraphicsContext implementations,  
there could be eg the switch between an cairo and a gdiplus backend,  
perhaps the drawing code would not even have to know which one is  
active, it would just set up his array of preferences ...

Thanks,

Stefan