skin-able lazarus / 31-LCL ---------------------------------------------------------------------- gulyone · 2013-03-09 22:53 hello everyone I just had a look to the TWidgetSet class and it brought up a little question in my mind : I'm wondering if overriding the 'NC' funcs/procs can be possible 'after' the inheritance and initialization process is done on different OSes ? I think it could be a great technology for a starting point to write skins engines ... what is your opinion ? note : 'NC' funcs/procs are those which paint non client areas of the windows. aparently , lazarus let the Oses responsible for these tasks. I didn't see redirecting capabilities into the TWidgetSet common ancestor for all supported platforms (like OnNCPaint , OnNCCaption, OnNCCalcSize , etc...) dont you think it would be cool and great ? and a starting point for a LazSkinEngine ? maybe in a platform independant way ... ---------------------------------------------------------------------- Dibo · 2013-03-09 23:14 TWidgetset is a wrapper for target OS api. For example: TListView class on windows is using WinAPI, on Linux GTKListView or QT equivalent on KDE. It is hard to create OnPaint event which will look same on all OS. This is just different api and logic. Thats why Lazarus Custom Drawn control where created. But it is a long way to go ---------------------------------------------------------------------- taazz · 2013-03-09 23:19 doesn't fpgui has the same  philosophy with customdraw? any chance of borrowing code or extending that framework ? ---------------------------------------------------------------------- Dibo · 2013-03-09 23:23 Yes, fpGUI is amazing, it's hard to believe that one guy working on it ---------------------------------------------------------------------- taazz · 2013-03-09 23:41 To tell you the truth I haven't actually seen the fpgui code yet or what widgets has already developed I'm just getting really tired of the open source world where every single difference results in a new distribution of something all those man hours hasted on duplicating the same thing over and over again. That's why I asked if it was preferable to merge those two projects more power to final product thats what I'm thinking. Sorry for the rant. ---------------------------------------------------------------------- gulyone · 2013-03-10 00:07 Quote from: taazz on March 10, 2013, 12:41:06 amTo tell you the truth I haven't actually seen the fpgui code yet or what widgets has already developed I'm just getting really tired of the open source world where every single difference results in a new distribution of something all those man hours hasted on duplicating the same thing over and over again. That's why I asked if it was preferable to merge those two projects more power to final product thats what I'm thinking. Sorry for the rant. Very Good Point Sir ! I think fpGui would be great and a totally independant skinEngine , but , yep its a long long road to go and... I also think other WidgetSets have in common some procs and funcs we could regroup to make a valuable skinengine, bringing that way Our Dear Lazarus on the front of the scene (creators Love when graphics are beautiful and Easy to use , when creating apps, and users make their choice between 2 apps doing the same things in the background only for one reason = the apearance ! SKIN !!!) a LazSkinEngine , then , wouldn't be a toy ! ---------------------------------------------------------------------- mse · 2013-03-15 06:46 Quote from: taazz on March 10, 2013, 12:19:19 amdoesn't fpgui has the same  philosophy with customdraw? any chance of borrowing code or extending that framework ? As another alternative for borrowing code MSEgui uses the following approach for skinning: - Every widget inherits from "twidget", there is no distinction in "TWinControl" and "TGraphicControl" as in Delphi. - twidget (and thus all MSEgui widgets) has a property "frame" and a property "face". - twidget.frame is of type "tframe" which manages the frame layout and drawing, scrollbars for example are drawn by the tframe descendant "tscrollbarframe". - For simple widgets which don't need the frame functionality the frame property does not need to be instantiated, the memory consumption is then a nil-pointer only. twidget.frame can be activated at design or runtime for every twidget if desired. - tframe has many possibilities to customise the look, for example it is possible to use pixmaps for the corners and the edges, it is also possible to use different pixmaps for different widget states (focused,clicked...). - tframe has a property "template" which links a "tframecomp". tframecomp sets the look of all connected tframe instances. Default values which are supplied by tframecomp can be overridden by setting properties of the individual tframe instances. - "tface" is a similar construct for painting the twidget client area by fades and tiled or stretched pixmaps. - There is a similar tface.template property which links to "tfacecomp". - In order to do a centralised skinning "tskincontroller" can be used. tskincontroller assigns dedicated tframecomp and tfacecomp to the frame.template and face.template properties of the different widgets (tbutton, tdataedit, containers, tabbar...) and sets color, font and other properties if desired. For more complex tasks ther are event hadles where settings can be made in code. Martin