[lazarus] delphi compatibility

[Michal Bukovjan]

Marc Weustink wrote:

>+ From: Michal Bukovjan [mailto:michal.bukovjan at openone.cz]
>
>[..]
>
>+ Sure. That is why property editors exist after all.
>+ Just for a record, I studied how it is done in Kylix today.
>+ In pursuing compatibility, Borland arrived exactly to what I
>+ want to avoid. On their controls, you can set up *only* Color,
>+ and Font.Color (as in Windows) and Bitmap, which seems to be
>+ new. The problem is, when you use your own colors, there is
>+ no way to specify the color of font or background for disabled
>+ or mouseover state.
>+ So when a user applies the right theme, you get unreadable
>+ text or funny looking hover effects (yellow text on yellow
>+ background, or gray text on gray background, etc.). I call
>+ it plain design flaw.
>+
>+ I will think about this ExtendedStyle some more :-)
>
>IMHO, if one is using themes, one should not play with fonts/colors/bitmaps
>etc. It should be handled by the theme. If one still wants to change
>fonts/colors/bitmaps etc. I call that a design flaw.
>
The problem is in the words *one*:

one as a developer -
   a) either leaves default colors/fonts, and application copies theme. 
Everything is OK. Note that developer is not using themes, it is the 
widget set that uses themes. All that developer can do is to leave 
defaults, i.e. use widget set calls to draw (that is the reason for 
Frame3d, for example).
   b) wants to have his own skin/colors (like most multimedia players 
do, for example - xmms, winamp) - no go with Lazarus/Delphi, he can 
define only some limited aspects

one as a user - can use any theme he wants. Application should either 
respect the entire theme (which Lazarus does not at the moment, but this 
is regular bug right now :-) - case a), or define its own *replacement* 
(i.e. define its *all* colors/fonts on its own), not just a subset - 
case b) - not possible with Lazarus by design.

With current Delphi-like design, it can be fixed so that we can do a) 
with Lazarus easily.
Without design changes, we will be unable to handle case b).
If we choose to ignore case b), or implement later once Lazarus takes 
over the marketplace, we should state it somewhere so that developers 
don't bother :-(

Michal


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