Re: consensus for Wx::Perl ? // Wx::Perl::Splitter
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
Re: consensus for Wx::Perl ? // Wx::Perl::Splitter
the default seems to be Bundle:: http://search.cpan.org/search?query=Bundlemode=all so it will be Bundle::Wx::Perl
Re: consensus for Wx::Perl ? // Wx::Perl::Splitter
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
Re: consensus for Wx::Perl ? // Wx::Perl::Splitter
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
Re: consensus for Wx::Perl ? // Wx::Perl::Splitter
Hi, On 31/08/2012 22:33, Erik Colson wrote: And why Wx::Perl ??? cpan is all about Perl isn't it ? No need to put Perl in any module namespace It is just a convention that a few pure Perl CPAN Wx related modules have been called Wx::Perl:: so it was worth pointing that out. The only rule that I personally would request folks to follow is that it makes life simpler if the Wx:: top level namespace is reserved for modules that wrap C++ classes. So Wx::MyModule is reserved for something that wraps a C++ class called wxMyModule. wxPerl internals rely on this so that a few C / C++ functions can serve all the wxPerl classes. It makes maintenance and wrapping new classes and wxWidgets versions really quite simple in most cases ( thanks to Mattia ). Given this, there has to a sub-namespace under Wx:: for use by stuff that does not wrap a C / C++ class so Wx::Perl:: seems a natural enough choice. Wx::Perl:: is already established in use for several modules outside of the main Wx distribution so as it is there it seems reasonable to point folks at it. I would agree though that if you are producing a whole set of wrappers then MyFramework::TextCtrl, MyFramework::Button and the like seem more appropriate. Cheers Mark
consensus for Wx::Perl ? // Wx::Perl::Splitter
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. 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. best herbert aka lk
