[[lazarus] Design issues]

[Shane Miller]

I agree this sounds good.  We need to look into it a bit further but I would still like to get those people familiar with this project working on the editor code and not this.  I would prefer to get the editor working before we rip apart and redo the base classes.  Unless this is hindering us, I feel we should continue on.  If we had someone new to the project that isn't involved in another part of it currently, then they could look at this and try to change it but I want this editor up and running first. That would make things a TON easier.

What are the major issues with the editor that need changing at this point?

Shane


>>> mbukovjan at netscape.net 02/22/00 05:39AM >>>
Florian Klaempfl <Florian.Klaempfl at gmx.de> wrote:
> Hi,
> 
> I'am still curious about some design decisions of lazarus:
> 
> - Why do you still use the strange message concept to communicate with the
>   toolkit interface??? Virtual methods or another class ttoolkitinterface
>   could easily do the trick. I know messages are a clean OOP concept 
>   but in compiled languges they are replaced by virtual calls or
methodpointers  

Yes, I am thinking about this same thing. The virtual method concept would be
much more clear, maybe some abstract interface object and then for each widget
there could be a mapping extended interface object descendant.
BTW, I wonder even Borland uses CM_??? concept which seems to me redundant on
many places. Does anybody know why use these internal CM_ messages at all?

I, too, don't like huge case statements, it just doesn't feel good :-)

> - Also the tgtkcomponent.createcomponent seems to be a rather strange idea
to me! 
>   As far as I can see you have always to modify the lazarus sources if
you're creating
>   a new type of component? If you want to be toolkit independend you could
>   create functions like 
>   CreateButton, CreateToolbar etc.
>   The same applies to tgtkobject.setproperties

That would end up being the same - creating new functions for new widgets.

> 
> Both things have some impact on performance: FPC and the processor tries to
do
> good branch prediction :), but you puzzle them by using a lot of case
statements,
> let it me point out more precisily:
> 
> Example TProgressBar.SetPosition:
> 
> It calls ApplyChanges, well quite ok, but we wouldn't need to change all
properties,
> but now SendMessage is called and here you loose two pieces of information
in the data
> flow:
> the object type and what you want to do: SendMessage figures out again what
you want
> to do by testing a lot of cases and setproperties figures out again of what
class
> type the sender was! I think the processor has to do better things! 
> 
> Clean proposal for a solution:
> 
> twincontrol or tcontrol gets a pointer to a class ttoolkitinterface
(similiar
> to the handle under windows) and ttoolkitinterface has 
> childs like ttoolkitbutton with a appropritate methods.

Hmm, definitely worth considering.

Michal Bukovjan

____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at http://webmail.netscape.com.

_________________________________________________________________
     To unsubscribe: mail lazarus-request at miraclec.com with
                "unsubscribe" as the Subject
    archives at http://www.miraclec.com/list_archives/lazarus