lichtkind

Good morning, this will be about GCL (my attempt to make WxPerl programming fun) and I want alsohear from you if its allright to talk about that at this stage of development on Perl Workshop (one month to go so a lot will change).

This is another Problem i sit on forever, i mean when I promised cromatic my first article on Wx::XRC ??? You know WxPerl looks good as an actor, is fast, needs some RAM, but programming it is sometimes not the experience to strive for. Many saw the problem and few tried to solve it ( wxPerl::*. TUIT and other), but nobody went very far. So what we gonna do and how prevent failure.(in precaution I called the Project Wx::Perl::Smart to remember me go a better route than the smartmatch op)

I think the standard answer (incremental steps) is helpful here. And besides that I already have plenty code to show, its living as helper classes inside of Kephra. But first things ...
Creating the normal Widgets is two cumbersome. Because firstly there are lot of parameters that are useless, but you have to fill them in because the real interesting stuff comes at a position after it. Than there is stuff missing you have to give the object in a second third and fourth call, and there are even parameters you could your object ruin with, even they are acceptable from the constructors point of few. I speaking here especially of the parent widget. if that is at one time set to undef (which is allowed) you never gonna repair the event behaviour because you never will be able to reparent it to a widget hence all event get stuck and will never reported to parent object, there some weird GTK warning you provoke ... lots of weir issues ahead, you just don't want that. The ID falls into the unnecessary category because you already have your Perl ref, which is an ID for this widget and since we have fine hashes in Perl we also don't need a name parameter. position is also useless since managed by sizer as well as size which you want to only sometimes interfere with (but should be done when composing the layout so you get all that information also in one place.) Oh and then you have to do an extra call to mount the event even there is just one like for a button. So i did some smart constructors for a button and some other widgets. But since its only the constructor and nothing more i don't wanted to have an extra module for any widget. So created the Wx::Perl::Smart::Widgetfactory. When building a factory object you give it once the parent object, and have to care about one thing less. (correct reparenting necessary later when doing layout.). When you use the Wx::Perl::Smart::Frame which helps you to save the 3,4 usual commands to set up the basics steps when starting an app you can also the widgetfactory as a method inside and the parent is also already set to the frame.

That has also the advantage that the *::Smart::Frame has also the smart layout constructors inside you you give them when creating the widgets a nice name under which they are stored, and later when defining the layout you just use this names in a perly data structure which gets compiled to the layout and all problems of visibility and right reparenting are taken care of by the smart layouters. To see that in action (its all running code today) just visit the bitbucket repo of the Harmonograph.

Alright so what did I meant with incremental steps. The WidgetFactory will become an independent Module so it provides leverage on its own, but its 30% here of what I envision it could be.

Second independent step are combined widgets. I also did several of them and will alter explain them in details. They are combinations of several simpler widgets but behave as one, giving you a simpler API to abstract reoccurring tasks away. Just two examples: a slider that displays its value in a small text box and if you edit the box you trigger same event as moving the slider. Another thing the the AUI::Notebook - a tab bar with moveable tabs by mouse. I patched it so you can also move the tabs by keyboard and mouse. But the main problem was when moving a tab my mouse and then selecting a tab by keyboard it used the previous, not the visible order. all that's however fixed.
These widgets you can also use independently form the widget factory and the smart layouters so you decide how smart your programs get :)

Third thing are the describes layouters. here you can also choose if you use the full thing (Smart::Panel) or just the smart sizer which get do a littel bit more that the normal BoxSizer and also has a simpler API.

The forth this will be a wiki liek syntax on to of it all which compiles to the data structure which will be compiled down to the layout as the Smart::Frame did. I think with that plan I'm up to success even there is so much still to be done. Thanks for your attention.