[Cuis] Preferences // Settings

[Casey Ransberger]

Hi Hannes,

The overall idea is that a class called Preferences isn't really even
necessary beyond simply pointing the user at where the actual preferences
live, because preferences in Smalltalk tend toward being either global
variables (which we usually want to avoid) or persistent state on long
lived objects (most often, class or class instance variables.)

So instead of continuing to pile a bunch of user preference state/behavior
in one place, we might instead put that state/behavior where it ought to
sensibly go in the system organization and instead provide a user interface
to the many sites in the system which are customizable. The point is one
ends up with looser coupling.

Worth noting, with a bit of a grin, that I did exactly the opposite thing
with Theme, but only because I saw an interesting opportunity to separate
concerns about look and feel throughout Morphic, which seemed worth doing.
I still think that was a good idea. Anyhow I digress.

Does this all make sense? I'm not making a call to arms to kill Preferences
so much as I'm making a call to arms not to fatten the thing anymore, so
that one day it can retire comfortably and in good standing for all of the
hard work it has done.

As to which things I'd like to remove from preferences? Well, font-size
definitely should be a part of Theme in my opinion. That's currently still
a preference, and mostly because I haven't gotten round to submerging it
into Theme yet, but I wouldn't hate it if someone beat me to the punch on
doing that :D

C

On Sun, Mar 3, 2013 at 5:32 PM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

> On 3/1/13, Juan Vuletich <juan at jvuletich.org> wrote:
> > Hi Casey,
> >
> > On 28/02/2013 05:32 a.m., Casey Ransberger wrote:
> ....
> >> In other news, should we add this stuff to the appearance menu? I think
> it
> >> might make sense since we don't have a browser for preferences
> currently,
> >> and I doubt we need one either.
>
> >> Andreas hated Preferences, wanted the settings to live on the actual
> >> objects as opposed to in a big (Preferences) pile, and I really
> identified
> >> with that idea.
> >>
> >> Thoughts? It's something that any of us could easily do, and I'd
> volunteer
> >> for that.
> >
> > Sure. I agree with all you say. Go ahead.
> >
>
> Casey, which candidate objects/classes do you see where the
> preferences should live?
>
> And what would be the next very tiny actual increment to implement?
> Appearance menu? Which menu entries? Just the one Helmut asked for?
> Others?
>
> Regards
> Hannes
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20130304/788afeb4/attachment-0003.html>