[lazarus] [win32] Client area under win32

Karl Brandt pascalive at bol.com.br
Tue Sep 24 23:12:28 EDT 2002

  Gerry Ferdinandus wrote:

>> From: Karl Brandt <pascalive at bol.com.br>
>> Reply-To: lazarus at miraclec.com
>> To: lazarus at miraclec.com
>> Subject: Re: [lazarus] [win32] Client area under win32
>> Date: Fri, 20 Sep 2002 18:18:41 -0300
>> Gerry Ferdinandus wrote:
>>> Windows 32 interface is a long time project. So we need some 
>>> project management method implemented here.
>>> a) To make this project success full we need some good 
>>> documentation. Like what is implemented at message level and things 
>>> still need to be done etc. So we need some agreement about the 
>>> document structure and the contents.
>>> People come and go. But documentation stays. If will also help other 
>>> potential windows interface programmer.
>> The best approach, i think, is have on mind one objective and go in 
>> this way.
>> As you said lazarus/win32 is a big task, and we can't take as primary 
>> objective make it complete,
>> so i propose to divide the work in tree steps/objectives:
>> Make the win32 interface:
>> 1) USABLE
>> Where the principals properties/events/methods of the principals 
>> components work.
>> 2) USEFUL
>> Where more components, properties/events/methods works
>> {Note that only recently lazarus/gtk got this state}
>> Description not necessary
>> Once we believe in this way, we must elect the 
>> components/properties/events/methods that are necessary to which step
>> and make the docs with these.
>> Basically i propose two types of doc (if we agree that it must exist):
>> One summary table with the state (3 or 4) of the property/event/method
>> One doc with one detailed table for which control.
> Agree, the project will be divided is 3 project milestones: USABLE, 
> So every properties/events/methods can have 3 priority level
> Document table based is ok.
> Some table idea:
> The X mark the priority level
> When finish/tested the finish column will be X
> TButton | USABLE | USEFUL | COMPLETE | Finish
> ---------------------------------------------------------------------
> OnClick | X | | |
> Caption | X | | |
> Font | | | X |
> Etc.
> I think one doc with this type of table should be enough. Every 
> component will have it own table. It is going to be a big document.

I made a sample table that ilustrate what i said.[see Attachment]
The colors indicate in what objective/step the property is.
red -> usable
For example:
The property Height is red so it's a property that must be working to 
get the usable target.
This way, we must concentrate our efforts to get all red 
properties/events/methods Done before jump to the yellow ones ...
I propose three flags: Done, Partial, Broken
The fields Details, Devs, Extra don't need explanations
I see this as a good way to organize the job, make-it produtive, and 
avoid duplicate work ;-)
But requires some work :-(

-------------- next part --------------
A non-text attachment was scrubbed...
Name: zip00003.zip
Type: application/octet-stream
Size: 979 bytes
Desc: "lazwin.zip"
Url : http://localhost/pipermail/lazarus/attachments/20020924/2e542672/zip00003.obj

More information about the Lazarus mailing list