On Wed, 10 May 2006 22:46:14 +0200
darekM <[EMAIL PROTECTED]> wrote:

> Mattias Gaertner napisa?(a):
> > On Wed, 10 May 2006 21:38:18 +0200
> > darekM <[EMAIL PROTECTED]> wrote:
> >
> >   
> >> [...]
> >>     
> >>> Nothing personal.
> >>> We need to make sure, that no useless properties are added to the LCL
> >>> only to let .dfm load with lesser errors or some Delphi code gives
> >less >> errors.
> >>>   
> >>>       
> >> Why not. 
> >>     
> >
> > First of all: Lazarus is beta and we want to achieve 1.0. 
> I also work on it.

:)

 
> > Every published
> > property should work or at least be documented why it can't be
> > implemented easily.
> 
> > Second: If we add an unimplemented publish property then we can go
> > directly
> >   
> > to the bugtracker and add it as bug. Otherwise people will do it. They
> > always did that.
> >   
> Thats no problem (add to bugtracker)

Huh? 
A patch should fix bugs, not add them.

 
> > Third: We will not add all Delphi 2005 properties, just because we will
> > likely implement them in a few years anyway. We add them, when we
> > implement them. At least partly.
> >
> >   
> They are not all properties, only one. Its not so important, but I think 
> its better if newbie compiling without error and his program not work 
> proper than not compiling at all. 

No. At least not in general. If I learned one thing from lazarus in the last
years then this:
A newbie, who successfully compiles some units is happy until he tests it
and finds out: it does not work. Now he is scratching his head and has no
clue, where to start searching.
With a compile error he directly sees, what to comment/change.


> I can workaround it, but i think not all.
> >   
> >> Programs are build step by step. Better is add something to 
> >> avoid some of compiling errors now, and in future make progress on it. 
> >> If we investigate all LCL (or even VCL) we found some places that seems
> >
> >> unnecessary. Of course is very important to avoid slowness and huge 
> >> memory consumption. I've been resist to add not useless field to 
> >> tMemoItem, but tPopupMenu is different. Nobody have more than 1000 
> >> menus, but tMemoItem are many more.
> >>
> >>
> >>     
> >>> Every added property must be implemented and work on almost all
> >>> platforms.
> >>>       
> >> Are you sure, that every property  work "on almost all platforms". When
> >
> >> some of us make property to one platform,
> >> others must wait until somebody implement it on second (third...) 
> >> platform. How to add new property working on all platforms at once.
> >>     
> >
> > Add them public and publish them when they work on almost all platforms.
> >
> >  
> >   
> >>> And publish properties when they work. 
> >>>   
> >>>       
> >> Maybe PUBLIC will enough in my patch. (I don't understand difference 
> >> between PUBLIC and PUBLISHED.
> >>     
> >
> > Published means they are visible in the object inspector and are used by
> > newbies.
> >
> > We can add the property as public if you promise to implement it next
> > week for at least one widgetset.
> >   
> How to achieve this, when 3 my patch waiting on mailing list, and 2-5 on 
> my computer.

Yes. Sometimes I got the feeling I'm the only one applying patches and my
time is limited. Especially since some of these patches are hard to tell
what they break and what to test before committing. 


> But more seriously
>  Its not so important to me. If somebody ask, then I can help or
>  implement. You may throw out this patch.


Mattias

_________________________________________________________________
     To unsubscribe: mail [EMAIL PROTECTED] with
                "unsubscribe" as the Subject
   archives at http://www.lazarus.freepascal.org/mailarchives

Reply via email to