[lazarus] [win32] Client area under win32

[Gerry Ferdinandus]

>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}
>3) COMPLETE
>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, USEFUL 
And COMPLETE.
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.

>>
>>
>>b) Testing tools.
>>For testing our interface we need some testing programs. The Lazarus 
>>examples are not suitable for our purpose. So we need some new one. For 
>>example one program to test ALL the property and event of Tbutton. An 
>>other program to test TComboBox etc. The new examples will also benefit 
>>for the future ‘new’ interface project (native OS X interface?).
>>This is a ‘long term investment’ for the Lazarus project. But we need 
>>these testing tools.
>>You need to test these new examples first on Linux/GTK system. (Dual boot 
>>system is recommended working method). Because LCL+GTK is ‘stable’ for 
>>programming and testing purpose.
>
>At the moment i don't think that all properties must be tested (see above), 
>only the most common.
>
Here is some extra explanation about the testing tools.
1) We must use EXACTLY the same testing tools. This is to avoid problems 
like. Tbutton 'testing' works fine on your computer. But does not work on my 
computer. Because I am using different testing tools etc. This will cause 
unnecessary frustration under team members.

2) Type and quality of the testing tools. This can be a long debate. 
Complete testing of all properties/events is NOT needed at this moment, only 
the most common. You are right about this. At this moment I am experimenting 
with a simple TButton ‘testing tools’. It is edited/run(F9) under Delphi6 
and can also be compiled with MAKE(fpc). This way I can use VCL as reference 
how it should work. And still be able to compile for LCL. I do not know if 
this is the best way to do it. For editing pascal code I always use Delphi.

(Same working methods and tools for all team member is recommended. This is 
to create better understanding for each other work and it is easier to help 
each other when problem arise.)

>>
>>c) Win API knowledge.
>>I thing most Delphi programmers does not know much about win 32 API. Of 
>>show no interests in studying it. Because they are trained in programming 
>>with component. This can be a problem for our goal. But for point (b) you 
>>do not need to know the API. For point (a) Api knowledge is recommended. I 
>>have a book ‘Programming windows 95’ by Charles Petzold (1996) it’s about 
>>programming windows with visual C by using API and not MFC. This is where 
>>I get my info about API.
>
>Fundamental
>
>>
>>As you can see ‘hacking’ the Windows32 interface code now is not 
>>professional for the long-term investment.
>
>The lazarus project can't be thinked as professional because it relies on 
>voluntary help ;-)
>

That’s true. But there is not much volunteers right now. ;-)

>>So we must decide first if we want to ‘hacking’ now or follow the above 
>>procedure.
>
>For now let's see what other people think
>
>>
>>First thing we must know our limitation in both time and knowledge of the 
>>subject. And do not get over excited about things.
>
>Correct. We also have life
>
>>I think the testing tools are the most important things for now. So I 
>>suggest that we write ALL the testing tools and THEN make the decision if 
>>we want start ‘hacking’ or start documenting (a).
>>
>>>>
>>>>3 Potential Windows32 interface programmer:
>>>>Markus Lüdin E-Mail: markus at luedin.com
>>>>Karl Brandt E-mail: pascalive at bol.com.br
>>>>Gerry Ferdinandus E-mail: Gerry_ferdinandus at hotmail.com
>>>
>>>How about keith bowes?
>>
>>I do not know if he is still interested in windows interface. Maybe he can 
>>answer it for him self.
>
>AFAIK he is the win32 mantainer.
>
Yes, he is. But nobody is helping him. :-(

PS.
(Message for "Vincent Snijders" <vslist at zonnet.nl>)
I have read you e-mail. Thank you for your help (writing the test tools). 
But at his moment we must first decide our working methods. We will keep you 
inform about the progress.




_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx