minical 0.1 patchfile

That is entirely your decision. It would be useful to have a
post  
mortem of this processs at any rate--

I'm posting this to the list in hopes we can start a
discussion on  
patch process. I.E What is the right way to submit a patch?

I went forward with bug fixes to this and some of the
dojoifying as I  
did not think the first drop was really good enough to be
primetime,  
which I mentioned in the drop. Hopefullly you can use some
of the  
fixes in the patch I sent.

Jeremy



Quoting Matthew Eernisse <mdeosafoundation.org>:

> Jeremy,
>
> I'll have a look at it in the next day or so. The
problem with this
> patch submission is -- as I mentioned to you on IRC --
integration work
> started awhile back (using the original patch that you
submitted) --
> and actually is almost done now. Trying to integrate
code that is
> continuing to evolve and change is not really a tenable
practice, for a
> lot of really obvious reasons.
>
> Outside participation for Scooby is a new thing on both
sides, so I
> realize the process is not very well fleshed out -- but
it's probably
> best either to do all your updates to the code *before*
submitting the
> patch at all (i.e., get it to a point where you're
pretty happy with it
> before you send it), or wait until your initial work is
integrated, and
> begin your updates on your code once it's in the
Scooby codebase.
>
> I should be finished getting the minical into the tree
in the next
> couple of days, and after I get it checked in, I'll
send you a
> port-mortem to let you know what changes I made to your
code, and why.
> Some of those changes may be things you've fixed in
this patch, but
> again, I did the integration based on what you
origianlly sent. I'll CC
> the dev team on that e-mail as well.
>
> I know the initial first times through this process
there will be some
> bumps. You just have the 'good fortune' of being a
great first test
> case.
>
> Thanks.
>
>
> Matthew
>
>
>
> Jeremy Epstein wrote:
>> OK here it is.....
>>
>> I am not sure if its appropriate to post patches to
the list, so   
>> help me out here....
>>
>> ths zip file contains images -- extract to your
images subdirectory  
>>  on webapp.
>> the .diff file is for SVN
>>
>> What is here
>>
>> minical drawing in scooby
>> --you can navigate months and select days etc... I
tired to make   
>> the interface conform as strictly to chandler as
possible.
>> -- you can move minical around the screen-- this is
for the   
>> designers-- screen snap where you want it and we
can stick it there.
>>
>> what is not here
>> -- mini cal doe not update the main calendar --
that is for the   
>> main scooby team to do. I hope mincal will act as a
sharp stick for  
>>  the dev team to settle on a architecture for these
components and   
>> views.
>> -- busy bars. mostly because I do not have an
efficient means of   
>> getting the data. I would prefer an array of
"scores" the length of  
>>  the number of months currently shown. I.e. one
score (from 0.0 to   
>> 1.0 per day) I don't need to know about actual
events.
>> --this is still not a dojo widget, although it uses
dojo libraries   
>> for substantially all external operations (i.e.
dojo.late, .event   
>> etc..)
>> --its interface should be compatable with dojo.
>> --does not use dojo topics for updateing-- it uses
an alternate   
>> framework until dev team decides what to do
>> --minical updates the Pref object (via cal_main,
which I consdered   
>> the controller) when changing selected day. Cal
main currently does  
>>  not expose methods to get or set selected day that
can update   
>> external views, so I added them. There is a catch--
surrently the   
>> methods update the Prefs store, but do not update
the main   
>> calendar. I leave it to matthew to hook the getter
and setter to   
>> cal_main internal data model.
>>
>> anyway have fun
>>
>> Jeremy
>>
>>
>>


_______________________________________________
scooby-dev mailing list
scooby-devlists.osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman
/listinfo/scooby-dev