Micha Nelissen wrote:
Burkhard Carstens wrote:
However, with win32/gtk LCL this is even worse... seems like one never
knows, whether an event was fired before or after ..
These are all bugs. The developer interface should be as consistent as
possible, yet the look and feel for the user as native as possible.
Problem is that the order of events is not documented (since they are
delphi internals), and we should do this as we go along; this requires
some discipline however.
The wiki could be a good place to store these events plus their
relationship to programmer and user actions. It would make porting to a
new platform a lot easier as well.
I agree that documenting the LCL behavior is a good thing and could
improve the Lazarus quality. As a example if a Delphi feature is not
doable in LCL, just document and show an alternative (like done for
TBitmap.Scanline).
Another point is defining the set of features/controls provided by LCL:
- Is necessary TCListBox?
- Is already deprecated in GTK and TListView fills the function
with advantages
- Is necessary TPairSplitter?
- AFAIK it was introduced only because TSplitter was not available
- It could be implemented as a package
- Should non visual code like *CriticalSection functions be in LCL?
- SyncObjs already exists and can be used in a more elegant way
- Imagine the pain to implement them in a crossplatform widgetset
like QT, fpGUI, or even GTK2?
Removing the unnecessary, duplicate functions/components, not doable
features would help in the development and maintenance of Lazarus, not
to say the code size.
Of course this could not be done immediately, would be something after a
1.0 release with 2.0 in mind.
Luiz
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
