[haiku-commits] Re: r33903 - in haiku/trunk/src/apps/debugger/settings: . generic
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Fri, 06 Nov 2009 08:03:05 +0100
On 2009-11-06 at 05:02:27 [+0100], Ryan Leavengood <leavengood@xxxxxxxxx>
wrote:
> On Thu, Nov 5, 2009 at 4:47 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
> >
> > BMessages are usually just fine for settings, although a BVariant might
> > be easier to use in that case.
In fact my Settings class itself is just a wrapper around a BMessage using
BVariant to communicate the values. :-)
> I imagine for many cases BMessages are fine for settings, but for
> whatever reason some other wrapper classes were written in some of the
> apps for Haiku, and it might make sense to share some code instead of
> having various slightly different versions. But you guys know how I am
> on code duplication :)
I'm all for code reuse, too. Though a general problem with reusing a
class/framework is that API/semantics changes require you to update all
places of use, which can be annoying, particularly when reuse started before
the class/framework was mature enough.
> I'll just keep this in mind for the future, at least for ShowImage.
> Ingo's new code here just seemed like it was more of a framework that
> might be reusable, and it is well written and (eventually) well
> tested. Though maybe it is too much for simpler apps.
The focus of my work is a bit different. ShowImageSettings is basically a
thin wrapper around BMessage adding some convenience methods (the getters and
setters could as well be added to BMessage itself -- KMessage features
those), while I mainly wanted a generic way to describe what settings are
available (cf. SettingsDescription and *Setting). This allows for partially
automated generation of GUIs for manipulating the settings (cf.
SettingsMenu[Impl]).
For actual program settings I have, so far, preferred dedicated settings
classes that can be archived to/unarchived from a BMessage.
CU, Ingo
Other related posts:
