On Thursday 15 February 2001 12:14, Randal L. Schwartz wrote:

> I think TimeTracker and TimeTrackedItem sound like the two most
> natural classes for this.  So I create TimeTracker as a subclass of
> Morph, I suspect.  Or should it be a subclass of SystemWindow?  And is
> a TimeTrackedItem on the screen as a submorph?  Does it have to be
> within the parent's bounding rectangle?

This all depends on what data you need to keep and what you're going to do 
with it.

Often, we separate the model -- the actual objects and their behavior -- from 
the view (the Morphs that you can interact with). This is how the browsers 
work, for instance. 

This lets you test the actual "business logic" separately from the UI. Your 
model classes might look like:

Project -- is named, has 0 or more tasks, can give you various totals
Task -- is named, belongs to one (or more?) projects, knows how much time has 
been spent on it. Might have subtasks (in which case its totalization would 
include them).
Session -- a single span of time spent on a task (start, end, duration). Can 
answer duration, can be paused and restarted

Actually, if you have Tasks that have subtasks, you could probably get rid of 
Project.

And then your view classes would have to provide for:
* creating new tasks
* starting, stopping tasks
* displaying task times and status
* saving and restoring data to disk

As far as the design, you can have bare Morphs, or you could use a 
SystemWindow. Windows can be collapsed; this is sometimes handy. Of course, 
any Morph could decide to depict itself differently when "collapsed". Your UI 
elements -- Morphs -- will point to the actual model data (that is, a 
TaskMorph will have an object reference to a Task).

Depending on how you want to display things, you could first look around for 
other Morphs that can do part of what you need (the 
SimpleHierarchicalListMorph comes to mind here if you're using subtasks). 
Also there's the PluggableListMorph. Or you could just have loose Task morphs 
wandering around in your main Squeak window. These would be submorphs of the 
World.

> Or do I even need classes?  Can I just hack a morph adding specific
> behavior/data?  I know... that's the VB approach. :)

You probably could use the scripting stuff for this, but I don't know enough 
about this to suggest anything.

> Presuming I'm using classes, where does the class code get stored? 

In the image, first; if you file out a change set or project it then lives on 
disk too.

> Do
> I make a project, build it there, then fileout the project from time
> to time?

You could. Or you could file out the change set.

> And then what about the data?  Should the class itself know
> how to store to a file (and if so, how?),

That's probably what I'd do. Depending on what you want to use the stored 
data for (like: do you want to read it with a Perl program <g>?), you might 
want to store it in some form that other programs can read (like lines of 
text). The Save Morph On File or ImageSegment format is not likely to be too 
readable by Perl.

> or should I just use "save
> morph on file" to save the data?  And if I "save morph", but then
> alter the class to add additional behavior, will the restored morph
> become one of the new class instances, or somehow stay one of the old
> ones?  And does "save morph" also save all the live submorphs?

Save Morph should save submorphs. If you add or change behavior, the restored 
morphs will have the changed behavior. If you change the instance variables 
(by adding, renaming, etc.) you may have to write a conversion routine to 
handle the old versions. There are provisions for this in the image (look 
into "conversion methods").

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com