Re: consensus for Wx::Perl ? // Wx::Perl::Splitter

[Mark Dootson]

Hi Herbert,

I think you should do exactly what you think best. You have as much 
experience of using Wx as any of us I think so if your experience tells 
you that one particular way is best, then do that. It will be your 
module after all.

In my opinion only, you can implement your constructors however you 
like. All that I would appreciate as an end user would be that it is 
documented - but it is your module so your call.

I look forward to seeing the module(s) on CPAN and all your tutorial / 
documentation work.

Regards

Mark

On 01/09/2012 19:46, herbert breunung wrote:
hai mark

i thought about,
and what about hybrid API,
so you can do it positional and if there is only one param hasref i do it the
current way. would be that acceptable for an Wx::Perl::* module?

best
herbert

btw I'm registering the Namespace Bundle::Wx::Perl right now

Am 01.09.2012 13:42, schrieb Mark Dootson:
Hi,

On 31/08/2012 20:49, herbert breunung wrote:
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.

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.


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.

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