yes i just extend classs without frameworks and im cautious to only pollute Wx::Perl namespace with generally useful modules and i will also only include things into the bundle that are in development, stable and useful. there will be still a lot kephra modules that will not show up on cpan. but especially the sizer and panel class i have to put on cpan because it will be nucleus of my gcl project. the will compile datastructures into gui. unlike XRC it will be no xml but native perl structures, easy to read write , marshal, save and also retrievable from a gui. secand phase will be a dsl to define gui with very few types. at the beginning very minimal but will se how far we get. once also other backends like prima , gtp or qt stand we will have a real nice api to define very simply gui, like in rebol, and can output into all front one day maybe even to web or whatever. i want to see perl as a primary language for gui programming.
yeah sound like i want to do everything at once. thatwhy currently book and kephra are most important. then we will see. best Am 31.08.2012 23:33, schrieb Erik Colson: > herbert breunung <deirdre_s...@web.de> writes: > >> Allright, >> >> I alright wrote here that I do currently some helper modules and after im >> more >> familiar with dzil and their API gets more stable i want to ship them to >> cpan. >> However after we get more and more Wx::Perl modules (didnt knew even >> Wx::Perl::ListCtrl) i would like du bundle them into the module Wx::Perl >> or Wx::Perl::Bundle. > > All depends on the purpose of your modules. i.e. Probably lots of wxPerl > developpers create their own (mooseified or not) classes based on the > classes from Wx:: > > If yours extend existing classes from the basic Wx, then I might prefer to > see them somewhere out of Wx namespace. Maybe WxFramework:: ? > > And why Wx::Perl ??? cpan is all about Perl isn't it ? No need to put > Perl in any module namespace > > Not sure however, this is probably best discussed with Mark and on the > pause module naming list.. > >> However the more important question I like to ask you all is how consistent >> has the API be bewtween all of these modules. Especially what is now >> Kephra::App::Splitter has named parameters because IMO >> >> ....Splitter->new( parent => $win, $left=> $w1, right=> $w2, gravity=> >> 'left'); > > i guess the '$' before the first 'left' is a typo ? > all my classes using Moose use named parameters as you do here. So yes, > clearer and less error prone ! > > best > -- > erik >
