| Re: taking the widget plunge. help [message #21698 is a reply to message #21655] |
Tue, 12 September 2000 01:32  |
Martin Schultz
Messages: 515
Registered: August 1997
|
Senior Member |
|
|
"J.D. Smith" wrote:
>
>> P.S. Let's just say I spent a couple of days writing
>> documentation for FSC_PSConfig, *the* best program I've
>> ever written, and no one downloads it or uses it. You just
>> figure after a while, what's the point?
>
> I took this as a friendly reminder to check out your new stuff, and I was
> frankly amazed at how much work you'd put into the documentation. Really an
> astounding effort. I will try to integrate FSC_PSConfig into some of my
> programs around here.
>
> One note which I think is instructive. You include a section on customization
> where you outline how to directly modify your source to add personal or
> company-wide set-up lists. This is a very useful feature, but I think you're
> going to cause yourself and potential users grief here. It's a *perfect* place
> to flex our object oriented muscles. The problem will be that in a year you'll
> think of a great way to redesign it, or maybe RSI makes some changes to device
> which prompt a rewrite. Then, either all the users who have made their own
> modifications will be out of luck, or you'll be contrained in what kind of
> updates you can do. It is exactly these types of situations that scream out for
> some sort of object relationship. If, rather than giving direction on how to
> change your code, you gave a simple example of INHERIT'ing your class, and
> chaining to its setup code, you could fully preserve "forward compatibility" --
> i.e. drop-in replacement of your updated code.
>
I fully agree. Isn't inheriting what objects are all about?
> Or, since in this case the local setup changes are data-only (no fundamental
> method changes), you could simply provide access to an internally growable list
> of setups. Inheritance is not even really required.
>
> I haven't looked closely, but a method which allows you to add setup lists
> (e.g. self->AddSetup,"Company Viewgraph",/EUROPEAN, FontNameSet="Helvetica"),
> would seem to do the trick. This might be called automatically in Init with all
> the built-in defaults. A user could INHERIT it, override and chain to AddSetup
> for a fully internal solution, or they could use a compound relationship and add
> the setups "from the outside" in whatever wrapper routine (or object) they
> use.
>
> The details of how set-ups are stored, manipulated, etc., would be hidden, only
> the published interface of AddSetup need remain the same (or backwards
> compatible anyway... nothing to stop you adding new keywords as new features
> become available).
>
> Anyway, it's just a thought. Perhaps you're afraid of scaring off potential
> users with objects. You shouldn't be. It's good for them.
>
> JD
This seems somewhat "convoluted" to me (but after recent experience, I
am sure you will have your reasons for proposing exactly this). I
always tend to think that setup is best done with ASCII files that are
easily editable and human readable. Yes, you should have a method
named something like FSC_PsConfig::Setup, and this method should
define a minimal set of defaults. But then it would read a file and
overload the default definitions. If it doesn't find the file, well,
then you live with the defaults (or the company creates a child object
with specific defaults). Proposed strategy:
1. define a few defaults (IDL standard, letter portrait, letter
landscape)
2. look for setup file ('psconfig.setup') first in local directory,
then in IDL !PATH -
potentially also in !FSC_CONFIG_PATH if it is defined
3. if found, analyze file and overrule default settings
Useful additional keywords to setup would be:
/Add (and name, size, ...) : add a specific setting "manually"
/Help : print out a help message describing the setup file format and
search method
As for the file format you could do something like
A4:
size=11.9,6.2 # not sure about the values
color=1
END
A4_Landscape:
size=6.2,11.9
color=0
END
etc.
Poor David! The more you do, the more you are asked to do...
Cheers,
Martin
PS: If you like a parser method for a format like this, I can send you
one.
--
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
[[ Dr. Martin Schultz Max-Planck-Institut fuer Meteorologie [[
[[ Bundesstr. 55, 20146 Hamburg [[
[[ phone: +49 40 41173-308 [[
[[ fax: +49 40 41173-298 [[
[[ martin.schultz@dkrz.de [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
