[Lazarus] Color setup of the Form1: TForm1

[Mattias Gaertner]

On Wed, 18 Jun 2008 17:19:52 +0200
"Graeme Geldenhuys" <graemeg.lists at gmail.com> wrote:

> 2008/6/18 Mattias Gärtner <nc-gaertnma at netcologne.de>:
> >> For LCL to ever reach v1, all primary widget sets should support
> >> the same functionality. If not, remove it from the LCL.
> >
> > Define 'same functionality'.
> 
> OK, lets use the example of this thread. If you have a Form.Color
> property working in Win32, that same functionality should work for all
> 'official' widget sets, before Lazarus can reach v1 status.
> Consistency is key!
> 
> What's the point in having a property available in a widgetset when it
> does nothing.  That's kind of my point.

The program does not crash.

The problem of the widgetset specific properties is known. A first
step is the 'restricted' page in the object inspector.

A second step is document all widgetset specifics.

For the v1 I agree, that we need to IFDEF some features.


> >> took this route from the start (create their own custom drawn
> >> toolkit), I think they would have 70% less bug reports compared to
> >> now and Lazarus would long ago have reached v1 status.
> >
> > I doubt that.
> 
> I scan through all the mantis bug reports as they land in my inbox. A
> hell of a lot of them are regression bugs. Implement something new
> (new event due to a message or something) for a specific widget set
> (eg: Treeview under Win32), and it breaks the treeview under other
> widget sets. Or the behaviour (features) of the Treeview is now out of
> sync between all supported widget sets. 
> Such errors/issues do not
> occur in fpGUI because there is only one set of GUI components and a
> platform neutral messaging system - all platforms use the same
> component code. Implement something under Linux and it's available
> under Windows too.

True.
But:
- is it VCL compatible?
- What about file dialogs, icons, clipboard, sub pixel rendering,
unicode support, accessibility features, all that stuff that
gtk/qt/carbon has already implemented and more important: is
maintaining?

 
> As for how components look... I spent a lot of time testing canvas
> painting routines in fpGUI. The canvas painting routines are now
> identical (to the pixel) under Windows and Linux. I can now develop a
> new component 100% under Linux and have the knowledge and trust that
> it works and looks identical under Windows. And yes I know the old
> argument of "Look and Feel", but trust me, users are not that fussy
> (Windows Media Player, MS Office etc..). It's very easy to fool 90% of
> the users out there in thinking it's native!

Does that mean fpgui's theme engine is finally good enough to create
native looking apps?

 
> All I'm saying is that it's *much* easier to maintain a single set of
> components, than trying to make all different toolkits from various
> vendors act the same. You guys have done a great job trying, but it's
> been a huge battle and a lot of time to get there. Time I think could
> have been better spent on something else if LCL was based on it's own
> custom drawn toolkit.

Have you ever wondered, why lazarus has more than 3 widgetsets?
Technically windows/gtk/carbon would be enough for Windows, WinCE,
linux, BSD and OS X. Apparently people don't like the same look&feel.
They like a native look so much, that they spent quite a lot of time
into specializing instead of working on the base set.


Mattias