On Wed, 18 Jun 2008 17:19:52 +0200 "Graeme Geldenhuys" <[EMAIL PROTECTED]> wrote:
> 2008/6/18 Mattias Gärtner <[EMAIL PROTECTED]>: > >> 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 _______________________________________________ Lazarus mailing list [email protected] http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
