[lazarus] [win32] Client area under win32

vslist at zonnet.nl vslist at zonnet.nl
Wed Sep 25 09:57:07 EDT 2002

Making a document with things to do seems like a good idea. Certainly if the
work can be divided with it.

Maybe we could be it more useful if we change it a bit. At the momennt it
looks at the interface of the LCL (properties, methods and events). I think
we should look at the interface of the win32Interface object. We should try
to make that compatible with the gtk interface object.

Therefore I propose a different setup, in which we document which messages
are sent by the LCL to the interface object en what messages the interface
the interface is supposed to send to the LCL.

It could be used for future porting as well, as it gives a description of
what has to be implemented by an interface.

Vincent Snijders

-----Original Message-----
From: Karl Brandt [mailto:pascalive at bol.com.br]
Sent: woensdag 25 september 2002 5:21
To: lazarus at miraclec.com
Subject: Re: [lazarus] [win32] Client area under win32

  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 :-(

Aan de inhoud van dit e-mailbericht kunnen geen rechten worden ontleend. De informatie verzonden in dit e-mailbericht is uitsluitend bestemd voor de geadresseerde. Het Centraal Bureau voor de Statistiek staat niet in voor de juiste en volledige overbrenging van de inhoud van een verzonden e-mailbericht noch voor tijdige ontvangst daarvan.

No rights may be derived from the contents of this e-mail message. The information in this e-mail message is intended only for the addressee. Statistics Netherlands cannot vouch for the correctness and completeness of the contents of e-mail messages, nor for the timely receipt thereof.

More information about the Lazarus mailing list