Cheers>> or Wx::Perl::Bundle.
>
> I think the Wx::Perl:: namespace has always indicated pure Perl modules so
> "Wx::Perl::Bundle" looks like a good name for a bundle of all of these.
agreed it will be Wx::Perl::Bundle
>>
>> 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');
>>
>> is to me much clearer.
>>
>> im really interested i you view.
>
> I think the modules on CPAN generally stick to the parameter conventions of
> the existing main Wx.
so should i name it WxPerl::Splitter
its not just a custom thing for kephra. it is now but its like
Wx::Perl::ListCtrl a pure perl thing that eases the api and does some things
the original module should do like taking care or reparenting, remembering
position for unsplit to seemlingless resplit and things like that.
i really tried to come up with an positional api bit this seemed to me much
more natural even if i use in kephra internal apis itself mostly positional
parameters.
best
> I think that probably many long time Wx users have their own versions of this
> in place. Having to pass all previous parameters when you just want a 'style'
> generally drives a person to implement a way of overcoming this.
>
> The GUI parts of Citrus Perl rely on a set of modules prefixed CP::Wx:: that
> take care of this. The modules themselves are just a renamed port of internal
> modules in other applications.
>
> For example, a code snippet
>
> ----------------------------
>
> my $dname_label = CP::Wx::StaticText->new($self, label => t('Distribution'));
> my $dname = CP::Wx::ValidatedText->new($self, vdata => $vdata, vdatafield
> => 'citrusname', style => wxTE_READONLY);
> my $version_label = CP::Wx::StaticText->new($self, label => t('Version'));
> my $version = CP::Wx::ValidatedText->new($self, vdata => $vdata,
> vdatafield => 'citrusversion', style => wxTE_READONLY);
> my $perl_label = CP::Wx::StaticText->new($self, label => t('Perl'));
> my $perl = CP::Wx::ValidatedText->new($self, vdata => $vdata, vdatafield
> => 'citrusperl', style => wxTE_READONLY);
> my $widgets_label = CP::Wx::StaticText->new($self, label =>
> t('wxWidgets'));
> my $widgets = CP::Wx::ValidatedText->new($self, vdata => $vdata,
> vdatafield => 'citruswidgets', style => wxTE_READONLY);
>
> -----------------------------
>
> Examples of simple wrappers are in CP::Wx::Control and the code that makes it
> work is in CP::Wx::Window. It is intended to make it v simple to implement new
> wrappers for new controls simply by looking at CP::Wx::Control.
>
> It currently lurks only in Citrus Perl as probably CP::Wx:: is not a
> reasonable namespace - but I like it being short. Also, such things are fairly
> useless to a wider community without documentation.
>
> So - in answer to your question - yes, named params make absolute sense to me
> - but my view is that it needs to be outside the main Wx dist. The main Wx
> dist replicates as far as is possible the C++ interface - which means that the
> C++ docs, more or less, work for wxPerl too.
>
>
> I hope the above relates to your questions.
>
> Regards
>
> Mark
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>>
>> best
>> herbert aka lk
>
>
